How to DIY stress test your website and know when it will crash

Imagine a business owner's classic nightmare: you've allocated $50,000 for a massive ad campaign with top influencers. Traffic is pouring in, and orders should be hitting records. Instead, you receive a barrage of angry messages, and your online store displays a blank page reading "503 Service Unavailable" or "502 Bad Gateway". The budget is burnt, your reputation is tarnished, and customers have flocked to your competitors.

To avoid this, you need to know the breaking point of your resource in advance. In this article, NineLab engineers explain in detail what load testing is, why websites "fall" in the first place, and how to run a basic stress test yourself.

What is a stress test and how does it differ from load testing?

Many confuse these two concepts:

• Load Testing: we check how the site handles the expected number of users. For example, we know that 5,000 people an hour will come on Black Friday, and we look to see if there are any slowdowns.
• Stress Testing: we intentionally "flood" the site with traffic until it breaks. Our goal is to find that point of failure (bottleneck) and see exactly how the system "dies" (and more importantly, how quickly it recovers afterwards).

Important rule: never run a stress test on a production database during peak hours. Ideally, an exact replica of your site (staging environment) should be deployed for testing.

Why do websites fall anyway? 3 architectural bottlenecks

Businesses often think a site falls because "there's not enough server capacity" or "too little RAM". In practice, 90% of the time, the problem lies deeper:

1. Database cannot handle the queue (Locks): Ten users simultaneously try to form a shopping cart. The database begins to lock records to avoid conflicts. The eleventh user waits their turn and times out.
2. Web server connection limits: Your Nginx or Apache is configured to handle 500 connections simultaneously (max workers). The 501st user simply won't be able to connect and will receive a 502 or 504 error.
3. Lack of caching: When 10,000 people visit the main page, the server has to generate it from scratch every time, requesting the menu, catalog, and prices from the database. This loads the CPU to 100% in a matter of seconds.

Tools for do-it-yourself testing

If you just want to get a general idea of reliability, you don't have to be a DevOps engineer (check out our guide on which monitoring metrics to use). There are simple utilities and cloud services for generating synthetic load.

1. k6 Cloud / Grafana k6

One of the most modern tools from Grafana Labs. A basic scenario is written in JavaScript. The service is convenient because it has a cloud version (allowing you to emulate a real spread of users across the globe) and produces beautiful, clear graphs of response times and failures.

2. Apache Benchmark (ab)

A classic console utility that comes with the Apache web server. Perfect for quick and rough checks. The program is so popular that it is already installed by default on MacOS or Linux (Ubuntu).

ab -n 1000 -c 100 https://your-site.com/

Where -n 1000 is the total number of requests, and -c 100 is the number of simultaneous connections.

In the report, we are primarily interested in these parameters:

• Failed requests: if this is not 0, it means your server could not handle even this small load.
• Requests per second (RPS): how many real requests per second your server can deliver.

3. Yandex.Tank

More serious "artillery" from Yandex. This is a powerful tool for high-load systems that can aggregate percentile reports. However, fine-tuning it requires basic technical expertise.

3 fatal mistakes in DIY testing

If you decide to do it yourself, beware of traps that will make your test results useless:

1. Testing static pages. Testing the homepage or an old blog article is pointless — chances are they will be instantly delivered by a caching system (or CDN). You need to test the "heaviest" dynamic routes: internal catalog search, adding goods to the cart, or checkout.
2. Shooting from a single point. If you run a script from your laptop over office Wi-Fi, you're testing your router's bandwidth, not your server. Proper tests are launched from distributed powerful servers.
3. Ignoring User Flow. A real customer does not visit a site 10,000 times a second. They open the catalog, click parameters, put an item "in the cart". A good stress test always simulates realistic user steps.

Result analysis: what to do next?

You launched the load and saw an error. The site crashed. What should you do?

A DIY test answers the question "will we crash?". But it never answers "WHY did we crash?" and "HOW do we fix it?".

If the system folded under traffic, it doesn't always mean you urgently need to buy hardware for thousands of dollars a month. Perhaps you just need to set up Redis to cache filter aggregations. Or rewrite one slow SQL query that locks other tables. And for serious ambitions — rebuild a monolithic architecture by implementing microservices and load balancers (similar to our high-load referral system case).

NineLab specializes in designing fault-tolerant (high-load) infrastructures. We don't limit ourselves to simply sending bots to a site. We conduct a deep technical audit of bottlenecks, build globally distributed infrastructures, and optimize nodes so that your resource can withstand even the most viral marketing campaigns. Don't risk your business before an important release — leave brand stability to the engineers.