Website Performance Tips & Tricks

vijayanand · #21 (**permalink**) 08-10-2007, 06:37 AM

Generic Session Optimizations

• Don't use session.auto_start.
• Do not enable session.use_trans_sid
• Whenever possible set session.cache_limiter to private_no_expire
• Assign each user (vhost) it's own sessions directory.
• For large sites consider using session.save_path = "N;/path"
• If possible avoid automatic garbage collection.

ragavraj · #22 (**permalink**) 08-10-2007, 06:58 AM

SSL Acceleration :

Most of the E-commerce site enabled a SSL for Credit card offload encryption/decryption prcoessing task.The Web servers to spend more processing on content genratin and delivery.When considering an SSL accelerator, take into consideration the number of transactions per second (TPS) it can handle. TPS will be more important on SSL Acceleration appliances than cards. For instance, if you buy an SSL Accelerator Card that can handle 2000 TPS for a server that can only handle 500 TPS, then you waste the money on the 1500 TPS you can't use. An SSL Acceleration hardware appliance (box) can deal with transactions for all your web servers and scale quickly.

Thanks
R.Rajan

vijayanand · #23 (**permalink**) 08-11-2007, 12:26 AM

we can increase the performance of the site by using following steps:
1)
for ($i=0;$i<count($some_array);++$i) {
}is slow

$temp=count($some_array);
for ($i=0;$i<$temp;++$i) {
}is faster

for ($i=0;isset($some_array[$i]);++$i) {
}is fastest

2)
Use ++$i instead of $i++. The second one uses a temporary copy of $i to add 1 to, then assign to $i.

vijayanand · #24 (**permalink**) 08-11-2007, 12:35 AM

Hi,
Using 'echo' is faster than 'print' because it is a language construct, not a function.

and also using include ‘/some/file.php’ instead of include(’/some/file.php’).
Same for require and the _once equivalents.

These will lead to increase the performance of the site.

ramkumaraol · #25 (**permalink**) 08-13-2007, 12:21 AM

The places where such high returns are achievable are in the while and for loops that litter our code, where each slowdown in the code is magnified by the number of times we iterate over them. The best way of understanding what can be optimized is to use a few examples:

Example 1

Here is one simple example that prints an array:

for ($j=0; $j<sizeof($arr); $j++)
echo $arr[$j]." ";

This can be substantially speeded up by changing the code to:

for ($j=0, $max = sizeof($arr), $s = ''; $j<$max; $j++)
$s .= $arr[$j]." ";

echo $s;

First we need to understand that the expression $j<sizeof($arr) is evaluated within the loop multiple times. As sizeof($arr) is actually a constant (invariant), we move the cache the sizeof($arr) in the $max variable. In technical terms, this is called loop invariant optimization.

The second issue is that in PHP 4, echoing multiple times is slower than storing everything in a string and echoing it in one call. This is because echo is an expensive operation that could involve sending TCP/IP packets to a HTTP client. Of course accumulating the string in $s has some scalability issues as it will use up more memory, so you can see a trade-off is involved here.

An alternate way of speeding the above code would be to use output buffering. This will accumulate the output string internally, and send the output in one shot at the end of the script. This reduces networking overhead substantially at the cost of more memory and an increase in latency. In some of my code consisting entirely of echo statements, performance improvements of 15% have been observed.

ob_start();
for ($j=0, $max = sizeof($arr), $s = ''; $j<$max; $j++)
echo $arr[$j]." ";

Note that output buffering with ob_start() can be used as a global optimization for all PHP scripts. In long-running scripts, you will also want to flush the output buffer periodically so that some feedback is sent to the HTTP client. This can be done with ob_end_flush(). This function also turns off output buffering, so you might want to call ob_start() again immediately after the flush.

In summary, this example has shown us how to optimize loop invariants and how to use output buffering to speed up our code.

Example 2

In the following code, we iterate through a PEAR DB recordset, using a special formatting function to format a row, and then we echo the results. This time, I benchmarked the execution time at 10.2 ms (this excludes the database connection and SQL execution time):

function FormatRow(&$recordSet)
{
$arr = $recordSet->fetchRow();
return ''.$arr[0].''.$arr[1].'';
}

for ($j = 0; $j < $rs->numRows(); $j++) {
print FormatRow($rs);
}

From example 1, we learnt that we can optimize the code by changing the code to the following (execution time: 8.7 ms):

function FormatRow(&$recordSet)
{
$arr = $recordSet->fetchRow();
return ''.$arr[0].''.$arr[1].'';
}

ob_start();

for ($j = 0, $max = $rs->numRows(); $j < $max; $j++) {
print FormatRow($rs);
}

My benchmarks showed me that the use of $max contributed 0.5 ms and ob_start contributed 1 ms to the 1.5 ms speedup.

However by changing the looping algorithm we can simplify and speed up the code. In this case, execution time is reduced to 8.5 ms:

function FormatRow($arr)
{
return ''.$arr[0].''.$arr[1].';
}

ob_start();

while ($arr = $rs->fetchRow()) {
print FormatRow($arr);
}

One last optimization is possible here. We can remove the overhead of the function call (potentially sacrificing maintainability for speed) to shave off another 0.1 milliseconds (execution time: 8.4 ms):

ob_start();

while ($arr = $rs->fetchRow()) {
print ''.$arr[0].''.$arr[1].'';
}

By switching to PEAR Cache, execution time dropped again to 3.5 ms for cached data:

require_once("Cache/Output.php");

ob_start();

$cache = new Cache_Output("file", array("cache_dir" => "cache/") );

$t = getmicrotime();

if ($contents = $cache->start(md5("this is a unique kexy!"))) {
print "Cache Hit";
print $contents;
} else {
print "Cache Miss";

##
## Code to connect and query database omitted
##

while ($arr = $rs->fetchRow()) {
print ''.$arr[0].''.$arr[1].'';
}

print $cache->end(100);
}

print (getmicrotime()-$t);

We summarize the optimization methods below:

ExecutionTime (ms)

Optimization Method

9.9

Initial code, no optimizations, excluding database connection and SQL execution times.

9.2

Using ob_start

8.7

Optimizing loop invariants ($max) and using ob_start

8.5

Changing from for-loop to while-loop, and passing an array to FormatRow()and using ob_start

8.4

Removing FormatRow()and using ob_start

3.5

Using PEAR Cache and using ob_start

From the above figures, you can see that biggest speed improvements are derived not from tweaking the code, but by simple global optimizations such as ob_start(), or using radically different algorithms such as HTML caching.

Booom · #26 (**permalink**) 08-13-2007, 12:48 AM

Hey all, due to the very good performance of this thread, ive made this thread as sticky and have moved it to a more appropriate forum.

Thanks

ramkumaraol · #27 (**permalink**) 08-13-2007, 02:32 AM

Use HTML caching if you have data that rarely changes. Even if the data changes every minute, caching can help provided the data is synchronized with the cache. Depending on your code complexity, it can improve your performance by a factor of 10.

Thanks,
Ramkumar.B

vijayanand · #28 (**permalink**) 08-14-2007, 06:39 AM

Beginner Vs Experienced

Beginner : echo "$var";
Experienced : echo $var;

Beginner:echo "<a href="http://www.php.net">PHP</a>";
Experienced : ?><a href="http://www.php.net">PHP</a><? ... ?>

Beginner : $a[0]=1; $a[1]=2; $a[2]=3;
Experienced : $a = array(1,2,3, 1);

Beginner : if($a>1) { $b=2; } else { $b=3; }
Experienced : $b = ($a>1) ? 2:3;

Beginner : $result=mysql_query(...);
Experienced: $result=mysql_query(...) OR die
(mysql_error());

Where Experienced reduces the time of execution and coding length.

vijayanand · #29 (**permalink**) 08-14-2007, 06:41 AM

We can speed up the site by means of following...

If you use Javascript functions or STYLE tags, then put all of these into a file called
common.inc and use the following:

<? require 'common.inc'; ?>

on any page that you want these function included.

ramkumaraol · #30 (**permalink**) 08-14-2007, 06:58 AM

The fastest way to concatenate multiple small strings into one large string is to create an output buffer (ob_start) and to echo into the buffer. At the end get the contents using ob_get_contents. This works because memory allocation is normally the killer in string concatenation, and output buffering allocates a large 40K initial buffer that grows in 10K chunks

Thanks,
Ramkumar.B

vijayanand · #31 (**permalink**) 08-14-2007, 07:33 AM

For better performance of the site, you might want to disable calling fsync(). (There is risk that you loose more data when system is crushed, though)

To disable auto fsync(), start postmaster like

postmaster -o '-F'

This is recommended setting for session database, since session database is not critical as account database and it accessed most often.

kathir · #32 (**permalink**) 08-14-2007, 07:42 AM

Better php.ini setting (track_vars, register_globals)

PHP users are better to set enable "track_vars" and disable "register_globals" for sevral reasons.
(PHP programmers are better to use $HTTP_*_VARS and $HTTP_POST_FILES).

1) Readability: With $HTTP_*_VARS, code readers does not have to check where values comes from. With $HTTP_*_VARS, code maintenance can be much easier and programmer will spend less time for debugging code.

2) Portability: If global var registration order has been changed (May differ server to server), code may not be portable. (Insecure also)
With PHP4, track vars are always enabled, so programmer can be sure there are $HTTP_*_VARS for PHP4.

3) Security: Without $HTTP_*_VARS, sensitive variables may be over written by intruders. Or sensitive variables may be over written due to changes in global var registration order. [Programmer should check user inputs always, thogh]

4) Performance: If "register_globals" is disabled, PHP does not have to make a copy for global var. Programmer does not have to check to make sure variables are over written unintentionally.

5) PHP4 Session: Programmers can save session variables without using session_register() with $HTTP_SESSION_VARS. i.e. Programmer can use $HTTP_SESSION_VARS as normal array and it persists as session vars

PHP users could have these benefits by using $HTTP_*_VARS. Without $HTTP_*_VARS, programmers are loosening those advantages in return of saving number of typing keys.

Thanks
-Kathir

vijayanand · #33 (**permalink**) 08-15-2007, 11:44 PM

Content Delivery Networks

Web performance can be done by using CDN.

Basically, they have multiple servers across the world and when a request comes for yourcompany.com for example, the CDN "owns" the DNS for that name and static .html, JavaScript files, and image files can be served from their edge server. If their edge server doesns't contain your .html, image, or JavaScript, their edge server sends a request back to your web server transparently to another domain (another.yourcompany.com) on the internet to retrieve the files.

The files then get sent back to their edge server and stored there and then sent to the client. If your file is at their edge server, the client machine (requestor) gets the files from their edge server. Thus if your web server is sitting in San Francisco and someone from London wants to visit your web site, your site content can be served from a CDN server in London instead of San Francisco, reducing response time.

Obviously, the time it takes for data to transfer within London is a lot less than from London to San Francisco. CDNs can also provide live streaming functionality - serving bandwidth intensive media from their content servers... something that can be costly if you are a multimedia-rich company. Watch out for testing results CDN companies give that are irrelevant to your site. Any test results of downloading large single 300kb .gif files are not indicative of how well a CDN's service is appropriate to you.

vijayanand · #34 (**permalink**) 08-15-2007, 11:52 PM

Two types of performance

There's two different ways to look at a website's performance.

First of all there's raw server performance. How many page request can a server handle before it collapses under load and more important: how fast can it process them. On a high volume website this aspect of performance is very important because it determines how many users a machine can serve before additional server capacity is needed. This article is not about this kind of performance tuning. WordPress comes with a pretty robust caching engine built in which makes it perform as fast as it possibly can.
The second way to look at performance is what we could call 'perceived performance'. It's the speed at which your site appears to perform to the user. Even if your server is capable of serving all files required to render your website's pages in a visitor's browser as fast as it gets, your site may still appear slow to the user. A fast pipe doesn't necessarily result in a fast website. Slow client-side performance can have a plethora of causes. There's an awful lot to gain on the front end side of the game which is what this article is about.

vijayanand · #35 (**permalink**) 08-16-2007, 12:00 AM

Performance Tip:

DON'T try to be smart and randomize hostnames for images on a per-request basis or you'll run the risk of the same image(s) being loaded from different servers instead of being cached by the browser which of course results in an actual performance hit instead of a gain. Make sure each file is downloaded from the same domain at every request

vijayanand · #36 (**permalink**) 08-17-2007, 07:57 AM

How to check if a variable is an integer?

Tip: Assuming $foo is an the variable do :

if (ereg("^[0-9]+$", $foo)) {
echo "it's an Integer";
}

vijayanand · #37 (**permalink**) 08-17-2007, 07:58 AM

Problems of style

It's a matter of style and convenience to produce scripts in such a way that make them easy to read and debug. If you are using a programming editor that highlights your code it will be easy to identify the various parts. This may explain why you find syntax that looks rather confusing at first. Some examples:

$line = $result['name'] . ' ' . $result['last_name']; // ok - easy to
read/debug
$line = $result["name"] . ' ' . $result["last_name"]; // ok, but why
use double quotes if they are not necessary?
$line = "$result[name] $result[last_name]"; // ok - but much harder to
read/debug - poor coding style

$line = $result['name'] . ' ' . doSomething($result['last_name']); //
ok - preferred method (using a function)

If you are working with any kind of a team and/or plan on allowing others access to your work in the future it's etiquette to try to make it accessible and easy on the eyes.

vijayanand · #38 (**permalink**) 08-17-2007, 08:01 AM

Turn On Error Reporting Immediately

The single most important thing I tell people who use PHP is to turn error reporting to its maximum level. Why would I want to do this? Generally the error reporting is set at a level that will hide many little things like:

* declaring a variable ahead of time,
* referencing a variable that isn’t available in that segment of code, or
* using a define that isn’t set.

These factors might not seem like that big a deal -- until you develop structured or object oriented programs with functions and classes. Too often, writing code with the error reporting turned up high would cost your hours as you scoured long functions that didn’t work because a variable was misspelled or not accessible.

PHP won’t tell you anything in that case – it’ll just create the new variable for you and initialize it to zero. The remedy is to put the following line at the top of every PHP document as you develop:

error_reporting(E_ALL);

It simply forces the error reporting to be at its highest level. Try putting this line in other PHP programs, and more often than not you’ll receive a barrage of warning messages that identify all the potentially wrong elements of the code.

*Note - The error report should be off while in production server to avoid users to not view the error.

kathir · #39 (**permalink**) 08-17-2007, 08:03 AM

Combining PHP classes

Out of sheer boredom I wanted to see which was better, including one big file of classes or splitting your classes up into multiple files. I'm going to use nusoap as an example. The NuSoap package lets you download one file. nusoap.php. That one file contains 9 classes. While not only is this method nice as you only need to include one class, its also 24% faster on average than having to include 9 seperate files.

I broke the nusoap.php class out into 9 seperate files, one for each class as most people organize their libraries. I then included the 1 nusoap file, then recorded the time, then included the 9 nusoap files and recorded the time. After 50 iterations the average was that including multiple files was on 24% slower than the one large file.

So what's the lesson? If you're distributing your PHP software package and/or push your scripts to a live server, think about combining your classes by directory into one big file. Lets say you have a directory like this
/classes/
user.php
user_detail.php
user_images.php
user_whatever.php

If all of those files have to be included to create a user object, just create a master user.php file with all of your classes built into that file. The upside is a little faster performance and easier/less includes. The downside is it might be slightly harder to maintain. The trade off is decided by your traffic load. Some of your out there like to eek every little nano second you can out of your scripts.

Thanks
-Kathir

kathir · #40 (**permalink**) 08-17-2007, 08:12 AM

Optimize Your HTML Code

Try to use few tables or divide a big one into several small ones because your user will see the content only after the whole table is built. (So put e.g. the title and subtitle in one small table and the rest in a bigger table: the small table will be visible before the bigger one.)
Use CSS instead of HTML-tags to format your text, if you use the same attributes more than once in your project:
HTML Code:
 mytext
instead of
HTML Code:
 mytext
Iframes? I don't know the golden rule. The optimal solution for dynamic output could be <iframe> my dynamic output </iframe>: your HTML-code immediately gets parsed on your user's browser and after (milli) seconds your database output appears (meanwhile your user reads something else). But ... unfortunately Netscape ignores iframes! What can we do? We can write a second version of our page only for NS-users (inserting a JavaScript browser definition), or we can choose a unique solution for all browsers dividing our site in different frames: a main frame with only a small amount of PHP code that your user will see immediately and a display frame with your query output that the user will see a bit later.

Apropos frames Don't forget that your user bookmarks only the address that will appear in the address bar (that means probably "http://www.yoursite.com" = the address of your "index" file that contains the frameset. This address doesn't change opening other pages by clicking the navigation bar in one of your frames).

Thanks
-Kathir

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode