How do I determine if I should ask for additional CPU cores on my web server?

Question

I have a website that has approximately 300 users and I get about 1000 hits per day. Due to an upcoming event next week, there is a possibility of all of a sudden getting between 20 and 25 thousand users per day, with between 60 and 70 thousand hits. I currently have 2 CPU on a semi-dedicated hosting. My host is aware that there could be a bump in users and said that he could quickly up the CPU as needed. However, there's also an option of prepaying for additional CPU. As the 20-25K users would be purchasing access to my site, I definitely want that aspect to go smoothly. Is there anyway to tell whether I should purchase access to the additional CPU?

Additional information:

1) A screen shot of my usage of the last week (the spikes are nightly database/file backups and won't increase with the new users)

2) I use a CDN for images, javascript, css

3) My "purchase access to the site" script takes about 2 seconds to run as it's interacting with my payment processor.

4) Each page that the user accesses requires a check via php to see if they're logged in, and 1-2 trips to the database: typically page loads are under 5 milliseconds.

If I'm being neurotic and shouldn't purchase more CPU, then that's fine for someone to tell me so. However, if this seems like a case where I should make the purchase, it would be great to know what number of additional CPU cores would be appropriate.

Answer 1

I think the approach here should depend on the nature and timing of the traffic:

• If you are expecting a curve increase with traffic spread throughout the day then 70000 hits/day works out at just less than 1 hit per second, and with a page processing time of around 5ms this should be no trouble at all.

• If instead you are expecting a spike increase with the potential of those 70000 hits all within a period of an hour for example, then this works out at around 20 per second, which may or may not be an issue for you depending on a whole variety of things.

When scaling up, increasing CPU will only get you so far in terms of performance, but for capacity you should consider scenarios such as being able to respond to requests simultaneously through the use of load balancing and multiple VPS instances.

If your website can be adapted to work with solutions such as Amazon Web Services or Google Cloud you could simply fire up additional instances or use auto-scaling as required for capacity and just pay as you go for bandwidth/diskspace used etc.

You mentioned using CDN for static resouces, however you could also split your site into two, and use different hosting environments/providers for each:

• Your main domain www.example.com with the pages that the public see that rarely change, could be hosted either (a) with two or more shared hosting providers, ideally ones that offer generous or unlimited bandwidth, and setup an address (A) DNS record to each host; or (b) on Amazon Web Services, using a stack of S3 for static files, EC2 for your dynamic processing (PHP/ASP etc), RDS for your MySQL databases, ELB for your auto-scaling, CloudFront for CDN/acceleration etc.

• Your subdomain secure.example.com (perhaps with an SSL certificate?) that needs access to your database for when people are accessing pages tailored for them, eg. login areas, order/payment processing, subscription service areas etc, could be kept on your existing hosting setup. By separating the two you should have more resources available to serve these higher importance requests.

In this way if you had problems with one of the above the other would still work fine. Solutions like this used to cost a fortune and require a lot of expertise but these days it can be accomplished on a minimal budget by one person who is happy to experiment and learn, all the knowledge required can be found in the Amazon or Google documentation, or if you chose to use multiple shared hosts you wouldn't require any additional knowledge (though this may cost more as pricing is typically fixed).

While it can be considered good practice to test how your site copes under pressure with stress testing, you should be very wary of doing this if you do not own the infrastructure and if it is not soley used for operating your website since otherwise it could impact on other customers services, breach the terms of your hosting contract, and leave you liable to prosecution for causing what could be considered a denial-of-service attack by the service provider if they have not authorised it in advance. Instead of stress testing the 'live' hosted environment, try to replicate the setup in a virtual machine on your PC and see how it copes while stress testing it 'offline'.