More on Website Performance Improvements

Lately I’ve been looking at improving the performance of BritBlog, and I think I now have quite a satisfactory solution.

As you may recall, I’ve been looking at using content compression and content caching.

Content (HTTP) Compression

The content compression has made a huge difference to the download times of the pages, but only seems to have added a slight additional load on the server:

Download speeds before and after content compression

The graph above shows the total download time (green), and the data start times (yellow). The data start time is the time taken for the first byte of data to come back from the server, and with dynamic pages this largely reflects the time taken to generate the content.

(You can see four intermediary tests where the download time is only improved a small amount. This is where I compressed the HTML but not the CSS or JavaScript files.) Although you can’t really tell from these graphs, the data start times only go up a smidgen, so I’m guessing the compression work isn’t too much of an overhead.

Anyway, on the whole the content for these dynamic pages doesn’t change much throughout the day, so I’ve been looking into content caching with the two PEAR packages (Cache and Cache_Lite).

Content Caching

Cache_Lite seems to be marginally quicker than Cache, and it’s incredibly simple to use. It even has built in output buffering so you don’t need to control this yourself. Can you tell I like it?!

The graph below shows how the use of caching (with Cache_Lite) has improved the data start times of page requests, and therfor overall web site performance. I’ve set the cache life to one hour, and you can see that once an hour there is a spike in the data start times where the cache is refreshed. Caching was enabled at about 4:30 PM, so the cache file was built at the first HTTP request at 4:38 PM.

Data start times improve once content caching is enabled

Although this only saves us about 200 milliseconds, the work done by the server is reduced dramatically. When looking at these results, you should also bear in mind that there is basically no load on the server at the moment. The only traffic comes from the Site Confidence test agents that I use to gather this data. Once the site is in production usage the load on the system should be greatly reduced.

So is it all worth it?

The short answer is yes, I think so! The traffic on BritBlog is going up everyday, and it seems a bit unnecessary generating all the pages on-the-fly when they change so little. It should also improve the visitor experience as the site will respond more quickly to requests.

More stuff

If you find this interesting, you may like to see my earlier posts on mod_gzip content compression and using PEAR cache_lite.

Finally, I used Site Confidence to monitor my test server and to generate the graphs.

Sociable:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • digg
  • Furl
  • NewsVine
  • Reddit
  • YahooMyWeb

2 Responses to “More on Website Performance Improvements

  • Fabien
    June 20th, 2005 20:26


    I’m the main author of Cache_Lite.

    Just have a look at the Cache_Lite tutorial :

    At the end of this page, there is a section “very important comment”. If you modify your code as it’s described in it, perfs of PEAR/Cache/Lite will be (often) more than twice better PEAR/Cache.

    The main reason is that Cache/Lite load the PEAR.php file only when an error occured (the loading process is dynamic). And PEAR.php is a big file…

  • marky moo
    June 20th, 2005 21:05

    Thank’s for your comments, Fabian, and congratulations on an excellent package!

Leave a Reply