Stress testing self hosted nextjs
Unanswered
Common paper wasp posted this in #help-forum
Common paper waspOP
My nextjs app is running on docker (which is being managed by coolify/traefik proxy).
I'm stress testing my app using another vps using following command and result is:
wrk -t12 -c400 -d60s [mywebsite]
Lots of timeouts and app is not usable when i try to access it when stress testing happening.
I
So I don't think the issue is server resources as you can see.
What can be the issue then?
I'm stress testing my app using another vps using following command and result is:
wrk -t12 -c400 -d60s [mywebsite]
Running 1m test @ [mywebsite]
12 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.49s 366.80ms 1.96s 63.12%
Req/Sec 25.85 38.56 220.00 86.26%
5479 requests in 1.00m, 254.82MB read
Socket errors: connect 0, read 396, write 0, timeout 4728
Requests/sec: 91.17
Transfer/sec: 4.24MBLots of timeouts and app is not usable when i try to access it when stress testing happening.
I
htop on target server, my ram usage is 1.7gb/8gb, my 4 cpu cores are at around 40%~.So I don't think the issue is server resources as you can see.
What can be the issue then?
1 Reply
This usually isn’t CPU or RAM. With Next.js + Docker + Traefik, the bottleneck is almost always concurrency and connection limits, not raw resources.
A few likely causes:
Single Node.js process: next start runs one worker. Under 400 concurrent connections, requests queue even if CPU looks idle. You need multiple workers (PM2 / cluster / multiple containers).
SSR blocking: If the route is SSR (DB calls, auth, middleware), each request holds the event loop. Try stress-testing a fully static route to compare.
Traefik timeouts / connection limits: Default Traefik settings can cause read timeouts under load even when the app is “fine”.
wrk test is very aggressive: -c400 is huge for a single Node worker. Try lowering concurrency and scaling horizontally instead.
If you test a static endpoint and it handles load fine, the issue is app-side SSR + concurrency, not the server.
A few likely causes:
Single Node.js process: next start runs one worker. Under 400 concurrent connections, requests queue even if CPU looks idle. You need multiple workers (PM2 / cluster / multiple containers).
SSR blocking: If the route is SSR (DB calls, auth, middleware), each request holds the event loop. Try stress-testing a fully static route to compare.
Traefik timeouts / connection limits: Default Traefik settings can cause read timeouts under load even when the app is “fine”.
wrk test is very aggressive: -c400 is huge for a single Node worker. Try lowering concurrency and scaling horizontally instead.
If you test a static endpoint and it handles load fine, the issue is app-side SSR + concurrency, not the server.