Wordpress. A word that stands for an established system, a nice backend to write and edit articles but also for a frontend which performs slow and heavy. On cip-labs I developed a cache for this system. The cache is very easy to install and does the caching in a very very simple way.

How it works

It works quite simple. I had modified the index.php of the wordpress installation. When a request comes in,  an object of CIP_WP_Cache would be created. This object represents the cache. It looks up in the cache directory and tries to find the file which is requested. The files were stored in a directory defined in CIP_CACHE_DIR. If the file was found in cache (files are named like md5($_SERVER['REQUEST_URI'])), the cache will responds it and then shutdown. The benefit of doing so is, that the wordpress engine would never reached during the whole request. But if the file was not found in the cache, the CIP_WP_Cache captures the output buffer of the wordpress engine and stores the result in it’s cache. For the next requests to this URI, the cache responds the file from the cache.

That’s it, it does nothing more or less. Of course, you need more functionality to control the cache and I will write a plugin for Wordpress which allows you to control the behavior of the cache. In the following I have a few benchmark results from my recent tests:


The results of the benchmark are clear. The heavy wordpress engine (avg. 13 MB ram usage) battles against a static file. I used ab -n 1000 -c to test the performance of the cache. I think the specifiation of the benchmark environment is regardless for this benchmark.

without cip-cache

  • time taken for requests: 311.653 sec
  • requests per second: 3.21

with cip-cache

  • time taken for requests: 1.897 sec
  • requests per second: 526.88

To sum up this benchmark you can see, that cip-cache serves faster. The cache works with a TTL directive (called CIP_CACHE_TTL), which you can configure in the cip-wp.php file. When cip-cache creates the cache file, it runs through the wordpress engine and after that, it writes the output buffer to the cache directory.

How to Install

At first, you have to overwrite the index.php from your Wordpress installation with the index.php from the source package (copy both files (cip-wp.php and index.php) into the directory which includes the index.php). The second step is to configure the cache with the CIP_CACHE_DIR and CIP_CACHE_TTL directives. Create a directory for the cached files and make sure, that you have set all required permissions (777).

  • CIP_CACHE_DIR: should be the directory that includes the generated cache files
  • CIP_CACHE_TTL:  time to life (in seconds)

That’s it.


  • control the cache behavior with a small Wordpress plugin (clear cache [item or all], set TTL, set cache dir, add/remove routes to control paths to cache)
  • cache just for readers and not for admin’s or users to avoid html fragments that should be not displayed on the readers view

goto: project page

goto: download version 1.0.0


For a long time I’m really intrested in performance aspects of content management systems and smarter blogging systems and that’s the reason for the decision to test some of the popular systems on a workbench and to get some technical information about these systems. The test was quite simple. I installed the packages on my sandbox server and added a function (cip-bench()) to the installation. Then I run the index page with the default template and configuration. The data I got from the test was limited on the raw index page after the installation. I picked up 5 aspects for the test. The first one was the memory usage of the system, the execution time, executed database queries, how many database tables exist and the last parameter shows how many files are required. It is interesting to see how different some CMS solve their tasks. I was suprised of some results for example 399 database queries of contenido.

To sum up this test I was impressed by chyrp. It’s delivered with an elegant backend and I think it has got a lot of potential to become more popular and famous. The memory usage of wordpress seems to be improved in contrast to previous versions.


name memory avg time queries tables required files
chyrp 5.556 MB 0.3 – 0.5 7-10 8 63
geeklog 6.97 MB 0.6 – 0.7 59 50 38
serendipity 6.773 MB 0.5 – 0.55 11 21 48
textpattern 2.823 MB 0.2 – 0.3 21 17 12
wordpress 12.044 MB 0.4 – 0.6 15 11 73


name memory avg time queries tables required files
cmsmadesimple 7.543 MB 1.1 – 1.48 38 – 52 52 92
contenido 9.562 MB 0.6 – 0.9 254 – 265 (399) 76 123
impressCMS 10.938 MB 0.5 – 0.6 53-55 57 139
joomla 6.289 MB 0.7 – 0.8 7 – 11 33 127