Tag: viper cache Posts

I spent some time working on Viper Cache last night. It’s going to get a new name at some point, but it’s close to being done. I’m going to test it on this site for a while and see if I can iron out any bugs.

Well, this is interesting. I gave a few individuals an alpha version of the Viper Cache plugin I’ve been working on. It has just been reviewed on Anieto2k, one of the largest plugin sites. The author compared it against all the WordPress plugins available today for caching. The full write-up is available here. The article looks like it is in Spanish so you’ll just have to settle for the pictures. Based on a few guesses in the translation, it looks like Viper Cache is the lowest in memory out of all four, and allows around 1330 pages per second on the test machine compared to the second place runner up of Super-Cache at around 300 pages per second. I also want to point out that I seriously doubt their test takes into account (only because such a test doesn’t immediately come to my mind either) cache hits that are only […]

There are a lot of different ways you can increase the speed of your website, even if you have relatively cheap hosting. If you’re lucky, your blogging platform already has a caching engine built in (Drupal does). If you’re unlucky, and running something like WordPress, you have to do a bit more work. Caching makes a website more responsive because it takes an expensive operation (such as a long database query) and stores it so that next time it doesn’t have to recompute it entirely. For example, when you go to this website, normally Apache would execute PHP, parse the WordPress code, do some MySQL database queries, and then finally output the HTML page. Depending on the hosting service, this may take a long time. With a cache, the final HTML page is simply written to disk (or memory if a memory cache is being used) so that when that […]

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 […]