Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Both nodejs and flask can barely hit 10k requests per second even if it doesn't touch database:

https://medium.com/@tschundeee/express-vs-flask-vs-go-acc087...



Node is a solution for network bound problems NOT cpu bound problems. Fibonnaci is very much in the latter category. Horses for courses


... if your web app is a fibonacci number generator..


In case it wasn't clear, I am saying 10k req/sec is low...

(compared to go/java which is 5 times as fast)


Well yeah, Node processes run a single thread (of user code). There's no concurrency there. Go and Java will use all available cores of the system.

A better (and likely more realistic) comparison would be to actually hit the database: node is async by nature so would better handle concurrent requests.


And minikomi's point is that a fibonacci number generator is ill suited for nodejs, so it is expected that this webapp doesn't achieve high rps.


If you're at 10k req/sec while processing nothing you can't possibly achieve a higher rate on real workloads. It establishes a hard cap on the best case scenario for a node server that manages to parallelize all IO work.

I am not trying to make any particular point here. In my original comment I was just providing a bit more context on whether or not nodejs/python can comfortably handle 600 requests per second, and if so, how much more "scale" is left in this architecture.


A fibonacci number generator is by definition not "processing nothing". "Hello world" is closer.

In any case, in practice, node.js can process almost as many as requests per second as nginx and PHP in common configurations, after you've implemented clustering - what other servers do by default. It's a dozen or so lines of code in node.js.

I expect the same is true with Flask, except that Flask's default configuration is even worse - Flask's built-in HTTP server is for development purposes only, and is similarly single-threaded. It's a WSGI framework, and deployment needs a proper WSGI server, of which there are a number of choices - gunicorn or uwsgi are common.

Using the default configuration is not a particularly good way of benchmarking the limits of a framework, because many of them are set up to be easy to work with by default, not to be fast. If node.js clustered by default, you couldn't use global variables for state and might have to deal with race conditions. Flask doesn't ship with a web server just because there's so many good choices available depending on what you need.


Out of curiosity what would be a healthy RPS range? I've always assumed anything over 1000+ is acceptable.


For this application where he was getting "hundreds of requests per second" at 500M users, if he suddenly grew another 10x he would've had to start scaling horizontally instead of running on just one machine.


according to my work, anything above 10rps is fine.


For internal business apps - or even b2b tools - 10 is probably plenty. There's a lot of premature optimization around.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: