> On 16 Mar 2016, at 12:10 PM, [email protected] wrote: > > I am hoping to gain some clarity here on our WSGI configuration since a lot > of the tuning seems to be heavily reliant on the application itself. > > Our setup > Single load balancer (round robin) > Two virtual servers with 16GB of RAM > Python app ~100MB in memory per process > Response times are longer as we broker calls, so it could be up to 1-2 seconds > Running WSGI 4.4.2 on Ubuntu LTS 14 with Apache 2 > WSGI Daemon mode running (30 processes with 25 threads) > KeepAlives are off > WSGI Restrict embedded is on > Using MPM event > For Apache, we have the following: > StartServers 30 > MinSpareThreads 40 > MaxSpareThreads 150 > ThreadsPerChild 25 > MaxRequestWorkers 600 > I have tried a number of different scenarios, but all of them generally lead > to the same problem. We are processing about 3 requests a second with a > steady number of worker threads and plenty of idle in place. After a few > minutes of sustained traffic, we eventually start timing out which then leads > to worker counts driving up until it's reached the MaxRequestWorkers. Despite > this, I am still able to issue requests and get responses, but it ultimately > leads to apache becoming unresponsive.
Just to confirm. You say that you never go above 3 requests per second, but that at worst case those requests can take 2 seconds. Correct? Are the request handlers predominantly waiting on backend database calls, or are they doing more CPU intensive work? What is the CPU load on the mod_wsgi daemon processes? Also, what is the size of payloads, for requests and responses? 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 https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
