> The problems alluded to are, yes, solvable in python. But they also seem endemic in python systems. > > When everyone who uses the tool uses it wrong, maybe i

> The problems alluded to are, yes, solvable in python. But they also seem endemic in python systems. > > When everyone who uses the tool uses it wrong, maybe it's not the user's fault. Yes, though that doesn't mean it is necessarily the code's fault. Honestly, I was very confused by this article, because I thought everyone understood what was going on, the trade-offs involved, and how that ought to impact your design decisions. It's not that Gevent'd Gunicorn is intrinsically a bad thing. You're going for cooperative multi-tasking/concurrency, so no preemptive multi-tasking support. This creates potential challenges with fair scheduling if you have real-time constraints like timeouts... so you design accordingly. One of the advantages of this model is you do indeed need less memory (and often a little less CPU) to handle high load levels. It's not like you are intrinsically better off if you use Python in a forking model. You can still end up so CPU bound that you timeout handling requests... the only difference is you'll get fairer splitting of the CPU's time across tasks. It can actually get worse if you get lost in an infinite series of context switches (yes, there are ways to mitigate this problem... although they can create fair scheduling problems... it's a natural tension), or worse still, start swapping. If the notion that running out of CPU might mean you have timeouts hasn't occurred to you...