We’ve been working on a huge, soon to announced project, that involves Wordpress MU. I’ve been working for months on this, and I’ve really got stuck into the deepest and darkest parts of Wordpress MU. I’ve got to say, I’m a fan of Wordpress. The code is nice to work with, its well documented (for the most part) and it just works. As opposed to some of the other open source CMS and blog engines out there.

But, I just kept hitting performance bottle necks with it. Which, is to be expected when you’re serving heavy php pages with lots of MySQL reads. I went down the well traveled road of installing various caching plugins (WP Super Cache was my favorite), and they made a huge difference – but still, performance not quite where I felt it should be. This project is for a very high traffic site, so its really worth squeezing every last percentage of performance out of your code.

I was about to roll out some kind of reverse caching proxy, such as Squid or a server cluster when I started to debate changing out Apache for something lighter and faster. I’d heard good things about lighthttp and Nginx. I was a little nervous, as this is a live production site, but the performance gains could be worth it. When I learned that wordpress.com uses Nginx, that sealed it for me. Nginx it is then!

So, after much trepidation, I pulled the trigger and started to rebuild the app on a new server running Nginx (a LEMP stack, as opposed to LAMP). It took me a long and arduous 2 days to get everything back up and running (on a dev server first, customers didn’t experience any downtime), but man, first impressions blew my mind. It is way faster, especially for serving images. I intend to write a detailed post about the setup, but for now here is a graph that shows a quick comparison. The site is monitored by Site24×7, and the following graph shows the ping times for a given page. This page had very simple content, so I wasn’t expecting much. But, see for yourself. Its a big difference, note that the site was cached before and after the change it was not cached. Once I roll out caching on the new nginx server then it will be fair comparison, i.e. this graph makes it looks like nginx is slower then it really could be.

Some quick lessons learned, the hard way.

PHP sessions did not work, I spent hours trying to get them to work under nginx but then just decided it was time to roll out a MySQL based session system, its more secure and portable and only took about 2 hours to get up and running on the live site. I’ll post a how-to article soon.

If images aren’t being served correctly it could be because FastCGI php cache’s directory needs to be owned by the same user that Nginx is running as. Obvious I know, but still, not so obvious at the time. Well, lots of things aren’t obvious at 2 in the morning!

I promise I’ll post more details shortly.