Sorry for the delay, I was not connected the last two days.

Thank you for you hints how to optimize my current setup. You are right, the 
worker MPM is better in my environment.
I know newrelic could help me to optimize my setup even more.

But I still see a problem: The soap client is a powerful machine in the same LAN, but outside my control and it can send a lot of requests to my server. It could be compared to a denial of service attack. The soap client must not
get all slots of the apache connection pool, since there are other (more 
important) wsgi applications.

Is there really no possibility to tell apache or mod_wsgi this: "don't put more than N requests in to the connection pool for this wsgi-app"?

If not, I need to implement the answer given on stackoverflow (mod_proxy and 
gunicorn).

  Thomas

On 27.02.2013 23:56, Graham Dumpleton wrote:
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 <http://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] 
<mailto:[email protected]>> wrote:

    Hi Graham, thank you for your patience.



    On 26.02.2013 12 <tel:26.02.2013%2012>: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 
<mailto:modwsgi%[email protected]>.
    To post to this group, send email to [email protected] 
<mailto:[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.



--
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 [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.


Reply via email to