4 ms·
The downside is that monkey patching the world with gevent was hard to pull off and even harder to verify. I was running a large Django installation on gunicorn
by aeyes 5y ago
The downside is that monkey patching the world with gevent was hard to pull off and even harder to verify. I was running a large Django installation on gunicorn+gevent for some years and I saw almost no difference in throughput or response time when I made the switch to sync workers. I was glad once I could remove all the monkey patches which really did nothing for my use case.
To this day I am not sure how anyone is getting better performance from using async over sync for something like Django. If you run 1000 sync gunicorn processes, I'm sure the OS scheduler is doing a better job in assigning them CPU time slices than what you could ever do with gevent.
There is a place for gevent/asyncio, for example if you want to fire off some http requests or DB calls in parallel but you'll have to do it manually no matter what gunicorn worker you run on.
- samwillis 5y agoAgree on the hackish nature of the monkey patching. My wish is that Gevent had been adopted into core so that it “just worked” with no monkey patching. Or at least a lower level api was exposed allowing different concurrency/coroutine implementations for the same apis. I have used Gevent extensively in two places; long running eventsource/sse Django views (it’s just implicit due to the Gunicorn worker) and views with hundreds of db and http api calls that are made concurrently before returning a response. Both worked well from my experience, the latter needed coroutines to be spun up for each api/db call.
- hedgehog 5y agoFor a while gevent was my go to for projects needing some kind of pub/sub service (different telemetry and device management applications). Worked great in that case but then Go came along, it works even better for those cases.
- dmw_ng 5y ago> My wish is that Gevent had been adopted into core so that it “just worked” with no monkey patching The problem with Gevent is no matter how clean the stack switching, the major liability is other code sharing that stack -- the complete universe of native Python extensions is huge, and some of it most certainly makes assumptions about the stack. I've used Gevent/greenlet for years and never encountered issues, but it's important not to be under any illusions about the kind of hellish crashes that might be lurking just around the corner as more third party code gets added to a project.
- Areading314 5y agoThe bottleneck is always. The. Database.
- nostrademons 5y agoUnless you're working on a site that's been specifically architected to not use databases. You're posting this comment on one now; HN stores everything in RAM and periodically journals snapshots out to disk so they survive reboots. Last I heard the whole site runs on one box.
- unoti 5y ago> specifically architected to not use databases. You're posting this comment on one now; HN stores everything in RAM and periodically journals snapshots out to disk so they survive reboots Yep! And for those that didn't know, this strategy on HN and other paulg projects is actually what inspired Redis! See this antirez tweet https://twitter.com/antirez/status/1110468354542919681 https://twitter.com/antirez/status/1110468354542919681 and https://news.ycombinator.com/item?id=19498379 https://news.ycombinator.com/item?id=19498379
- blowski 5y agoFascinating! Do you have a link to an article that explains that in more detail?
- wolf550e 5y agoI've used gevent for years and I've benefited from being able to fire many http requests using requests and many postgresql sql queries in parallel from a django view, waiting for all of them to complete and generating a response. It was easy to do and the code was easy to write. For the simple case, the throughput is not improved over sync workers. The scalability does improve. Basically, your code can magically cheaply wait for thousands of sockets to get ready, but it can't magically process more requests per second.