So I could suggest you use worker MPM with a greater number for MaxClients. Because it is a multithread MPM, would be less processes and so less memory and thus could handle queueing more requests, but even if you do that, you are still going to restrict yourself because you are allowing so few SOAP requests to run so you really need to address that as well.
What I cant tell is what the traffic is you are getting for SOAP requests and how CPU intensive they really are. They may well take 5 seconds to handle a request, but is it CPU bound or is it waiting on I/O with a backend service or database. If it isn't CPU bound then trying to limit the number of processes it runs on wouldn't serve any purpose. If it isn't CPU bound (and even if it is to a degree) and as long as your SOAP code is thread safe, you can probably do things better by by using multithread in daemon process for SOAP code as well. Either way, you really need to get a better idea on amount of traffic for SOAP requests, plus get an idea of how much SOAP requests are backing up by watching queue time, which is time from when Apache accepted the request and when SOAP code started handling it. As biased and self serving as it may seem since I work there and wrote the Python agent for it, this is a case where New Relic would really tell you what is going on so you can better tune the server. So, suggest you have a look at newrelic.com and if it is something you are able to install and get running, can then walk you through some possible extra setup for it and can then show you visually what your problems are and what you need to do. Graham On 26 February 2013 23:25, Thomas Guettler <[email protected]> wrote: > Hi Graham, thank you for your patience. > > > > On 26.02.2013 12:47, Graham Dumpleton wrote: > >> Sorry, two more questions. >> >> Is you SOAP code thread safe? >> > > I don't know. Up to now I avoided threads. We use threads=1 in the > WSGIDaemonProcess config. > > > Is there a particular reason you are using Apache prefork MPM given that >> all main Apache processes appear to be doing is >> serving static files and proxying to mod_wsgi daemons? >> > > No, there is no reason except "it was always done like this in the past". > You are right, we waste a bit of performance. But I don't think it is much. > > > Sleep time for me. Will see what you say tomorrow. >> > > Thank you for your fast replies. Good night .... good morning. > > > 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.
