stmllr.net

Little case study on using static file cache to increase performance of TYPO3

by on stmllr.net

The average number of requests on www.t3node.com is growing more and more. Since the website is hosted on a tiny virtual machine shared with others, the overall server performance is bad. Today I decided to serve pages from file cache to reduce the load. This little case study describes the problem by example and gives some key data for illustration.

Introduction

There are several other websites hosted on the server and TYPO3 is not the only one eating performance. At peak periods, the server load is very high and pages are served with much delay. Not only visitors suffer from slow websites, but there are rumors that google may take performance into ranking account (so called speed rank).

Solution

Since this website is driven by TYPO3, I decided to install the static file cache extension (nc_static_file_cache).This extension puts pages from the page cache to files in the filesystem. Whenever a page is requested, it gets served from the file system without involving TYPO3.

Test results (1)

To test the performance gain, I used ApacheBench (ab) on the start page:

spock@enterprise:/tmp$ ab -c 10 -n 1000 http ://www.t3node.com/

The result was disappointing 8 req/s.

After some investigation I realized that most of my pages did not profit from this cache. The info module of the static file cache extension reported, that they could not be statically served because they contain uncached USER_INT objects. Inspections with the admpanel revealed two extensions which use USER_INT:

Fixing the issues

I decided to remove the 'most popular' extension, since I never really liked the approach to save statistic data in the database table of the entity. I am going to look for something similar, maybe using some JavaScript counter or Apache access_log in combination with COA_GO.

The Tweet is still shown, but as a cached USER object which will be updated once a day. I think that's a good compromise, since my twitter activity is anyway not so high.

Test results (2)

To test the performance gain, I used ApacheBench (ab) on the start page:

spock@enterprise:/tmp$ ab -c 10 -n 1000 http ://www.t3node.com/

With USER_INT cObjects: 8 req/s.

Without USER_INT cObjects and without static file cache: 40 req/s.

Without USER_INT cObjects and with static file cache: 500 req/s.

That's 62.5 times faster than before! Ready to get slashdottet :-)

Conclusion

Performance can be crucial. If your website feels slow, search for bottlenecks like USER_INT extensions. If you can manage to get rid of USER_INT cObjects, chances are that you can also profit by a static file cache. That could push your website performance to lightning speed.

Tags

Comments

  1. terrorfrog

    Ahm you may or may not already optimizie and proper configure the hole apache subset

    not only php optimizer and proper mem config (never use to much btw)

    also think about to switch to ngix

    another server threatment you shoudl consider are ssds

    they are not suitable for big datastorage but for the typo3 core it is (symlinking to different partitions)

    the big advantage is you get high speed drives for about 150€ - even used as a mirror softwareraid they are faster than a high end raid 10 combination

    simply one drive can read at 450mb/sec and seek times below 1ms while even a multiarray MAYBE be ablle to deliver that datarate it can never deliver that seek time


    typo3 - is a bitch - because of its contruction - accessing so many files for every simple function - here you profit from php optimizer with cache in memory / ramdisks and ssds


    -
    if you have to much server memory but no ssds - simple solution - mount in fsck a ramdrive - make a startupscript copying the directory of typo3 core into it

    links your installations to that new drive

    voilla - high speed typo3 core :)

    i personally prefer ssds for some reasons - specially after reboot take a while to copy the content