Hey there

We manage a website for an event which has moderate traffic levels throughout most of the year (like 2000 - 5000 page views a day) and then ramps up for the month of the event culminating in over 150,000 page views a day over the 4 days of the actual event.

At the moment our approach is to host the site on a shared environment for most of the year and move it onto a dedicated server for the month of the event. This process is annoyingly time consuming and doesn't offer any fallbacks if the dedicated goes down over the event.

So - I have read a lot of positive things about Linode hosting and how easy it is to manage resources and scaling.
I am thinking that we would set up a stand a lone mysql server as per:
http://library.linode.com/databases/mys ... sql-server

Some questions:

- the website is a database driven php/mysql site that is pretty well optimised but we have seen our cpu work very hard at times even on the dedicated server. Any ideas/recommendations as to the perfect Linode set up during the busiest periods (again - 150,000 page views a day on a dynamic site WITH APC caching)?

- given that I am based in Australia, do you think I will have problems with latency (we would likely use the Asia datacentre) and will I be able to get support if I need it during my working day?

Thanks for any help

Darren

The only issue you'll see with Tokyo as the DC depends on what upstreams/transit your ISP (and your users, if they're AU based) uses.

Some will get to Tokyo via LA and then back across the pacific, adding a butt load of latency. (For example, im in NZ, to get to tokyo1.linode.com, it's ~250ms latency)

Linode usually answers support tickets within ~15 minutes and there's a "community support" IRC channel on irc.oftc.net

I have a Linode 768 right now that averages over 500,000 page views per day. There are a few sites, all of them forums, so it may not be representative of what you can do with a Linode for your setup, but Linode can definitely achieve a lot if you set it up correctly.

A suggestion for your situation, you can resize a linode pretty quickly. It has to move to a different host machine (because only linodes of the same plan run on any given host, ie, the host is all 512's or all 768's), but the time there is just to move your disk images. So, you could run it on a 512 most of the year when it's slow and then at the busy time, bump it up to a 768 or 1024 or higher during that busy period, then back down afterwards.

Although, as Ghan_04 pointed out, with some tweaking, you could probably push your peak volumes out of a 512 as well, depending on how heavy your php is.

this forum site and the irc channel have some people who are pretty solid at tuning as well. Some things to consider:
use mpm_worker with mod_fcgid instead of mpm_prefork with mod_php, this works very well for me
use nginx instead of apache, many here go that route

if you stick with prefork/mod_php, make sure you drop your maxclients, the default is way too high and that's the #1 problem people post to the forums with

A couple quick thoughts:

- How much of your traffic consists of static assets (images, CSS, JS, etc, etc)? With "the default" Apache/PHP configuration, these are resource-expensive to handle. Moving these off to another web server or to something like Amazon S3 + CloudFront can help in a hurry. You might want to create another virtual host now, e.g. img.example.com, to be able to respond to this in a hurry later on.

- Is your database access mostly reads or writes? If you're read-heavy, you might want to do something where you shunt the writes off to a master database server and then have read-only slave(s) for your web server(s). This can scale out crazy fast. Also make sure you're using InnoDB and not MyISAM.

- Which part of the application is eating up CPU? If it's one of those do-a-bunch-of-SELECTs-then-process-the-data things, try seeing how much of the processing you can do with the database query itself. JOINs are your friends.

Also, APC is nice and all, but don't be afraid to whip out memcached, or even redis, for things that might benefit from it. If you're doing a lot of SELECT * FROM thingies WHERE doohickey = 6554321, you can cache the living daylights out of that. Keeping separate memcached servers lets you share this cache between your app servers, too.

... oh, and I'd be remiss in my duties if I didn't suggest chef, puppet, or some other configuration management system. This, combined with the Linode API, is like cruise control for awesome. "Well, looks like we need another web server" -> tappity-tap -> open beer -> done. Build out an entire cluster in another datacenter in less time than it takes a pizza to be delivered. -rt (fab salvatores home calzone linode ram1024 lucid appserver deploy bootstrap)

_________________

/* TODO: need to add signature to posts */

what kinda odd SEO is this