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 (thank goodness), but I think this will meet the blog's needs quite well.

9 responses to “blog optimizations”

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

    • OK ;)

      * bumped the memory allocation for the web VM up to 1024M
      * installed memcache: sudo apt-get install memcached php5-memcache
      * fetched memcached-backed cache code: wget -O wp-includes/cache.php ‘’
      * installed & configured wp-super-cache:
      * installed & configured w3-total-cache:
      * tested it all from a host on the local network with siege: siege -A “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)” -c10 -r100
      * found the point where the system would enter swap thrash (-c50 -r10 or so) and modified throttling so that requests beyond that threshold would be rejected. I used shorewall:
      $ grep -i Web.*net.*FW /etc/shorewall/rules
      Web/ACCEPT net $FW – – – – 10/s:15
      * modified MPM settings a bit:

      <IfModule mpm_prefork_module>
      StartServers 5
      MinSpareServers 5
      MaxSpareServers 10
      MaxClients 20
      MaxRequestsPerChild 90

    • 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 ;)

  2. 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).


    • 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.


  3. 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.

Leave a Reply