Every website owner dreams of viral traffic. But when that traffic actually hits, the dream often turns into a nightmare: “Error 500: Internal Server Error”.
Learn more about WordPress speed optimization at WPPoland. Here is the story of one of our early “Fuckup Night” sessions at WordUp, where we analyzed why a client’s e-commerce site crashed during Black Friday.
1. The @admin-Ajax culprit
It turned out that a simple ” Visitor Counter” plugin was sending an AJAX request (admin-ajax.php) on EVERY page load.
- Traffic: 1000 users per minute.
- Result: 1000 PHP processes spawning every minute.
- Server: CPU at 100%, RAM exhausted.
Lesson: Avoid statistics plugins that rely on PHP/MySQL for every hit. Use Google Analytics or server-side log analysis.
2. Lack of object cache
The homepage was generating 150 SQL queries per load. Under high concurrency, the MySQL database became the bottleneck (locking tables). Implementing Redis reduced database queries by 95%. Menus, options, and transients were instantly served from RAM.
3. The PHP worker limit
On shared hosting, you often have a limit of, say, 10 concurrent PHP workers. If a script takes 1 second to execute, you can only handle 10 requests per second. If 20 people click at once, half of them get a 503 error.
Solution:
- Reduce execution time (HTML Caching, e.g., WP Rocket / Varnish).
- Move to a VPS with scalable workers.
Summary
A stable WordPress is a “dumb” WordPress. Serving static HTML via Varnish/Nginx is the only way to survive a real traffic storm.
