3 ms·
any reasonably multithreaded http server with nginx infront should easily serve 500+ requests per second, on something like a 5€/month hetzner VPS (x86, you get
by lionkor 3y ago
any reasonably multithreaded http server with nginx infront should easily serve 500+ requests per second, on something like a 5€/month hetzner VPS (x86, you get 2x the cores if you choose arm but thats a new offer so ill pretend it doesnt exist).
Only then will it cause significant delay. If your service drops connections at 500+ requests per second, something is off - You can configure quite the large accept backlog, like a few thousand, and you should only get an additional few ms delay per additional request.
If you're bottlenecked anywhere, it shouldnt drop connections until its like very very bad.
Thats assuming you need to access a DB or do other checks -- static content servers should start struggling on a 2-4 core system at around 10k requests per second, but that doesn't really matter for this.
- mhitza 3y agoCan you share your Hetzner VPS address, do you do your own TLS termination and can I test your endpoint with Apache benchmark? I ask because theoretical numbers, in my opinion, are thrown around to often, and when I hear thousands of responses/second on budget VPS's I want to see real life applications that actually handle that load. In my experience the difference between Apache and nginx is negligible, and if your service that runs on a $5 (or euro) a month VPS handles thousands of requests/second I'm going to be more than impressed when I see those numbers myself through a test.
- BenjiWiebe 3y agoI was actually going to test that myself, for you, with a $5 Linode. However, I spent about an hour fighting with siege/drill/hey and finally gave up. siege crashes and locks up all the time, as well as sometimes getting stuck for a minute or two between requests. hey reported 2 req/second for https, which I don't find believable either...