our application handles about 300,000 requests
per second at peak volumes, and responds in
under 10 milliseconds
Of course that is using PyPy instead of CPython. our application handles about 300,000 requests
per second at peak volumes, and responds in
under 10 milliseconds
Of course that is using PyPy instead of CPython.Where I get really frustrated with the 90s-era dynamic scripting languages is not when you are "filtering one list" or "serving JSON out of the DB", but when you're trying to do all kinds of CPU-type work in one page, with numerous (unavoidable) DB accesses and filtering and transforming etc etc. You can get into "seconds" surprisingly quickly, since it is, indeed, a fairly slow language.
It is likely that rewriting this code in C++ or something could get another 5-10x out of it even over PyPy, probably even more if we really start going crazy with optimizations, but at much larger investment of developer time. By contrast, twiddling with a couple of details and switching to PyPy is the sort of thing you can prototype in an afternoon and deploy in a week or two, even with solid testing procedures. At scale that's probably worth it (using 5-10 times fewer machines is generally a significant cost savings even in this "cloud" era), but they may not be to that scale yet. Perhaps they never will be. Who knows? Not me.
The bottleneck is usually DB work, so PyPy is not a great help there.
Bottomline: Number of requests (scalability) and response times (performance) are more a work of architecture than using a particular language. And Python can be actually quite fast (fast enough)
Spot checking, you've done better than you think :)
Exciting to see python implementation doing this!