On 13/11/2013, at 10:58 PM, Ahmed El Melegy <[email protected]> wrote:
> I serve two different types of requests . manually requests done by users > that I need to serve quickly , other requests are background client slow > requests and I don't have to respond to it immediately , may be I can drop > the request if the number of queued background requests exceeds a threshold . > I was thinking of redirecting background requests to a different > WSGIDaemonProcess , what do you think ? Using multiple mod_wsgi daemon process groups and delegating specific URLs to run in different process groups is certainly one approach to avoid backlogging within one process group and thereby blocking out those requests which need more prompt responses. The problem with Apache is that even in doing this, because processes/threads are used in the Apach child worker processes still, that proxy the requests, then backlogging can still occur there. In other words, if the number of long running requests which backlog due to the process group handling those reaching capacity, exceeds even the number of MPM processes/threads for Apache child worker processes, then you would exhaust capacity there as well and all types of requests would then backlog in the single socket listener for the whole of Apache and the requests needing quick responses would again be held up. I am not saying here that it isn't possible, but simply that you have to be mindful of ensuring that you have sufficient capacity by way of the Apache MPM processes/threads settings to deal with transitory backlogging at that level as well. This is on top of ensuring you already have enough capacity there to proxy enough requests to make use of the capacity defined in the daemon process groups. For example. To deal with both fast and slow requests you might have: WSGIDaemonProcess fast-requests processes=3 threads=5 WSGIDaemonProcess slow-requests processes=5 threads=25 WSGIProcessGroup fast-requests <Location /some/slow/url> WSGIProcessGroup slow-requests </Location> First off the Apache MPM settings would need to have at least capacity for 140 (3*5 + 5*25) concurrent requests. Have anything less and the capacity in daemon process groups is wasted. As extra safety measure though, to deal with backlogging if for some reason you reached the 125 slow-requests capacity, then you want extra capacity in MPM settings. So rather than 140, possible want ability to handle 200 concurrent requests in Apache MPM settings. Anyway, you probably get the idea. Just make sure you provision sufficient headroom to avoid potential for blocking things completely. If you don't already have a really good idea on the number of concurrent requests you are handling, or need to, you will need to add in some sort of monitoring to measure that and how much of the capacity you are already using. The other thing to consider is timeouts. Right now mod_wsgi itself doesn't have good internal timeout mechanisms but I did start working on it at one point for version 4.0. It has been a while now and I don't quite remember where I got up to. Even without that, it is possible to implement a crude timeout system yourself via a WSGI middleware around your WSGI application. I think I may have posted details about that once before. The idea though is for the middleware to rely on special headers that mod_wsgi sets in version 3.4+ indicating when the request was first accepted by Apache. One can look at that compared to when the request comes to be handled in the daemon process. If it exceeds some time value, indicating that the user has already been waiting for quite a long time due to potential backlogging, then rather than handle it, you return an error response for 503 or something. This technique can be used to short circuit things and better recover from temporary backlog without the server getting into an unrecoverable state where it can never catch up on executing requests which the user has likely already given up on. There is a bit more to it than have explained here, but enough to get you thinking and if necessary I can drag out the code I wrote for such a WSGI middleware at some point or find the old post about it. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/groups/opt_out.
