Makes sense. Thank you for the detailed answer! On Thursday, September 8, 2016 at 4:43:04 PM UTC-4, Graham Dumpleton wrote: > > > > On 9 Sep 2016, at 6:21 AM, Samer Atiani <[email protected] <javascript:>> > wrote: > > > > Greetings! > > > > I have configuration that looks like this: > > > > WSGIDaemonProcess example_daemon > > WSGIProcessGroup example_daemon > > WSGIApplicationGroup %{GLOBAL} > > WSGIScriptAlias / /var/www/example.wsgi > > > > From the docs, the defaults for WSGIDaemonProcess is process=1 and > threads=15. However, the docs also say the following about %{GLOBAL}: > > > > "Any WSGI applications in the global application group will always be > executed within the context of the first interpreter created by Python when > it is initialised." > > > > Does that mean that the configuration above makes it so that there only > one interpreter for all requests? > > Where WSGIDaemonProcess had processes=1 that would be the case anyway. > > > Does that consequently mean that it can only process one request at a > time? > > The total number of requests that can be handled at any one time in a > daemon process group, is: > > processes * threads > > What the application group is about is what interpreter context the WSGI > application runs in. > > When you are dealing with command line Python, there is only one > interpreter context (first or main interpreter context) but when using the > C API as is done when embedding, you can create additional sub interpreter > contexts. > > These sub interpreter contexts live in the same process they are created > in and provide pseudo separation between running Python applications. It > isn’t perfect separation, but lets gloss over that as don’t want to go into > the mechanics of it. > > So normally what happens with mod_wsgi is that each WSGI application is > run in a different sub interpreter context of the process handling the > request. This is to keep them separate. > > So if you had 3 processes and 5 threads, and two separate WSGI > applications delegated to that daemon process group. Each of those 3 > processes would have a copy of each WSGI application, but in two different > sub interpreter contexts of each process. So still a copy in each process. > > Across the two of the WSGI applications they would share the total request > handler thread pool of 3*5 = 15 threads. > > Thus if one WSGI application misbehaved and blocked requests and used up > all 15 threads at a specific time, the other WSGI application wouldn’t be > able to process requests, nor would the first either for that matter if all > 15 were used. > > This is why you would give each WSGI application its own daemon process > group. > > Now sub interpreters generally work okay, but in some cases you get third > party extension modules for Python that don’t use the Python C API for > threading in a way to allow them to work properly in sub interpreters. In > this case you need to force them to run in the first or main interpreter > context. So rather than use a sub interpreter, it would use that first > interpreter created in the process much like what happens when using > command line Python. > > If you did this for a whole daemon process group and all the WSGI > applications running in that group, it means those two WSGI applications > would be forced to run in the same interpreter context. For some WSGI > applications that would be bad. Django cannot do that for example. This is > why a WSGI application per daemon process group is better. > > So forcing use of the first or main interpreter context is to work around > problems with some C extension modules for Python. > > Although separate sub interpreter contexts is the default, is recommended > that the use of the first interpreter context always be used when using > daemon mode. You should though ensure only one WSGI application per daemon > process group. > > So it does not affect how many concurrent requests you can handle. For > daemon process groups that is still processes*threads. Just keep in mind > that the pool of Apache workers (processes or threads) still needs to be > sufficient in capacity to be able to handle proxying the required number of > concurrent requests through to the daemon process groups. There is no point > setting up a daemon process group with capacity for 200 requests if the > Apache workers can only proxy at most 100 at any one time. > > 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.
