Saturday, September 29. 2007
Posted by Jonathan Street
in PHP Programming, Programming, Website Management at
16:16
Comments (4)
Trackbacks (4)
Comments (4)
Trackbacks (4)
Benchmarks, Site Speed and User Experience
Following on the back of my recent posts looking at the (hopefully) best and worst of benchmarks I thought it would be useful to finish off with some genuine tips for creating 'lightning fast' websites. I probably lack the experience and insight to bring anything new to the table though so instead I'll point you to a selection of interesting articles.
Firstly, let's lay the benchmarking issue to rest. Ben Ramsey, who after his initial outrage at my 7 tips post felt it "actually is really humorous" (probably unjustified praise but thanks anyway!), has a nice post highlighting the code in the PHP source confirming the lack of any difference I demonstrated in my follow up post. Wez Furlong commented on my 7 tips post and highlighted a post he made on benchmarking back in 2005. For anyone feeling my method was excessive his approach gives speedier results. Personally I'd like to see it run in triplicate though.
Next, as far as the minute differences the 'lightning fast PHP'-style posts are too often built around Ilia Alshanetsky probably has the best write-up.
Absolutely.
Getting to articles with tips for that 1st round of optimisations you may want to make there are 13 tips for high performance websites on the Yahoo! developer network. These were written by Steve Souders who, in addition to writing the book 'High Performance Web Sites,' is speaking at the FOWA conference next week. That's one session I definitely want to catch. Hasin Hayder has a follow up post which is definitely worth reading.
Hasin goes into more detail than the Yahoo! article and provides some sample code. A three part series of posts at the IBM developerWorks site takes a PHP focused look at high performance websites and provides some useful instructions on setting up your sites to use the XCache opcode cache, Xdebug and memcache.
Three rules for high performance web sites
For those wanting the abridged version here are my 3 tips for high performance.
1) Fast environment - Start from a position of strength. I didn't post the average speeds in the better benchmarks post because I was looking at the difference rather than the absolute values but the benchmarks were running ten times faster on my web host than on my desktop. There are various reasons why this may be the case, Linux vs Windows XP, system specs, PHP 5.2.3 vs 'evil' PHP 5.2.1, but it doesn't really matter beyond illustrating the need for a good server and host. Other things to consider include an optimizer/opcode cache and gz compression.
2) Cache everything - Database and web service queries, blocks of content and even your entire page are all fair game.
3) Test everything - Time your code. Profile your code. Test your assumptions (including tips 1 & 2).
Speed doesn't matter
Finally an alternative take because playing devils advocate is fun. Download speed is not how users determine the speed of a site. To the user a site is fast if they can quickly achieve their goal. Steven O'Grady at Red Monk also raises some interesting points contrasting the perspective of the developer and the user.
As always further suggestions, alternative viewpoints and discussion are welcome in the comments below.
Firstly, let's lay the benchmarking issue to rest. Ben Ramsey, who after his initial outrage at my 7 tips post felt it "actually is really humorous" (probably unjustified praise but thanks anyway!), has a nice post highlighting the code in the PHP source confirming the lack of any difference I demonstrated in my follow up post. Wez Furlong commented on my 7 tips post and highlighted a post he made on benchmarking back in 2005. For anyone feeling my method was excessive his approach gives speedier results. Personally I'd like to see it run in triplicate though.
Next, as far as the minute differences the 'lightning fast PHP'-style posts are too often built around Ilia Alshanetsky probably has the best write-up.
Please keep in mind that these are not the 1st optimization you should perform. There are some far easier and more performance advantageous tricks, however once those are exhausted and you don't feel like turning to C, these maybe tricks you would want to consider.
Absolutely.
Getting to articles with tips for that 1st round of optimisations you may want to make there are 13 tips for high performance websites on the Yahoo! developer network. These were written by Steve Souders who, in addition to writing the book 'High Performance Web Sites,' is speaking at the FOWA conference next week. That's one session I definitely want to catch. Hasin Hayder has a follow up post which is definitely worth reading.
Hasin goes into more detail than the Yahoo! article and provides some sample code. A three part series of posts at the IBM developerWorks site takes a PHP focused look at high performance websites and provides some useful instructions on setting up your sites to use the XCache opcode cache, Xdebug and memcache.
Three rules for high performance web sites
For those wanting the abridged version here are my 3 tips for high performance.
1) Fast environment - Start from a position of strength. I didn't post the average speeds in the better benchmarks post because I was looking at the difference rather than the absolute values but the benchmarks were running ten times faster on my web host than on my desktop. There are various reasons why this may be the case, Linux vs Windows XP, system specs, PHP 5.2.3 vs 'evil' PHP 5.2.1, but it doesn't really matter beyond illustrating the need for a good server and host. Other things to consider include an optimizer/opcode cache and gz compression.
2) Cache everything - Database and web service queries, blocks of content and even your entire page are all fair game.
3) Test everything - Time your code. Profile your code. Test your assumptions (including tips 1 & 2).
Speed doesn't matter
Finally an alternative take because playing devils advocate is fun. Download speed is not how users determine the speed of a site. To the user a site is fast if they can quickly achieve their goal. Steven O'Grady at Red Monk also raises some interesting points contrasting the perspective of the developer and the user.
As always further suggestions, alternative viewpoints and discussion are welcome in the comments below.
Sunday, September 23. 2007
Better Benchmarks
Following one too many posts talking about increasing the speed of PHP scripts by using single quotes instead of double quotes, preincrementing rather than postincrementing variables and the like I wrote 7 tips for lightning fast PHP sites. This post was supposed to be a spoof celebrating the worst aspects of these types of posts. I suggested that a hundred nanoseconds or so saved was going to make a practical difference. I based my findings on just one run and justified this by looping over a function a million times.
I had thought that with comparing aliases of functions seven times over people would realise what I was doing but apparently my post was just too close to the sad reality and lacking in sufficient humour for people to catch on.
Here I again present benchmarks for the seven pairs of functions I compared in my last post. The difference being that this time the benchmark I use is my best attempt. If you think you can do better I would like to hear from you.
Test Environment
For this more rigorous test I switched from my local development server to a remote shared hosting account running PHP 5.2.3 on a Linux system.
Benchmark Methodology
As before the code used to run the test is available for download. Instead of just running each function one million times and timing it multiple rounds of replication are now used. Each function is run one thousand times and then its partner is run one thousand times. This process is also repeated one thousand times during the execution of a single script. This gives the one million runs performed in the previous post. This is considered to be a single test. This test is run in blocks of ten with two second intervals between each request. Each of these ten test blocks are run every five minutes via a cron job. This allows 120 'tests', and 120 million function executions, to be run an hour without any supervision.
After leaving it to run for an hour or so I got to work processing the stats. Continue reading "Better Benchmarks"
I had thought that with comparing aliases of functions seven times over people would realise what I was doing but apparently my post was just too close to the sad reality and lacking in sufficient humour for people to catch on.
Here I again present benchmarks for the seven pairs of functions I compared in my last post. The difference being that this time the benchmark I use is my best attempt. If you think you can do better I would like to hear from you.
Test Environment
For this more rigorous test I switched from my local development server to a remote shared hosting account running PHP 5.2.3 on a Linux system.
Benchmark Methodology
As before the code used to run the test is available for download. Instead of just running each function one million times and timing it multiple rounds of replication are now used. Each function is run one thousand times and then its partner is run one thousand times. This process is also repeated one thousand times during the execution of a single script. This gives the one million runs performed in the previous post. This is considered to be a single test. This test is run in blocks of ten with two second intervals between each request. Each of these ten test blocks are run every five minutes via a cron job. This allows 120 'tests', and 120 million function executions, to be run an hour without any supervision.
After leaving it to run for an hour or so I got to work processing the stats. Continue reading "Better Benchmarks"
Saturday, September 22. 2007
7 tips for lightning fast PHP sites
Note: This was intended as a spoof. After laughing (or not) at the 'evidence' see my follow up post for how I think a benchmark should really be run.
I was recently creating a small tool in PHP and found myself hitting the max execution time and getting a fatal error. As it was only for my personal use I just bumped up the max execution time but it made me stop and think about how I could improve the speed of those scripts I do put up for public use. Most people aren't going to wait for 60 seconds for a page to load.
Naturally I hit the internet looking for tips. Blog posts, apparently entire blogs, forum posts and even dynamic web pages are devoted to speeding up our PHP based websites. Although these provide some information on small improvements I wanted more.
I set out to investigate whether there are any functions in PHP which perform similar tasks but where one function is faster than another. str_replace and preg_replace are fairly well known examples but I wanted to find others.
Test Environment
All tests were run on on a VIA Nehemiah 999 MHz with 480 Mb RAM (my gaming rig
) running Windows XP Professional SP2 and PHP 5.2.1. The code used to run these tests can be downloaded. In summary all tests were run 1 million times so that any potential errors averaged out.
1. sizeof vs count
First up are the sizeof and count functions. They can both be used to count the number of items in an array but does one do it better?
sizeof vs count
sizeof: 3.75928902626 seconds
count: 3.33035206795 seconds
Time saved: 0.428936958313 seconds; 12.8796280262%
The evidence says yes. The count function was over 12% faster in this test. Both functions are fast though taking 3-4 microseconds to count an array with 100,000 items. You might think it isn't worth it but remember count is also a character shorter. Not only is it faster to run but it is also faster to type!
Continue reading "7 tips for lightning fast PHP sites"
I was recently creating a small tool in PHP and found myself hitting the max execution time and getting a fatal error. As it was only for my personal use I just bumped up the max execution time but it made me stop and think about how I could improve the speed of those scripts I do put up for public use. Most people aren't going to wait for 60 seconds for a page to load.
Naturally I hit the internet looking for tips. Blog posts, apparently entire blogs, forum posts and even dynamic web pages are devoted to speeding up our PHP based websites. Although these provide some information on small improvements I wanted more.
I set out to investigate whether there are any functions in PHP which perform similar tasks but where one function is faster than another. str_replace and preg_replace are fairly well known examples but I wanted to find others.
Test Environment
All tests were run on on a VIA Nehemiah 999 MHz with 480 Mb RAM (my gaming rig
1. sizeof vs count
First up are the sizeof and count functions. They can both be used to count the number of items in an array but does one do it better?
sizeof vs count
sizeof: 3.75928902626 seconds
count: 3.33035206795 seconds
Time saved: 0.428936958313 seconds; 12.8796280262%
The evidence says yes. The count function was over 12% faster in this test. Both functions are fast though taking 3-4 microseconds to count an array with 100,000 items. You might think it isn't worth it but remember count is also a character shorter. Not only is it faster to run but it is also faster to type!
Continue reading "7 tips for lightning fast PHP sites"
