WordPress Under Kloxo + Lighttpd

Over the weekend, I was setting up the website for my first novel, which should officially become available around the end of the month, Gods willing. I was doing this on a server running the Lighttpd webserver, a (usually) fast and lightweight alternative to Apache that I have a lot of experience with. (Portions of this website are powered by Lighttpd.) The server, however, was running the Kloxo hosting suite, a spiffy, powerful, and flexible – but slightly eccentric – hosting setup similar to CPanel and Plesk and so on, only somewhat less sucky. (I hate CPanel with a burning passion, but I digress.)

One of Kloxo’s big virtues – and one of the reasons it’s becoming quite popular – is because it requires substantially less memory than other hosting setups, thanks – in part – to it’s use of Lighttpd.

When setting up WordPress under Kloxo and Lighttpd (on CentOS under OpenVZ, incidentally), I was a bit surprised by a couple of things I discovered, which I figured I’d share with the internet at large.

First of all, Lighttpd is very, very fast, and can scale really well. The Kloxo implementation, however, appears to scale quite well but is not terribly fast at all. Why? The way it handles PHP. PHP is run as a CGI or FastCGI process, which isn’t in itself a problem, but it’s run in such a way that a new process is spawned for every request. This affects performance, as you might expect. It also means that most opcode caches – Eaccelerator, APC, Xcache – are 100% useless under the Kloxo/Lxadmin system. You can enable Xcache from the control panel, but there is absolutely zero point in doing so. It does nothing, for all intents and purposes, and the developers should really remove it.

That in turn means that the (arguably) most popular caching and performance-enhancing plugin for WordPress right now – the W3 Total Cache – isn’t as beneficial as it could be under Kloxo. Oh, it installs and works just fine – but enabling Xcache caching has absolutely zero benefit, and actually slows down page generation times – on a single-core 2.4GHz machine – by about 0.2 seconds compared to “vanilla” WordPress. Page generation times are not the be-all end-all of performance metrics, but since Xcache is essentially nonfunctional, the plugin’s utility in these circumstances would seem to be marginal. You can still use disk-based caching, but since most people using Kloxo are using it on a virtual server, and virtual server disk i/o is always unreliable and generally piss-poor, I’m not convinced the whole thing is of any real benefit.

So, what does work? Well, I haven’t played with every plugin out there, but I’m quite impressed with DB Cache Reloaded, which shaves about 0.2 seconds off page generation times by minimizing SQL queries. (That’s 0.2 seconds per page compared to vanilla WordPress, so it’s about 0.4 seconds faster than W3 Total Cache.) And WP-Minify appears to help things a bit. The former of course uses a disk-based cache, so you’re uncomfortably dependent on disk i/o for raw performance, but it seems to offer fewer performance penalties than W3TC, so I’m cautiously optimistic there.

The important thing to keep in mind is that nothing PHP-based (or Perl-based, or anything else “dynamic”) is going to measure particularly well under Kloxo’s implementation of Lighttpd. All the “website speed checkers” are going to say your site is fairly slow, and page generation times are going to be pretty lackluster, because there’s a delay of a few hundred milliseconds in every request, while a new instance of PHP is launched. So if you’re super-concerned about what YSlow or whatever say about your website, Kloxo is probably not for you. That said, it should perform quite well – or at least consistently, if you want to be pedantic – under load, even given fairly marginal resources.

One other thing to note is that the default configurations that ship with Kloxo for both PHP and MySQL are pretty appallingly suboptimal, and you can see some marked improvements under most circumstances by optimizing them. You can only tweak MySQL if you have root access, but one of the dubious possible benefits to Kloxo’s otherwise peformance-crippling implementation of PHP is that the end-user gets a fair degree of control over their own personal PHP settings; if you know what you’re doing, you can squeeze a little extra performance out of your website by adjusting some of these.

I could move the website to a regular, Apache-based server. Or get another server of my own, and run a proper implementation of Lighttpd that supports PHP opcode caches. But, you know, it’s a crappy website that nobody’s ever going to visit, for a crappy novel that nobody’s ever going to read. More-or-less identical to 99.9999989% of all the other websites out there. I’m happy with the Kloxo setup; it’s easily “good enough” for what I need it to do – and probably just as adequate for whatever you need it to do, too.

Published in: Geekiness, General | on July 19th, 2010| 3 Comments »

Both comments and pings are currently closed.


  1. On 8/20/2010 at 1:00 am Neto Said:

    Have you missed the “Switch” button at the Kloxo panel? 😉

  2. On 8/20/2010 at 1:50 am Nemo Said:

    Of course not. 🙂 But the Kloxo implementation of PHP under Apache2 isn’t really any better than under Lighttpd. I’ve played around with that a little bit as well, and while both are, honestly, sub-optimal, Lighttpd seems to have (more benefits | fewer drawbacks) than Apache. (And Xcache is useless under both webservers.)

    Lest you think I’m ragging on Kloxo, I hate the way Directadmin implements Apache2, too. And I hate pretty much everything about CPanel. I heart Webmin as an end-user, but not so much as an admin…

  3. On 4/2/2012 at 1:02 am Jad Said:

    Very useful info, i hope since then updated Kloxo got some better enhanced for the WP