blog optimizations

Thanks to some recommendations from Jeremy, Pierre and Jeff, this blog should be running a lot less slowly. I’ve installed memcached, set up wordpress plugins, tuned apache MPM parameters, tweaked iptables and tc rules and beaten on the blog with load testing scripts. It seems that it will now reliably handle around 10 concurrent requests and take less than 5 seconds to bring the page up. This is much better than the previous <2r/s 20s load time. I’m no amazon.com (thank goodness), but I think this will meet the blog’s needs quite well.

This entry was posted in blog, C.J. Insider, colliertech, customer experience, debian, Free Software, network saturation, Networking, performance, rate limiting, Software, traffic shaping. Bookmark the permalink.

9 Responses to blog optimizations

  1. kike says:

    Could you publish some more explicit data about which optimizations did you apply?
    Thanks.

  2. Steve Kemp says:

    One other thing you might consider is sticking varnish or squid in front of the machine as a proxy and cache.

    • Good idear. I’ve got one of those on the network, too… I just need to pass the http streams through it. But later. I’ve got to get some xen provisioning abstraction stuff to happen for the right now.

      I was thinking of you the other day, btw. I joined ##xen on freenode and dug through the xen-tools code while helping someone get xen-create-image functioning correctly. There was a failure to generate /etc/xen/domain.cfg or something. Anyway, we worked it out ;)

  3. Wouter says:

    Hi.

    Why do you run both wp-super-cache and w3-total-cache. Don’t they have the same approach for caching/serving?

    Kike’s idea about opcodecaching (whether it’s gonna be APC (Which will be built-in PHP6), xchage of eAccelerator, is up to you.

    Lastly, Steve’s remark on a reverse caching proxy is nice too. But please, give nginx a try and varnish, before entering squid as squid was never meant to be a reverse caching proxy in the very beginning :-) Squid is a huge beast and imho not as fast as it could be anymore (although wikipedia still uses squid too, since it can share cache over multiple nodes iirc).

    Wouter

    • Hey there Wouter,

      I’m using both because wp-super-cache didn’t seem to be caching the main page. I saw no reason to disable wp-super-cache. I can imagine that it might cause some superfluous caching and issues in the future, but I will address those as they come up.

      I’ve asked Adrian to chime in on your Squid comment.

      C.J.

  4. Wouter says:

    Oh by the way, for extra geek-points, you could try running something else than apache ;-)

    I’m running WordPress 3.0 on a virtual server, with 1 cpu, 256MB RAM and nginx 0.8/php with apc on fastcgi.

    If I turn on fastcgi-cache (so it doesn’t run through php for *every* request), it can be blazingly fast (I’m getting 189req/s with “ab -n 100 -c 5″) and even more if I raise concurrency.