4 ms·
Django noob here. Could you give more details about the mechanism for doing background processing you mention? (Not sure how it helps the user not wait if it's
by scribu 13y ago
Django noob here. Could you give more details about the mechanism for doing background processing you mention? (Not sure how it helps the user not wait if it's synchronous.)
- crucialfelix 13y agoCelery is over-engineered but it does get the job done for most of the types of background tasks that I want a webserver to be involved with. Sending emails, making thumbnails, building 8MB xml files and uploading them to other servers, validating objects, sending messages to people, geocoding addresses with google etc. These types of things I do not want happening on the webserver at all. Its on a separate machine. I certainly don't want to block the user from getting a web response even while waiting for the email to connect and send. But Django and python could really use lightweight synchronous support for small things. > (Not sure how it helps the user not wait if it's synchronous.) example: Checking several URLs in parallel, collecting all the responses then returning some summary to the user. User is waiting, but at least the python doesn't have to do these sequentially so the wait is less.
- crucialfelix 13y agothough note that if you are blocking a request for some remote response or slow thing that your worker is not able to do anything else. it can't start working on the next request. so in django its not a useable design style if you have high traffic.
- est 13y agoIt's pretty simple and works just like fastcgi_finish_request() in PHP Search for pep 325 in pep 333