Hey all,

I just inherited a project from an old friend. He has it on a 2Gb VPS at Slicehost. During peak times the server gets ~2,000 pageviews/second. Its a highly advanced Wordpress deployment with text heavy content(online newspaper type) that barely uses 3Gb of bandwidth a month.

However, it seems to drop like a stone during peak times. He has had to reboot Apache 4 times in an hour. I'm wondering what a reasonable Linode would be for this site as I'd like to migrate it over here. Thanks in advance.

Is that really pageviews/second? Let's say a pageview's data size (all components together) is only 5KB, which is probably much lower than reality. By my calculation, 3GB (I assume you mean bytes and not bits) of bandwidth would get used in under 300 seconds, and need a sustained outbound traffic rate of 80+ Mbps while occurring. I thought a Slicehost VPS was capped at 10Mbps, but maybe he had them raise his limit.

I guess that's certainly possible though 5 minutes of peak usage each month seems a little unusual - what happens the rest of the time?

Anyway, the short answer though is that there is plenty of tuning that can be done, in terms of appropriate apache configurations, proxying static content with other servers (like nginx), caching at the PHP or Wordpress level, or other ways of running PHP servers. You should be able to find several discussions here in the forums. One of the recent discussions that might give you some ideas is at http://www.linode.com/forums/viewtopic.php?t=6272

Your best bet is probably to grab a Linode for testing and just see how his particular configuration runs. You could start with a large Linode and work down, or from the bottom up. If he really does need to meet 2000/s peak load, I don't think the smallest plans will work, so I'd probably start with a 1024.

Assuming he's using a 64-bit build under Slicehost (though they've offered 32-bit more recently) I expect a 32-bit build under Linode would work on a smaller plan.

Oh, and BTW, it wouldn't surprise me to find that some of the apache tuning discussions here are just as applicable to his Slicehost configuration and might help improve current reliability under load as well.

-- David

Hi db3l,

I did some checking and misheard him. Turns out he used 3Gb that hour and the hour wasn't up, which was more than his previous weeks traffic. So as I said, the peak seems to last about 1-2 hours after an ad campaign and was generating ~2,000 pageviews/second.

I was also considering grabbing a 1024 here at Linode and going from there. We're probably going to need some data redundancy so I figured we'd pick up a 512 for that in the same centre.

We're hoping to move away from Slicehost so I'd rather not dig in with the current configs. We shouldn't have another ad campaign for another week or so, so I've got time to work. Thanks again for the tips.

Linode consistently beats slicehost in all the benchmarks I've ever seen done (there are some links to some of them somewhere around here, customer testimonial forums, perhaps?)

Linodes tend not to be CPU bottlenecked, if that means anything (which probably explains the high benchmark results). The ability of a linode to handle a given load is usually bottlenecked on how much RAM you have, and how you've configured your software. For example, Apache falling over under load and requiring a restart sounds to me like he's misconfigured Apache.

I was thinking Apache was misconfigured too. Its going to be the first thing I overhaul when the keys are handed over. He seemed opposed to WP caching because the site is dynamic, but the reality is that there are less than 15 new articles per day. That seems like a viable candidate for caching to me...we'll see though.

WP caching can allow registered users to see the dynamic content, requiring them to login, but serve up static content much faster to guests. The cache also gets updated when new posts are created (at least it's suppose to) so guests should be able to see new content not long after it's posted, just served from a static page instead of being pulled from a DB on every request.

All in all, it's a good thing

No argument here! First thing I'll implement for sure.