What are you setting MaxClients to in Apache? Provide all the MPM settings you have set for prefork MPM. Eg: settings for:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 256 MaxRequestsPerChild 10000 as well as what you have set for: KeepAlive KeepAliveTimeout How long does it take the WSGI application to respond to a SOAP request? You either have MaxClients set to some ridiculously small value, your SOAP requests take an excessive amount of time to respond and you aren't providing enough capacity, or your WSGI application is locking up completely and never responding. Also, is your WSGI application thread safe? Graham On 25 February 2013 19:32, Thomas Guettler <[email protected]> wrote: > I asked this question on stackoverflow: > > http://stackoverflow.com/**questions/12528330/one-wsgi-** > app-eats-all-apache-clients<http://stackoverflow.com/questions/12528330/one-wsgi-app-eats-all-apache-clients> > > {{{ > We have a SOAP mod_wsgi (apache) app which gets heavy load sometimes. The > same Apache servers some other wsgi-apps. Unfortunately you can set > MaxClients only at server level, not per wsgi-app. > > We get: > > server reached MaxClients setting, consider raising the MaxClients setting > > Is there a way to stop this wsgi app from eating all apache workers? > > I want to return 503 "Service Unavailable" only to the SOAP client who > connects to the SOAP wsgi app. > > Apache config snippet: > > WSGIDaemonProcess soap_app threads=1 processes=3 > WSGIScriptAlias /soap_app /home/soap_app/django_wsgi.py > <Location "/soap_app/"> > WSGIProcessGroup soap_app > WSGIApplicationGroup %{GLOBAL} > </Location> > > There are only 3 wsgi daemon processes for the soap app. But it occupies > much more apache workers. > > Update: We use apache prefork mpm. There are N apache worker. And for > mod_wsgi we use prefork, too. There are M mod_wsgi worker processes. The > apache worker count can be controlled by MaxClients. The mod_wsgi worker > count is controlled by the above config. > > I think you can't handle this inside the python wsgi app (django). I guess > it needs to be done by the mod_wsgi or apache config. > }}} > > Here the answer: > {{{ > All the request are served by an Apache child (controlled by MaxClients) > but every time a request hits the soap_app url the Apache child will wait > for one of the the 3 WSGIDaemonProcess. If you receive request to soap_app > faster than you can serve them with 3 processes eventually you will run out > of Apache child. > > The only way I see to control the number of Apache child dedicated to > soap_app is tho use mod_proxy and proxy the soap_app request to another > "service". The proxy pass directive allows you to define the number of > concurrent request to be serve, that will be equal to the number of Apache > child you want to use for soap_app. > > The "service" to serve the soap_app request could be another VirtualHost > of the same Apache (never tested it) or a gunicorn instance with the > soap_app application > }}} > > I use mod_wsgi since several years now and was happy with it and want to > stay with it. > > I see this solution at the moment: route only the URLs which can get too > much traffic (soap client) through mod_proxy, > and route the traffic to the same mod_wsgi application again. But this > would be recursive ... > > Or I handle this at application level: I don't want more then 3 workers > running at one time. I give the mod_wsgi daemon 4, and in a middleware I > check how many workers are busy. If three are busy the request would return > at once with 503 "Service Unavailable". If the 503 response is quicker then > new requests come in, the MaxClients limit should not be reached. But how > can an application know how many workers are busy at the moment? Touching > files in a directory or > memcached incr+decr is not reliable. > > Do you understand my problem? Would could be done? > > > Thomas Güttler > > > > -- > Thomas Guettler, http://www.thomas-guettler.de/ > E-Mail: guettli (*) thomas-guettler + de > > -- > 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 > modwsgi+unsubscribe@**googlegroups.com<modwsgi%[email protected]> > . > To post to this group, send email to [email protected]. > Visit this group at > http://groups.google.com/**group/modwsgi?hl=en<http://groups.google.com/group/modwsgi?hl=en> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
