There are frameworks that can handle over a million requests per second (simple json output) or at least several 10,000 requests per second if DB queries are performed (even though on different hardware, but just compare the scale).
https://www.techempower.com/benchmarks/#section=data-r20&hw=... https://www.techempower.com/benchmarks/#section=data-r20&hw=...
I think, if performance is a strong requirement, they were better off with another programming language.
They measured that the app spends about half its time waiting for the database.
There seems to be a whole lot of things to do before thinking of changing basic plumbing.
I would imagine that even with Python, a fully asynchronous framework would be far better at requests-per-second than Django, but would require sacrificing features, since nothing async is yet at feature parity.
Just read the article...
(enjoyed the post, and I like your philosophy of using simple widely available tools; I'm hopeful that any changes you're able to provide back will have a kind of community-benefit flywheel effect)
My first instinct is that the number of requests seems really low, but I have no idea about the complexity of each request. To me that is kind of a crucial information to actually evaluate anything in the blog post.
I'd be curious to see if there is a meaningful gain from that approach, if anyone has done the transition before.
The number of requests still feels slow, and it isn't clear to me from the blog post whether that is DB limited or CPU limited on the application servers. Even with writes on each access Postgres should still be bored at that kind of load.
I think there must be some misconfiguration there. otherwise, the throughout should not be that low.
If possible, the author should setup a demo (contrived query, but similar to production scenario). From there, others can give valid suggestion or improve the code and configure.
[1]: https://www.techempower.com/benchmarks/#section=data-r20&hw=...
100/s is slow
But in this case the interpreter speed is largely irrelevant. This is a complex project and more than half the response time is spent waiting for the database (which is C++, not that it matters either)
We got some better performance for an internal service than Gunicorn after trying different gunicorn configurations to improve the performance of our workloads. We now mostly run (read depend) one instance of that service instead of 3 like we used to before.
[1] https://arunrocks.com/a-guide-to-asgi-in-django-30-and-its-p...
I’d be curious to hear more about this. Was is just degraded performance or something else?
Generally we've found that having basic control over the hosting infrastructure is important. We still depend on Azure's LB's and other infra for keeping things available, but having the actual instances our code are running on accessible makes a lot of things easier.
less than $100/mo buys you an absolute beast of a VPS at some hosting provider that could alone handle way more than that.
