Authorized Network Testing

Website stresser for the pages that carry revenue

Most sites do not fall over on the home page. They fall over on the third click, in a checkout that writes to three tables while a payment provider is already slow.

Authorized testing only - you must own or have explicit permission to test.

What a website stresser actually sends

HTTP requests at a rate you choose, at the URL you give it. It is not a browser: no JavaScript, no images, no CSS. That distinction matters more than it sounds. A page that feels slow on a phone can answer in 200 ms at HTTP level, because the delay lives in scripts and assets. You are measuring the server and the path to it, not the visitor's device.

Start where money changes hands

Start where money changes hands: product page, add to cart, checkout API. Then the pages that fan out to a database: category listing and search. A cached home page will absorb ten thousand requests per second while checkout dies at three hundred. Run each page as its own target so the failure has an address instead of becoming one blended average.

Running it against production

Your own site is the only place the numbers mean anything. Do it off-peak, start at a rate you know the site handles, raise in steps of twenty percent. Watch the 5xx rate rather than the CPU graph: a site returning 503 in 40 ms is not healthy, it is fast at failing. Agree an abort threshold with whoever owns the database before the run starts, and keep the packet side separate with a DDoS stresser run rather than blending both layers into one test.

Reading the four numbers

Four numbers: sustained requests per second, p95 at that rate, 5xx rate, time to first byte. A healthy run has a flat p95 and a 5xx rate near zero as the rate climbs. The rate where p95 doubles is your knee, and everything above it is a number you can quote in a meeting but not defend afterwards. The report downloads from the panel when the test ends, so the numbers leave with you.

What breaks first on a busy site

PHP-FPM or Node workers, then database connections, then anything calling a third party. A WordPress install with twenty workers stops at twenty concurrent requests, not at a round number. MySQL ships with max_connections at 151, and a pool that opens one connection per request reaches it long before the CPU looks busy. Both limits are configuration, not hardware. If the server side holds, the next question is the path, and IP stresser free together with the IP booter breakdown covers that split.

What it cannot see

JavaScript, logged-in sessions and the payment provider. A real checkout validates the card in the browser, redirects to 3D Secure and comes back through a webhook. None of that sits in your request path. Pair the run with a scripted checkout before launch and treat the stresser result as the server-side half of the answer; a free stresser run makes a reasonable smoke test of that half.

When a script does the job better

k6, Locust and JMeter script a journey: login, search, add to cart, pay, with think time between steps. That is the right tool for "will the flow hold". A stresser answers a narrower question: at what request rate does this endpoint stop answering correctly. Use both, script first, and never ask one to do the other's job. The layer 7 stresser tab holds the request methods this page assumes.

Keeping the evidence

Only systems you own or are explicitly permitted to test. The rule is applied when the target is added and again when the run starts, and it is not lifted for a free account or a single page. The stresser panel shows the record afterwards; online IP stresser and free DDoS stresser reach the same point from the browser and packet sides.

Website Stresser questions

Can I stress test my own website?

Yes. Confirm you own the target when you add it and the run is authorised; the same check runs when the test starts.

Will it take my site down?

If you ramp past the knee with no abort threshold, yes. Start low, raise in 20% steps, stop at the first sustained 5xx.

How many requests per second should I ask for?

Take your busiest hour, divide the request count by 3600, then multiply by three. That is a defensible starting point.

Does it test the CDN?

Requests go to the URL you give it, so a warm cache absorbs most of them. Bypass the cache to reach the origin.

How long should a run be?

Ten minutes shows a knee. Short free-tier windows show whether the endpoint answers at all.

Does the panel book the window?

Yes. Target, method, window and rate are set in the <a href="/en/stresser-panel">stresser panel</a> before the run starts.

Run one real stresser test before you pay

Trial credit from live support or the $0 Basic plan, same panel and same method list. The report matches what the paid plans produce.