Graham,
Thanks for your suggestion, I will give it a try. I actually had problem
with yaml parsing library throwing exceptions infrequently in my wsgi
script, and the only way I can consistently replicate it is creating 2
identical wsgi applications, a.wsgi and b.wsgi, sending request to a.wsgi
first, which works fine, and then sending request to b.wsgi, which throws
exceptions in yaml parsing library.
Kevin
On Wednesday, October 16, 2013 10:58:40 PM UTC-4, Graham Dumpleton wrote:
>
> I would generally recommend delegating each to its own daemon process
> group. This then allows you to do a number of things.
>
> The first is that you can force each to run in the main interpreter
> context of their respective processes. This avoids issues with third party
> extension modules for Python which don't work properly in sub interpreter
> contexts. This is done using:
>
> WSGIApplicationGroup %{GLOBAL}
>
> You can turn off Python interpreter initialisation in main Apache
> processes, reducing memory use of Apache and Apache child worker process
> startup time. This is done using:
>
> WSGIRestrictEmbedded On
>
> Because each WSGI application would be in its own daemon process group,
> you can then customise the processes/threads and other settings for daemon
> processes to be specific to the requirements of that particular
> application. Applications which are infrequently used can therefore be
> tuned to use less resources and even effectively shutdown when idle.
>
> This customisation can also be done on a single WSGI application by
> delegating different URL subsets of the one application to run in different
> daemon process groups. This way within one application you can further tune
> settings even further if necessary. For example, you might delegate your
> most trafficked URL to a process of its own so that only the code related
> to that URL is loaded and hot in memory. A URL which has large transient
> memory usage could be delegated to a daemon process group of its own as
> well and use maximum requests or the inactivity timeout to restart the
> process to reclaim memory every so often. That way you don't have overall
> memory usage of a multiprocess configuration dictated by the excessive
> memory requirements of a single URL in your application.
>
> Graham
>
> On 17/10/2013, at 11:11 AM, Kevin <[email protected] <javascript:>> wrote:
>
> Hi there,
>
> I have several wsgi applications running, let's say a.wsgi, b.wsgi and
> c.wsgi, is it a good practice to just create one WSGIDaemonProcess group w/
> multiple instances, or shall I create multiple WSGIDaemonProcess groups,
> each for a unique application?
>
> Thanks,
> Kevin
>
> --
> 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] <javascript:>.
> To post to this group, send email to [email protected] <javascript:>
> .
> Visit this group at http://groups.google.com/group/modwsgi.
> For more options, visit 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.
For more options, visit https://groups.google.com/groups/opt_out.
