Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Writing asynchronous code gives you the ability to speed up your application [...]

Citation needed... It will be slower by definition but it probably advertised higher throughput anyway. I wonder how many people the throughput question is true for. You’d have to be pretty hardware constrained.

They even suggest asyncio could be a replacement for celery... It really is the Wild West out here.



> They even suggest asyncio could be a replacement for celery... It really is the Wild West out here.

Yeah this is pretty questionable.

Having state in your app's process and then having to pretty much re-invent queues, job cancellation, uniqueness guarantees, scheduled jobs, periodic jobs on an interval, queue draining and retries with exponential backoffs.

I mean, yeah you could code all of that with enough time but why would you when Celery exists. If anything having the queue's state held in Redis or anywhere outside of your app's process is enough of a reason to pretty much never replace Celery with asyncio. Even in the post's example of sending an email I would still want a lot of what Celery has to offer and wouldn't consider replacing it.

IMO Celery isn't going anywhere soon and I would still use it in every Python project that needs background processing.


Just based on my C# experience, this sounds like a terrible idea (abandoning a real task queue for Async/await). 90% of the “gotchas” with async/await in C# comes from people thinking that the task scheduler is bonafide background queue.


Same here. We do lot of processing in background jobs, which make no sense moving to async task.


Celery doesn’t guarantee uniqueness. :-/


> They even suggest asyncio could be a replacement for celery... It really is the Wild West out here.

Yes that is complete madness. The last thing I would ever want to do is send an email or use an external API (those are the examples in TFA) in an async thread as part of a request-response cycle. How does error handling or retries work for that background stuff? I don't know the exact ins-and-outs of Djangos new async stuff yet but my guess is that if that mail/API server doesn't respond to your IO then your response to your own HTTP request hangs?

Above all the central and undemonstrated claim is that there are any performance or management advantages to async. I tested sync vs async on this a couple of months ago. The best performance and robustness is with garden variety sync python with a good WSGI server:

http://calpaterson.com/async-python-is-not-faster.html

If anyone has any contradictory benchmarks please let me know. I haven't been made aware of any yet.


Techempower benchmark: https://www.techempower.com/benchmarks/#section=data-r19&hw=... makes the difference between async python frameworks and sync frameworks pretty clear.

Async results in better utilization of system resources... since there aren't entire threads with app state blocked on IO requests (which would consume a chunk of system memory.)

Considering that a web app is most commonly waiting for a database operation, a single server can serve many more active requests simultaneously (since each active request is not allocating an app instance.)


The techempower benchmark predates me and original drafts of my blogpost mention it but I suppose that got cut for various reasons.

The trouble with that benchmark is that (and they're fairly open about this) they aren't keeping things the same between frameworks - there are multiple variables. If you look at the Flask code all the queries are being put through SQLAlchemy but for various async frameworks they're using the database driver directly and using native code libraries for JSON decoding.

I think techempower's benchmarks are interesting but they don't help you do a comparision of async vs sync.

Additionally on the particular benchmark you've linked to #1 is a dead experimental framework that is not in wide use and #2 is Falcon, a sync framework that is in wide use.


Yeah the post conflates asynchronous and concurrent like people always do. Asynchronous code can be executed sequentially, people. (Synchronous code can be executed concurrently, too.)

Asynchronous code is absolutely not just for running tasks after returning an HTTP response. A good example of the true power of asynchronous execution would be to do a Web Socket handler _inside a Django view._


> They even suggest asyncio could be a replacement for celery

Only if you don't care about reliability.


I used Celery (as a workaround) for a Django view that should have been in asyncio before asynchio was available.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: