Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I know this question is a little strange but I got lucky with an idea and I need some numbers to use for when I try to make a deal with a company. I'm wondering how much it'll cost me to run a site that's heavy on PHP and gets between 70,000 and 100,000 requests an hour on something like Rackspace's Cloud Servers. I have no idea how many servers I need or how much RAM each one should have. There will be a decent number of images on the site (probably something like 10,000 in the first couple weeks) and the site runs on about 2,500 lines of PHP code. I figure I should sign up for a CDN of some kind, although CDN In A Box is all I've heard of and I'm not sure it's necessary for a site that's already on a cloud platform. I've obviously never done anything like this before so I'm just looking to get an estimation of what I need for this massive site... Also, I use a database and I was wondering how that works - would I dedicate one of the cloud servers to running the database or would I need to put the database into each of the cloud servers? Thanks in advance...

share|improve this question
1  
CDN in a box is expensive and terrible. Check out something like Amazon CloudFront, Voxel or MaxCDN and you'll get much better pricing. Even if your network is global, there are still advantages to using a CDN such as reducing server load and bandwidth charges –  sam Jun 24 '11 at 8:03
add comment

1 Answer

up vote 4 down vote accepted

Firstly 100k requests per hour is nothing when it comes to modern hardware and software stacks, assuming the code's not astonishingly badly written anyway. It works out to be only around ~28 requests per second, which your phone might be able to serve :)

Now as for your setup you're going to want at least two machines, either setup in a live/live load-balanced manner or a live/standby situation. This will allow you to quickly deal with hardware failures, data corruption, misconfiguration etc.

If you think your site could grow much quicker than you're planning for now then perhaps you might want to adopt the very common three-tier system. This is where you have one or more database servers just doing that job, one or more application servers running your code and one or more web-servers simply doing the request front-end. This model allows you to scale out much more quickly and linearly but obviously requires you to design these splits into your code. This model works irrelevant of whether you're using a physical, virtual or cloud-based platform by the way - although database boxes degrade the most and quickest in a virtual/cloud environment due to the lower IO rates you get with these.

On top of that if you are intending to do a lot of static file handouts such as images/videos etc. then a CDN can make sense. They're not free of course so you need to do the maths to figure out if it makes more sense to keep things 'internal' or send them out to a CDN, there's lots to choose from (akamai and limelight are the two that leap to mind with good reputations), but only you can decide based on ave.bytes-per-request vs. number-of-requests vs. cost-per-byte/MB for both internal and external delivery.

One final thing, make backups - proper backups, not just snaps, and keep some of them off-site and do test restorations to offline hardware every so often to check they work. Seriously dude you wouldn't believe how many users we see on this site who didn't backup properly, didn't take some of them off-site or never tested them - and we never see them again, their businesses failed or they got fired - so take that seriously please :)

Come back if you need more help and if you're looking for people to help you grow please take a look at our 'careers' site (usually there's a link at the bottom of the page) as it's filled with people from this site and our sister site (stackoverflow - for coders) who may be in your area and happy to work with you.

Good luck.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.