As you can probably tell, I happen to think WordPress is the volkswagen of blog software. I mean that in a good sense- in the old days, a volkswagen was built for people (folks-wagon, duh), and could be tinkered with using only one size wrench. So they got a lot of mileage out of them. Now, Wordpress is pretty awesome, and I’m using it whereever I can find an excuse.
Some intrepid bloggers are putting together a WordPress Podcast… looks promising!
Now that you’ve been trending your webserver with mrtg and you have a baseline of performance statistics, your mind is naturally shifting to focus on the future. In the beginning, Disneyland won acclaim because it would pre-emptively replace parts. If an axle had an expected lifetime of 5 years, they would replace it at four years. So now you want to be able to predict failure, so you’re not down at the colocation at three in the morning with a stack of CDs hoping your backup will restore right, before you’ve lost so much business that the backup is moot.
Ab and ab2 (Apache Benchmarking) are generally included with an apache install, although I remember seeing options for apache-bench in the results of ‘yum list | grep apache’ . Using them, I generated some answers; currently one server handles 10 connections per second without too much additional load, for instance.
You can use httperf to to do x number of connections per second, for y number of seconds, and see what happens to the load. On that server, 10 cps for 30 sec resulted in a load increase of < 0.1, which was heartening to me; I didn’t take the server offline and so this was an _increased_ load (for a sunday afternoon), not a straightup load of 10cps.
You might try installing php-eaccelerator, which is a free and simple download. I did this on another server, took some metrics and restarted apache, then took the same metrics again. Then I shortened these two files to the same length (150 data points) and put them on the same graph for comparison. After about 150 datapoints, the two graphs are pretty much the same, which I think is a result of the primitive requests I had configured.
The column I am displaying in this graph is the ‘delay’ in microseconds; you can see that php-eaccelerator reduced the delay considerably. php-eaccellerator is only good for php, however, and so some sites ( for instance, ones that use Perl) won’t benefit.
What other good ideas do you have for predicting the point at which your servers will need upgrading?
