Of course, if you are incompetent enough to write queries that use no indexes and you don't detect that before you push to prod, you will have problems there.
What I mean is: when you start optimising, no matter how well you do, you will eventually hit a CPU performance wall. Then you will realise that only a rewrite will get you out of that hole, and by then it will be late.
In my experience, many sites never hit that point of having CPU-bound Python code which they can’t afford; the ones which do hit that wall are usually large enough that they can carve out room for a C/Rust library, microservice, etc. rather than rewriting the entire thing.
Re:Django 3
by frankwiles on Monday December 02, 2019 @09:11PM
(#21689313)
I concur, I’ve worked on at least a dozen “web scale” Django sites and I can’t think of a single one where we were CPU bound.
It’s possible, of course, but I’ve usually seen it as a symptom of not having a good culture around monitoring and troubleshooting — e.g. I remember someone porting an entire site to Jinja2 alleging performance wins, and it’s true that template rendering got (IIRC) 10-15% faster but they’d missed that 99.999% of the total runtime was being taken up by unoptimized database access generating many thousands of queries.