Is Linode right for this scenario?

@goldencoults:

Hey there

• 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 mpmworker with modfcgid instead of mpmprefork with modphp, 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)

@hoopycat:

(fab salvatores home calzone linode ram1024 lucid appserver deploy bootstrap)

what kinda odd SEO is this ;)