On Thu, Jan 21, 2016 at 8:19 AM, Benjamin Melki <webko...@gmail.com> wrote:
> > > > To implement this sort of feature, you need to have a worker queue - > Celery is the heavy duty answer for this; if you just need a cheap and > cheerful answer, RQ is a fairly easy-to-use option, or you can > roll-your-own in the database without too much trouble. > > > Thank you Russel, for the informative answer. It’s all pretty clear, and > it is a great news to learn that some async patch will make it into Django. > > Just to be perfectly clear…. you talk about celery and indeed i’ve seen > some tutorials about it. > But most were written before 3.5 python. > > Specifically for the image processing, do I need to install celery, can’t > I just use async / await for this task ? > The Python 3.5 async/await keywords are an entirely different beast, for an entirely different problem - that’s why I flagged the fact that “asynchronous” was a misleading word to use in this case. I’m sure you *could* use async/await to implement an image processing solution, but you wouldn’t gain much. A user would still connect to your server, start a request, which would spawn (or acquire) a thread to do image handling… and then wait until the background processing was complete before “await”ing, and then returning the result to the user. The end user experience is still going to be “nothing is seen until the entire process is completed”, and absent of some very sophisticated server gymnastics, the server thread is still going to be locked up waiting for the image processing to return. All you will have achieved is a lot of complexity in your code so that your image processing is handled in a separate thread. You could do exactly the same thing without async/await by spawning a subprocess or thread, and waiting/joining on the subprocess/thread response. Ultimately, this is really all async/await is - syntactic sugar around diverting program flow to an alternate thread (Insert suitable amounts of hand waving here glossing over the details and nitpicking :-). You’re still going to have a web server waiting for something, and a user waiting for a finished request. Moving to an all singing, all dancing asynchronous web server (such as twisted, tornado, or a patched version of Django such as the Django Channels that should be coming in an upcoming release), would solve the server resource starvation problem, which I suppose is a good thing, but the end user will still be waiting to see responses displayed - and remember, it only takes 0.3s of lag for a user to declare that a user interface is slow. Remember, “asynchronous” isn’t magic fairy dust that makes everything faster. You need to understand *what* is causing blocking in your algorithm in order to evaluate if synchronicity is the problem you have. In the case of image processing, you don’t want asynchronicity - you want background processing. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq84-VkWH3uwHmx-ZWZ1Py8vy6ZepD7EbNq%2BZUJ_U1zneiuQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
