Why Websites Crash During Traffic Spikes (and How a Load Balancer Fixes It)

Short answer: a website crashes during a traffic spike when one server has to handle every visitor at once. Its CPU, memory or connection limit runs out, pages slow down, and then errors appear. The fix is to put a load balancer in front of two or more servers, check their health automatically, and add servers when the load stays high.

This guide explains why spikes break sites, which load balancer setup fits which situation, and what to prepare before a sale, launch or campaign. The examples use VavenCloud, but the ideas apply to any provider.

Why do websites crash when traffic spikes?

Every server has limits: CPU power, memory, and how many connections it can handle at the same time. On a normal day you stay far below those limits. When a post goes viral or a sale starts, visitors arrive faster than the server can answer. Requests queue up, pages get slower, and in the end the server times out or refuses new connections.

• One server is one point of failure. If it slows down or stops, the whole site does.
• Spikes are short. Paying for a huge server all month to survive a few busy hours is wasteful.
• The busiest pages are the ones that matter most. Login, search and checkout fail first, and they are where you lose money.

Step 1: Put a load balancer in front of your servers

A load balancer is the front door of your site. It receives every request and passes it to one of several backend servers. It also runs health checks: if a server stops answering, the load balancer stops sending visitors to it until it recovers.

When you set one up, you decide:

• The backend group: the servers that share the work, and the port they listen on.
• The health check: a lightweight page the load balancer requests regularly, and how often.
• The algorithm: for example Least Connections, which sends each new visitor to the server with the fewest active connections.
• Sticky sessions: an option that keeps a visitor on the same server, which helps if your app keeps a shopping cart in server memory.

On VavenCloud, the backend servers are your own cloud servers in the same region, and each server can sit behind one load balancer at a time.

Step 2: Choose the right load balancer plan

The load balancer is a machine too, so ask what happens if it fails. VavenCloud has three plans.

Where a region has more than one physical server, the two HA machines are placed on different ones. HA and Enterprise load balancers also use your private network, which VavenCloud creates automatically if you don't have one yet.

Step 3: Let auto scaling add servers for you

A load balancer shares the load, but if every backend server is full you still need more of them. Auto scaling watches CPU or memory use and adds or removes backend servers by itself, so you have extra capacity during the spike and don't keep it afterwards.

On VavenCloud it works like this:

1. You pick a load balancer, a backend group and one source server from that group.
2. VavenCloud builds a template from the source server.
3. You set the minimum and maximum number of servers (up to 8) and add rules based on CPU or memory.
4. When a rule triggers, new servers are created from the template and added to the group. When the load drops, servers are drained and removed.

Auto scaling works with all three load balancer plans, and it only changes your backend servers, never the load balancer itself. When you update your app, update the source server first, then rebuild the template. You can apply it to new servers only, or replace the running servers one after another.

What a load balancer cannot fix

Spreading traffic across servers helps only when the servers are the bottleneck. Check these too:

• A shared database. If every server talks to one database, that database can become the limit.
• Slow code or heavy pages. Large images and uncached pages cost the same on ten servers as on one.
• Outside services. A payment provider or email service can have its own limits.

The only way to know is to test. Run a load test a week before the event and watch CPU, memory and error rates.

A checklist before your next campaign

1. Run at least two backend servers behind a load balancer.
2. Set the health check on a light page that proves the app works, not just that the server is on.
3. Use HA or Enterprise for anything that earns money.
4. Turn on auto scaling and test the rules with a small load test.
5. Take a snapshot and schedule backups before launch.
6. Ask for a second opinion early. Open a support ticket if you want someone to look at your setup.

How this looks on VavenCloud

1. Create two or more cloud servers in the same region.
2. Create a load balancer and choose its plan and region.
3. Add a backend group with the port and health check path, and add your servers.
4. Optionally turn on auto scaling.
5. Watch the build progress live in the dashboard.

Every step is a form or a button. You don't need the command line to manage the infrastructure.

See cloud services

Frequently asked questions

How many visitors can one server handle?

It depends on your app, your page weight and the server size, so there is no single number. Measure it with a load test and watch CPU and memory while you do.

Do I need a load balancer for a small site?

If a short outage costs you little, one server may be enough. Add a load balancer when you run campaigns, take payments, or want to deploy updates without downtime.

What is a health check?

A health check is a request the load balancer sends to each server on a schedule. If a server fails to answer correctly several times in a row, it is taken out of rotation until it passes again.

What is the difference between Basic and HA?

Basic has one load balancer machine. If it fails, traffic stops until it is back. HA has two machines that share one IP, so if the Primary fails the IP moves to the Backup.

Can I change my load balancer plan later?

Not in place. To move to a different plan, create a new load balancer and point your domain to it. Enterprise plans can add workers up to 10.

Keep reading

• Managed vs self-hosted database: which should you choose?
• What to check before buying a VPS in India

Not sure which plan fits your site? Open a support ticket and tell us what you are running. Our team will help you choose.

Talk to our team