Election night, a storm warning, a viral news story, a registration deadline. When a WordPress or Drupal site gets a sudden surge, it rarely fails all at once. One resource runs out first, requests start queuing behind it, and pages slow from one second to ten to timing out. Scaling well is mostly about knowing which resource that will be, and making sure it is not the one you forgot.
What runs out first
| Bottleneck | Symptom | Usual fix |
|---|---|---|
| Uncached pages | Web servers busy even though traffic is mostly anonymous | Fix whatever is preventing page caching |
| PHP workers | Requests queue; response time climbs steeply | More web servers, or fewer expensive requests |
| Database connections and CPU | Slow queries pile up; errors connecting to the database | Object cache, query fixes, read replicas |
| Search | Search pages take seconds while other pages are fine | Dedicated search service instead of database search |
| Logged-in traffic | Portals, forms, or carts slow while public pages are fine | Object cache and capacity sized for authenticated users |
| Background jobs | Cron or queue work competes with visitors | Run jobs on separate workers or outside peak |
The first row is the most important. A site where 95 percent of anonymous requests are served from the CDN can take a surge that would flatten the same site with caching broken.
How horizontal scaling works
The standard design puts several identical web servers behind a load balancer, with an autoscaling group adding or removing servers based on load. For that to work, the web servers must be interchangeable:
- Uploads on shared storage. Media uploaded through one server must be visible to all of them. Shared file storage (such as Amazon EFS) or object storage (such as S3) handles this.
- No sessions on local disk. Sessions stored on one server log users out when the next request lands on another. Store them in the database or Redis.
- Identical code everywhere. Deployments build one artifact and roll it to every server, never edits on a single machine.
Why autoscaling can be too slow
Autoscaling reacts to metrics, and a new server takes a few minutes to launch, start, and pass health checks. A gradual morning rise is no problem. A spike that goes from normal to ten times normal in two minutes, such as results being posted at 8 p.m., arrives faster than new capacity can. For predictable events, raise the minimum capacity beforehand. Autoscaling then handles anything beyond the forecast.
Load testing that tells you something
A load test that requests the homepage over and over mostly tests the CDN. A useful test mirrors real behavior:
- A realistic mix of pages, including ones that will not be in cache
- Search queries, form submissions, and logged-in sessions if the event involves them
- A ramp that matches the expected spike, not a gentle climb
- Run against a production-like environment, and watch every tier: CDN hit ratio, web server CPU, PHP worker queue, database, and search
The goal is to find the bottleneck before your visitors do, then run the test again after fixing it.
A checklist for a known event
- Confirm the date, time, and which pages will draw traffic.
- Check that those pages are cacheable, and load test them.
- Raise minimum capacity ahead of time for web servers and, if needed, the database.
- Freeze code and configuration changes around the event.
- Move heavy background jobs away from the peak.
- Prepare a lightweight fallback page for the most critical information.
- Agree who is watching during the event and how to reach them.
After the event, review the numbers: peak requests per minute, the slowest endpoints, database load, and how quickly capacity responded. Those figures make the next event cheaper to prepare for, because you size from evidence instead of guesswork.
How eWay scales WordPress and Drupal
eWay runs WordPress and Drupal on autoscaling web tiers behind a load balancer, with shared storage for uploads, Redis for object caching and sessions, managed databases with read replicas where the workload needs them, a CDN in front, and a dedicated search service. For known peaks such as elections, enrollment deadlines, and major announcements, eWay pre-scales rather than relying only on reactive autoscaling, and load tests before go-live and before peak seasons. Changes are frozen around high-stakes windows, and the on-call engineer watches the environment through the event.
What to include in a support ticket
- The severity you would assign, P1 to P4 (see severity levels and response times)
- The event date and time, expected audience, and key pages
- For an active slowdown: the URLs, the time, and whether logged-in and anonymous visitors are both affected
eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time, and should flag known events as early as possible. See how to request support for all the options. Related reading: page caching and CDN behavior and database performance and read replicas. More on our WordPress and Drupal pages.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article