What a Traffic Spike Actually Does
A local station runs a ninety second segment about your shop on a Tuesday at six o'clock. By 6:12 the site is returning an error page, and by 6:40 it is fine again, which is about when the people who saw the segment have given up. Almost everybody calls this a traffic spike and asks about a bigger plan. Nearly every time, the visitors were not the problem.
Count the people who actually showed up
A ninety second segment on local TV, or a post that does well in a Buffalo Facebook group, is worth somewhere in the low thousands of visits in the half hour after it runs. Call it 3,000 people, which is a very good day for most shops in this town. Spread across thirty minutes, that is 100 people a minute. Fewer than two a second.
Two requests a second is nothing. A plain page of 40 kilobytes served twice a second is 80 kilobytes a second of bandwidth. The laptop you are reading this on could do it without the fan coming on.
So when a site falls over at 6:12 on a Tuesday, the honest description is not that 3,000 people were too many. It is that this particular site could not do two of anything per second.
The site charges full price for every visitor
Load a typical small business page built on WordPress with a page builder and a dozen plugins, and the server runs somewhere between 60 and 90 database queries to produce it. That is a normal number, not a broken one. The menu, the site options, the theme settings, the recent posts, the related products, the plugin checking whether it should show a banner. Each one is a question, each one gets an answer, and PHP assembles the page out of those answers.
Here is the part worth sitting with. Every one of those answers was the same as the last time somebody asked. Your hours did not change between 6:00 and 6:12. Your menu did not change. The site asked anyway, once for every person who walked in the door.
At 100 visitors a minute and 90 queries each, that is 9,000 database queries a minute to hand out information that has been sitting still since Thursday.
Nothing on that page had changed since Thursday, and the database was asked 9,000 times a minute anyway.
What a traffic spike actually does
When the site is quiet, that work is invisible. Ninety queries at a few milliseconds each, plus rendering, comes to a page that takes maybe 1.2 seconds. Nobody complains about 1.2 seconds.
Now run thirty of them at once. The queries stop taking a few milliseconds, because they are waiting on each other, on the same tables, for the same connections. A query that took 40 milliseconds alone takes 300 in a crowd. The page that took 1.2 seconds takes six. Nothing about the server changed. The work got in its own way.
Your plan gives you a fixed number of PHP workers, often 20 to 40 on a shared account. At two requests a second and a 1.2 second page, about three workers are busy at any moment. At a six second page you need twelve. At ten seconds you need twenty, every worker is occupied, and request twenty one waits in line. The line grows faster than it empties. The people waiting hit refresh, which puts a second copy of their request behind the first. That is the 502.
This is why the crash rarely lines up with the peak. Load does not add to your response time, it multiplies it, and the site goes over the edge a few minutes after the moment everyone was watching.
A bigger plan moves the cliff, it does not remove it
The instinct the next morning is to buy more server. It works, a little. Twice the memory and twice the processor gets you roughly twice the workers, which moves the failure point from 3,000 people to something like 6,000.
The cost per visitor did not change. It is still 90 queries and 1.2 seconds, still the same answers, still assembled from scratch for every person. You have bought a bigger cliff to fall off, at three or four times the monthly bill, and you will find it the first time two stations run the story. That is what we say to people who call and ask to be moved off shared hosting the morning after. The plan is usually not why the site went down.
There are real cases where more machine is the right answer. A store taking hundreds of genuine simultaneous checkouts needs it. Most of the sites we host here are a homepage, a services page, a gallery and a contact form, and none of that needs a bigger machine.
Caching is remembering the answer
A full page cache means the server keeps the finished page from the first visitor and hands the identical file to the next several hundred. The 90 queries become zero. The 1.2 seconds become 20 or 30 milliseconds, and often the web server answers before PHP starts at all, so it never spends a worker.
Run the arithmetic again with the same 20 workers. At 1.2 seconds each, twenty workers finish about sixteen requests a second. At 30 milliseconds each, more than six hundred. Same plan, same bill, same hardware.
It is a boring thing to turn on. It is on by default on our web hosting for small business, and it is the first thing we look at when somebody says their site is slow. The usual objection is stale content, which is fair, but the cache clears when you publish, and a page can be set to expire every ten minutes if that helps you sleep. Hours that are ten minutes old are not a problem. A 502 during the only television coverage you will get this year is.
Same workers, same bill, same hardware, and about forty times the room.
The pages that cannot be cached are the ones to think about
Some work genuinely has to run for each person. A cart, a checkout, a logged in account page, a search result, a form submission. Those cannot come out of a shared cache, and pretending otherwise is how somebody ends up seeing another customer's cart.
Look at how few of them there are. Of the 3,000 people who saw the segment, most look at the homepage, then the hours, then one gallery. Say forty of them fill in the contact form. Forty submissions across half an hour is one every forty five seconds. That is not a load problem on any plan sold anywhere.
Even a store gets most of the benefit. Cache the pages everybody looks at, leave the handful of real transactions to do real work, and there is room for them precisely because the other 95 percent stopped touching the database. If one of those transactional pages is slow on its own, the fix is that query, not the plan.
Hosts advertise 99.9 percent uptime, which sounds absolute until you multiply it out. There are 8,760 hours in a year, and a tenth of a percent of that is 8.8 hours the server is allowed to be down with nobody owing you anything. Tuesday was not part of those 8.8 hours. The server was up the entire time. It was busy answering the same questions 9,000 times a minute because nothing had told it to write the answer down. The station is not going to run the segment twice. The work that makes a night like that worth having gets done on a quiet afternoon, before there is anything on the line.
More from the blog
- What Unlimited Hosting Really Means
- The First Hour When Your Site Goes Down
- Why Your Business Email Goes to Spam
All posts are on the blog. For the step by step versions, see the domain and hosting guides.