How Much Traffic Does My Server Need To Handle? (3)
Worried about your server crashing or slowing down under load? No surprise - it's an affiliate marketer's nightmare.
Here are some tools you can use to test your server before you're spending real money on it. But how much traffic do you need to handle to make sure you don't crash?
Figuring Out Your Load Per Second
As affiliate marketers, we're used to thinking in terms of clicks, impressions or page views per day or per hour. But what matters from a server performance point of view is number of simultaneous users.
It's impossible to figure this out precisely, but you can get fairly close by examining your hourly stats. Then just allow a generous margin on top of that to account for traffic variance.
To do that:
- Go to your tracking software, and find the day in the past month when you had the most traffic.
- Select your per-hour stats for that day ("Day Parting" in Prosper 202)
- Find the highest number of page views per hour for your landing pages ("Clicks" in Prosper) that day. So, if the highest you saw was 3,600 clicks at 3:00 - 4:00, that's the number you want.
- Divide that number by 60.
You've now got a very rough approximation of how many concurrent users you were serving. This assumes that you're running a fairly normal affiliate landing page, not something highly interactive or long-form: if you're using landing pages where the user is likely to be interacting with your site for longer, divide by 30 or even 20.
Of course, you want to be sure that if you suddenly have a spike in traffic, your server can cope with that. So, to be on the safe side, multiply your concurrent users by 1.5. That gives you a fair margin for error.
You can now test your site with Blitz.io or Loadimpact (see our article here) using that many concurrent users, and get an accurate picture of how your site is holding up.
Estimating traffic for a new campaign
If you know roughly how many daily visitors a new campaign is likely to get you, you can estimate a number of concurrent users from that, to check your server can handle the load.
To do that:
- Divide the number of page views you're expecting on your landers by 24. That gives an average number of page views per hour.
- Multiply that number by 4 to get an estimated peak users per hour.
- From there, follow the instructions above to get the concurrent users you need to test
If your server can handle the load from a load test using those numbers, you're at least reasonably confident that you won't see problems when you set the campaign live.
EXAMPLE: Medium-scale PPV campaign
Bob's looking to start a new campaign with LeadImpact - but before he does so, he wants to know if his server's up to it.
He's going to be running a broad adult campaign, so traffic is limited only by his budget. He's initially planning to spend $500pd testing the campaign, and he'll be buying clicks at $0.02 each.
That means he's looking at 500/0.02 = 25,000 page views a day. Dividing by 24, that's 1042 page views an hour. And we multiply by 4 to get a maximum likely peak traffic of 4166 page views in a single hour.
4166/60 = 69 concurrent users. We multiply that by 1.5 just to be sure, and get 105 concurrent users.
If Bob's server can handle 105 concurrent users without slowing down, he should be fine to run his campaign. Otherwise, it's optimisation time!
So, he heads off, and uses the Handy STM Guide To Load Testing with those numbers
Found this guide useful? Confused about anything? Think my numbers are odd? Let me know below!
You have to remember that these numbers are not entirely right.
Each user will be requesting image files and javascript ect for each lander so you need to handle 12-14 times more user volume than you simulate or test for.
Offloading to a CDN or using a Varnish caching server in front of sites like wordpress will help with this.
It's a good point - Blitz just tests the main page, not all the associated static content, and that does indeed result in more connections. However, I did factor the multiple connections in to the calculation above.
[Note: intense geekery follows! You don't need to know this stuff to test your server.]
For starters, you don't actually need as many connections as there are pieces of static content on the page. Whilst the HTTP 1.1 RFC proviso that each browser should not maintain more than 2 connections to a single server has long since been abandoned, modern browsers maintain a maximum of 6 connections (with the exception of IE10, to be fair, which maintains 8). That means that you need 6 connections per client, maximum. My LPs tend to contain at most around 5 pieces of static content, but I know a lot of people use Photoshop slicing, so let's assume that those 6 connections are all going to be fully used.
The concurrent users calculation up there works as
(Maximum hourly visitors * time on site in seconds)/3600 (seconds in an hour)
I assumed the worst case - that we're looking at an unoptimised Apache install with its hilarious 10 second KeepAlive default. (I was actually wrong - Apache 2's more sensible and assumes 5 seconds). However, we've also got to multiply our visitor count by 6 for the 6 connections.
So, we end up with
(Maximum hourly visitors *6 * 10)/3600 (seconds in an hour)
Of course, this all assumes that your main LP is the slowest thing to serve of all your linked content. I tend to think that's a reasonable assumption - it's almost certainly invoking PHP on your system, and probably also MySQL, wheras the images are simply coming across an HTTP connection.
However, if you want to be really precise about testing, there is a way to test all your files in Blitz.io. I'm just adding that into the testing tutorial now - thanks for pointing out the static files issue.
It's also true that you do need to account for database load from multiple hits, so I'm adding a note on that too!
Home > Hosting, Servers & Security >