On 24/09/2013, at 9:57 PM, Sebastian Clemens <[email protected]> wrote:
> Ok, some more about my system: running Debian 6 and Plesk 11, 2GB RAM (and
> 50% is already in use) and the important part of my config:
>
> WSGIProcessGroup ssl.sebastian-clemens.de
> WSGIApplicationGroup ssl.sebastian-clemens.de
> WSGIDaemonProcess ssl.sebastian-clemens.de processes=1 threads=1
> display-name=%{GROUP}
> WSGIImportScript /var/www/vhosts/sebastian-clemens.de/httpdocs/wsgi.py
> process-group=ssl.sebastian-clemens.de
> application-group=ssl.sebastian-clemens.de
> WSGIScriptAlias / /var/www/vhosts/sebastian-clemens.de/httpdocs/wsgi.py
If that is the only WSGI application being run in that daemon process group,
you would be better using:
WSGIDaemonProcess ssl.sebastian-clemens.de threads=1 display-name=%{GROUP}
WSGIScriptAlias / /var/www/vhosts/sebastian-clemens.de/httpdocs/wsgi.py
process-group=ssl.sebastian-clemens.de application-group=%{GLOBAL}
If you are using a recent mod_wsgi version, this would have to be done as:
WSGIProcessGroup ssl.sebastian-clemens.de
WSGIApplicationGroup %{GLOBAL}
WSGIDaemonProcess ssl.sebastian-clemens.de threads=1 display-name=%{GROUP}
WSGIImportScript /var/www/vhosts/sebastian-clemens.de/httpdocs/wsgi.py
process-group=ssl.sebastian-clemens.de application-group=%{GLOBAL}
WSGIScriptAlias / /var/www/vhosts/sebastian-clemens.de/httpdocs/wsgi.py
Key change I am making is forcing application group to %{GLOBAL} so runs in
main interpreter of the process and doesn't waste a little bit of memory
creating a sub interpreter.
Also don't use 'processes=1' explicitly, let it default to one process. Use of
'processes' option, even with 1 process, has a side effect of flagging
wsgi.multiprocess as true, which may not always be what you want as it can
prevent certain in browser debugging tools to not work as they will think it is
a multiprocess configuration.
Finally, if only using mod_wsgi daemon mode, also set:
WSGIRestrictEmbedded On
This disables initialisation of Python in Apache worker child processes, where
they aren't needed.
Beyond that, cannot suggest anything else because it really does depend on your
application. Factors which dictate how you can set things up is memory used by
application, response times and through put. Number of true concurrent requests
and whether performing large uploads and downloads also matters. Whether you
are using nginx as a front end proxy can also matter as doing so allows
Apache/mod_wsgi to run with less resources.
As far as monitoring goes, one of the key things that dictates the tuning of
processes/threads is the capacity utilisation, in conjunction with queueing
time. This shows how much of the available capacity you are provisioning is
actually being used. Too often I see people over provision capacity and they
only use less than 5% of available capacity, thereby wasting memory in the
process and potentially paying too much money to a hosting service.
Capacity analysis or thread utilisation is mention in one of those talks I gave
a link to, but also see:
http://blog.newrelic.com/2012/09/11/introducing-capacity-analysis-for-python/
which shows how that looks in a proper monitoring system.
So read that and watch those talks I linked to.
Graham
> But I don't know how to calculate the amount of processes and threads if I
> expect ~1000 Users / Day
>
> By the way, that's the configs for another small webpage, but I'm going to
> copy & paste it for all of my django running sites.
>
> Am Dienstag, 24. September 2013 13:16:20 UTC+2 schrieb Sebastian Clemens:
> Hello,
>
> I'm using mod wsgi for some simple websites with only one process and one
> thread. But now I'm going to host a big page with 1000 users/day.
> Last time I hosted it i tried with 5 processes and 10 threads and the server
> crashed cause of full RAM.
>
> Can anyone give an approach how many users one process and one thread can
> handle? And how can I calculate the amound of processes and threads?
>
>
> Thanks very much,
> Sebastian
>
> --
> 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.
--
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.
