Read: http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading
For first lot of questions. In daemon mode additional daemon mode processes are not spawned, the number of daemon mode process is fixed. This doesn't mean Apache may not create additional child processes which do the proxying of requests to the daemon mode processes. Read: http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html for a bit more information about how Apache spins up new child processes and its bad effects on using embedded mode, especially with prefork. As to where requests for a specific application are handled, normally that would all be in the same daemon process group as that is the sole place you would have told it to run the requests. So, the only way that requests for one application would be handled in separate daemon process groups is if you had configured it that way by saying to send certain URL sub requests to a different daemon process group. For second lot of questions. Any process, be it an embedded mode process if that is being used, or a daemon process can have multiple separate contexts in which code can run, ie., separate sub interpreters within the one process. Thus sub interpreters are not one to one with processes as a process can have multiple sub interpreter contexts within them. This means that when a daemon process group has multiple processes, there is a same named sub interpreter in each of them. So if an applications requests end up being handle by a process, it goes to the appropriate sub interpreter (application group) within that process. At the same time requests for same application handled by another process in same daemon process group would be handled by same named sub interpreter in the other process. For third lot of questions. The main interpreter is just the first interpreter created in a process when Python is initialised and is the equivalent of what you get when you run command line Python. The first interpreter has special properties because the Python C API simplified GIL API only works properly in the main interpreter. Thus in some cases it is necessary to force applications to run in the main interpreter if using C extension modules that use this API. Sorry if I have explained that badly, am snowed under with work right now and behind on emails. Graham On 18 August 2011 03:23, giohappy <[email protected]> wrote: > I'm just starting to study mod_wsgi to deploy three applications based > on Pyramid framework. > The will run in apache mpm prefork 2.2, on a linux system. > I'm trying to figure out the various options given by daemon > processes, daemon group and application groups, but I'm lost between > the relations between each other. > I'f I'm not wrong, I can dedicate each app a daemon group of > processes. The flow for each application is: > > 1. Incoming request > 2. apache evaulates the process group of the requested application > 3. it starts / reuse processes (or threads) from the selected daemon > process. > > First doubt: > if apache requires to spawn a new process, because of requests peaks, > how does this new process relate to the daemon processes? I suppose it > starts up a new group od damen processes. If it's right, it can > happens that two requests redirected to the same app can be processes > in two different daemns. Am I far from the truth? > > Second doubt: > The application group, by default, will map an application to the same > sub-interpreter, on into the main interpreter if GLOBAL is used. What > does it mean exactly, in relation to the daemon group of processes? I > mean, how mod_wsgi guarantee that the same (sub) interpreter will be > used, if apache can spawn new processes? > > Third, and last doubt: > If I set GLOBAL for the application group, but I have various daemon > groups, what is the "main interpreter"? > > I'm sorry for my basic (and probably dummy) questions, but these are > my very first steps into the world of mod_wsgi... > Thanks for the help, > giovanni > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
