I’ve been dabbling with a new caching engine for WordPress over the last few weeks. While WP-Cache does a pretty decent job, it falls short in a few areas, and it’s something I’ve been trying to fix. In particular, here’s what I don’t like about it:
- It relies on the entire WordPress engine to do it’s caching
- It doesn’t make use of proper HTTP caching headers
The problem with the first item is that even if you have a cache hit, the entire WordPress PHP core is parsed and partially executed. What that means is the caching system will always be limited by how fast the PHP parser is on the host machine, and how bloated the WordPress code-base is.
The second item is a little more subtle. If you request a page from a website using WP-Cache and it registers as a cache hit, basically WP-Cache reads a file from the disk and transmits it to you. This is a big gain, since you don’t have to do all the database queries over again to generate the original page. However, it’s sort of unnecessary to transmit the data to a browser if the data already exists already in the local machine’s cache. In order to take advantage of that, you have to do a bit more bookkeeping and set proper HTTP headers at various stages of the requests, something that WP-Cache hasn’t tackled yet.
With the caching engine I’ve been working on (called Viper Cache for now), I have basically solved both of those problems. To solve the first I removed the caching engine from WordPress and made it stand-alone, relying only on PHP itself. So when you register a cache hit, WordPress isn’t instantiated at all and an optimized PHP script serves the proper content. This works together with a WordPress plugin that manages invalidating parts of the cache whenever content on the blog changes.
In addition, proper HTTP caching headers are sent, so for most browsers, no data is even transmitted the second time a page is requested (what happens is the browser asks if the content has changed using an If-Modified-Since header, and the Viper Cache will respond with a 304 Not Modified if the local copy is the same as the remote copy). This results in a CPU and bandwidth savings. If the copy on the server has been modified, and the local cache doesn’t match the remote copy, the entire page is served again from the website cache.
I’ve been running it on my blog for about a week now, slowly ironing out the major bugs (and there have a been a few related to WordPress cookies and improper Content-Types). I did a fairly exhaustive benchmark a few minutes ago, and using my configuration on Media Temple, Viper Cache is about 2.5x – 3.0x faster then WP-Cache for serving pages (and that’s not even taking into account items that are already in the browser’s cache).
What I need now is a few guinea pigs to help iron out the last bugs. Is anyone interested in putting it on their blog and testing it out for a week or so? If so, drop me a comment.
[…] ViperCache (en proceso de creación) […]
Hey, I think it’s a great idea.
How does this compare with the new Super-Cache WordPress Plugin by Donncha? Have you tested that yet? It’s getting amazing reviews and has stood up to some serious heavy traffic, Digg-style hits.
Super cache relies on WP-Cache if I remember correctly. I think the performance of it would be similar in normal use cases to this one, however where super cache would routinely fall back on Wp-Cache in some instances (which it does if I remember), in those scenarios viper cache would still be faster. Plus, I’m adding one more optimization related to invalidating cache entries which should significantly increase the hit ratio.
Without a doubt you could handle a Digg with viper cache the way it is now. Execution time is minimal per request (far less than Wp-Cache), and you’d only do the work once per page in a several hour period.
[…] Posts WordPress Viper Cache AlphaHow To Make A Better WordPress – Entry #1: SitemapsStartupWeekend VancouverCrossroads 2.0 Alpha Now […]
[…] raiz del post de comparativa de plugins gestores de caché, Duane Storey, creador de ViperCache se puso en contacto conmigo para ofrecerme una versión beta de ViperCache y hacer pruebas con ella. […]
Hi Duane
Translation of the article on my blog here for anybody looking for an English version:
http://www.sprayfly.com/2008/02/20/testing-viper-cache-for-wordpress/
Looking forward to the release. This plugin seems to have real potential!
Jono
Hello,
I would really like to test It in one of my blogs, please send me details.
Thanks!
Hi Duane
I’d like to test your plugin. I think I was a guinea pig on some previous life and still like testing new things. 🙂
It doesn’t rely on Apache’s mod-rewrite, does it? I’m running WordPress-MU with lighttpd instead of Apache. Anyway if it does I can try to port the rewrite rules to lighty’s syntax.
Could you send me the details?
Thanks!
[…] Viper Cache para WordPress. vÃa: anieto2k Etiquetas: […]
I’d like to take a look at Viper Cache to consider implementing it for testing – thx
There is a thread on wp-hackers which you might want to weigh in on:
[wp-hackers] GSoC Proposal: Integrate WP-cache / WP Super Cache into WordPress
Aside, you may want to consider renaming your plugin from “Viper” because “Viper007Bond” is a very active member of the WordPress community, writes a number of plugins, and confusion may result 😉
Maybe he should rename himself 🙂
I’ll think about renaming it. I picked the name because the Dodge Viper is fast, and so it just sort of fit.
Actually I would be glad to be able to test it. Having many servers with WP installed on many very diferent setups, should give you some insight.
But I’m looking to coupling it with nginx+fast-cgi Since WP-Cache has some issues with it. and wp-super-cache needs too much rewrite voodoo.
Willing to test this out on a couple of my blogs.
If you could email me a copy that would be great.
Thanks 🙂
Hey, I haven’t had time to work on it in a while. I need a full evening to finish it off. As soon as it’s ready I’ll drop you a line.
Hi there,
I would be more than happy to test this out. If you have time maybe you could email me a copy. Many thanks, Karl
Hi 😉
sounds really great.. i could test it if you want, just send me a copy of it and i will test and compare it to the other solutions out there.. but your description sounds really good.
have a nice day
yours
Chris
WordPress Object-Cache 2.5…
Da sich in WordPress Version 2.5 der Object-Cache (wp-include/cache.php) geändert hat, d.h., es wird nun primär der Arbeitsspeicher anstatt das Filesystem benutzt, sind die aktuellen object-cache.php Erweiterungen für APC, XCache oder eAccelerator…
This cache looks very promising. One thing that wp really needs is dealing with db queries and other server side processing issues. Not to mention some really bad plugin architecture by some developers. We would be very glad to run viper cache as a trial and feed back our results.
Many thanks for your contribution to wordpress.
[…] and is a performance test and early review of Duane Storey’s latest WordPress plugin – Viper Cache. Viper Cache is a caching engine plugin for WordPress that can dramatically speed up WordPress page […]
Hi Duane,
I’m interested in testing your plugin. Recently I’ve tested two new cache plugins called “Hypercache” & “1BlogCacher”. The later is still running on my blog.
Both runs before WordPress engine initiates.
Let me know, if you want me to try your plugin. I would definitely be helpful in getting most out of it.
Hope for an early positive reply.
DG…
I’d love to help you out by testing your plugin. I’m always open to things that help sites load faster.
I would be very intrested in testing this out on the many wordpress and wordpress mu installs I have. I am using the latest dedicated cloud servers I have running. Which allows me to dynamically get CPU’s on the fly when needed.
I used to be a beta tester for Apple
Let me know
cheers,
Michael