2009/11/17 Daan Davidsz <[email protected]>:
>> Not scalable and lean in what way?
>>
>> You will use just as much memory if you were to create as many
>> distinct process groups as you have applications and with each having
>> 8 processes each running a single thread.
>
> Not scalable because it currently uses a global configuration file for
> the server. This means all different sites on that server will be run
> using those 8 processes. When the amount of traffic increases 8
> processes may not be enough.
Most people over estimate how much traffic their site will
realistically receive. It also isn't necessarily the number of
concurrent users you have to worry about as much is it how long each
request takes. If your request response requests are well optimised
and short, then even a single threaded mod_wsgi daemon process is
generally going to be more than adequate for most peoples needs. More
processes/threads is only going to warranted where you have many
requests which take more than a short amount of time as they will tie
up threads available thereby reducing number of requests/sec you can
sustain.
If your site is going to receive the amounts of traffic that would
trouble such a setup then you are already in a poor hosting setup in
as much as you have no control of the Apache configuration and
management. If your site is going to see substantial amounts of
traffic then you should be on a VPS where you have full control or
with a hosting company such as WebFaction where you can offload static
file serving to their infrastructure and still have full control of
your own Apache instance.
>> At the moment only by duplicating WSGIDaemonProcess/WSGIProcessGroup
>> configuration for each application.
>>
>> Because I don't know whether you are currently using WSGIScriptAlias
>> on specific WSGI script file, or mapping it against a directory of
>> WSGI script files, or using AddHandler, can't guide you as to exactly
>> what you need to do.
>
> I control the mod_wsgi flow using .htaccess files and AddHandler. The
> problem is that I don't have full control (at the moment) of the
> system administration. The global configuration file was set by the
> administrators.
>
>> Short answer is though that you aren't restricted to one
>> WSGIDaemonProcess/WSGIProcessGroup configuration.
>>
>> Can you provide the rest of your mod_wsgi related configuration?
>
> My first post contains all the configuration except the .htaccess
> configurations.
>
> I'm afraid that my current configuration will also combine the PATH
> variables for different websites.
Relying on PATH setup is also again a bad idea. References to
executable programs should also be by absolute path to avoid problems.
> Using a ProgressGroup per website
> would solve that, but I don't know how to accomplish that with my
> limited server administration rights. Is there any other way or should
> I just ask for more rights on the server because it isn't workable
> otherwise?
If the administrators aren't going to constrain you as far as how many
processes you have, then would suggest you have them do something like
the following. This presumes all your stuff is under one VirtualHost
which you own.
<VirtualHost *:80>
ServerName daan.example.com
WSGIDaemonProcess daan-1 threads=5 display-name=%{GROUP} user=daan group=daan
WSGIDaemonProcess daan-2 threads=5 display-name=%{GROUP} user=daan group=daan
WSGIDaemonProcess daan-3 threads=1 processes=5 display-name=%{GROUP}
user=daan group=daan
WSGIRestrictProcess daan-1 daan-2 daan-3
WSGIProcessGroup %{ENV:site.process_group}
WSGIApplicationGroup %{ENV:site.application_group}
SetEnv site.process_group daan-1
SetEnv site.application_group %{RESOURCE}
</VirtualHost>
What this does is set up three different process groups for you to
use, two multi threaded ones and one single threaded one. The default
is set to be the first of the multi threaded ones.
Because the delegation to process and application groups is handled
indirect via SetEnv variables, then you can override them in your
.htaccess file provided you have FileInfo override, which since you
can use AddHandler you would.
The WSGIRestrictProcess directive allows administrators though to
constrain you to only being able to delegate to the process groups set
up for you.
In your .htaccess file you would then have:
AddHandler wsgi-script .wsgi
If you then wanted to delegate a specific application to the single
threaded process you could use:
<Files django.wsgi>
SetEnv site.process_group daan-3
</Files>
That is, for WSGI script file for the site, using SetEnv override
site.process_group variable from which which process group to use is
being read.
If you had a specific site that needed to be run in main Python
interpreter within a process, eg. Trac with Python subversion
wrappers, you could also set the application group to change which
interpreter is used:
<Files trac.wsgi>
SetEnv site.process_group daan-2
SetEnv site.application_group %{GLOBAL}
</Files>
So, still requires administrators to do stuff to set up initial
process groups, but your then have flexibility to move applications
between process groups provided.
The issue then becomes how many different process groups and processes
within them the administrators are prepared to let you have.
Graham
--
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=.
