mod_wsgi + multiple projects - works well, but unclear about a few things

[Leho Kraav]

hi all wsgi gurus

my goal was to get several isolated trac no-site-packages virtualenvs
running under mod_wsgi: 0.11 virtualenv for bunch of live projets,
0.12-dev1 for project dev1 and 0.12-dev2 for project dev2. but i am
somewhat unclear regarding ApplicationGroups and ProcessGroups - some
setup guides did it one way, some the other. so i also seem to have a
mix in my config file. what about having both dev1 and dev2 both in
ApplicationGroup %{SERVER}%, should they be in separate AG, or does
separate PGs take care of that? perhaps someone could tell me if
there's something to be fixed here:

/etc/apache2/modules.d/70_mod_wsgi.conf:

<IfDefine WSGI>
LoadModule wsgi_module modules/mod_wsgi.so

WSGIDaemonProcess dev1 user=leho group=apache threads=25 python-path=/
secure/trac/virtual-0.12-dev1/lib/python2.5/site-packages:/secure/trac/
virtual-0.12-dev1/bin
WSGIScriptAlias /project/dev1 /secure/trac/virtual-0.12-dev1/bin/
virtual-0.12-dev1.wsgi
<Location /projekt/dev1>
WSGIReloadMechanism Process
WSGIProcessGroup dev1
WSGIApplicationGroup %{SERVER}
SetEnv trac.locale et_EE.UTF-8
</Location>

WSGIDaemonProcess dev2 user=leho group=apache threads=25 python-path=/
secure/trac/virtual-0.12-dev2/lib/python2.5/site-packages:/secure/trac/
virtual-0.12-dev2/bin
WSGIScriptAlias /project/dev2 /secure/trac/virtual-0.12-dev2/bin/
virtual-0.12-dev2.wsgi
<Location /projekt/dev2>
WSGIReloadMechanism Process
WSGIProcessGroup dev2
WSGIApplicationGroup %{SERVER}
SetEnv trac.locale et_EE.UTF-8
</Location>

WSGIScriptAlias /project /secure/trac/virtual-0.11/bin/
virtual-0.11.wsgi
<Directory /secure/trac/virtual-0.11/bin>
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.locale et_EE.UTF-8
SetEnv trac.env_index_template /secure/home/httpd/htdocs/project/
index.html
</Directory>

</IfDefine>

[Graham Dumpleton]

On Oct 29, 7:00 pm, Leho Kraav <lkoogliz...@gmail.com> wrote:
> hi all wsgi gurus
>
> my goal was to get several isolated trac no-site-packages virtualenvs
> running under mod_wsgi: 0.11 virtualenv for bunch of live projets,
> 0.12-dev1 for project dev1 and 0.12-dev2 for project dev2. but i am
> somewhat unclear regarding ApplicationGroups and ProcessGroups - some
> setup guides did it one way, some the other. so i also seem to have a
> mix in my config file. what about having both dev1 and dev2 both in
> ApplicationGroup %{SERVER}%, should they be in separate AG, or does
> separate PGs take care of that? perhaps someone could tell me if
> there's something to be fixed here:

For Trac, due to limitations in Python wrappers for subversion, you
must use:

WSGIApplicationGroup %{GLOBAL}

So, if using subversion you don't have a choice and if need separation
must use daemon process groups instead.

> /etc/apache2/modules.d/70_mod_wsgi.conf:
>
> <IfDefine WSGI>
> LoadModule wsgi_module modules/mod_wsgi.so
>
> WSGIDaemonProcess dev1 user=leho group=apache threads=25 python-path=/
> secure/trac/virtual-0.12-dev1/lib/python2.5/site-packages:/secure/trac/
> virtual-0.12-dev1/bin
> WSGIScriptAlias /project/dev1 /secure/trac/virtual-0.12-dev1/bin/
> virtual-0.12-dev1.wsgi
> <Location /projekt/dev1>
>         WSGIReloadMechanism Process

Delete WSGIReloadMechanism directive. This is default for mod_wsgi 2.X
and will not even have choice in mod_wsgi 3.X. You should not be using
mod_wsgi 1.X.

>         WSGIProcessGroup dev1
>         WSGIApplicationGroup %{SERVER}

Use:

WSGIApplicationGroup %{GLOBAL}

to avoid subversion issues.

>         SetEnv trac.locale et_EE.UTF-8
> </Location>
>
> WSGIDaemonProcess dev2 user=leho group=apache threads=25 python-path=/
> secure/trac/virtual-0.12-dev2/lib/python2.5/site-packages:/secure/trac/
> virtual-0.12-dev2/bin
> WSGIScriptAlias /project/dev2 /secure/trac/virtual-0.12-dev2/bin/
> virtual-0.12-dev2.wsgi
> <Location /projekt/dev2>
>         WSGIReloadMechanism Process

Delete WSGIReloadMechanism directive. This is default for mod_wsgi 2.X
and will not even have choice in mod_wsgi 3.X. You should not be using
mod_wsgi 1.X.

>         WSGIProcessGroup dev2
>         WSGIApplicationGroup %{SERVER}

Use:

WSGIApplicationGroup %{GLOBAL}

to avoid subversion issues.

>         SetEnv trac.locale et_EE.UTF-8
> </Location>
>
> WSGIScriptAlias /project /secure/trac/virtual-0.11/bin/
> virtual-0.11.wsgi
> <Directory /secure/trac/virtual-0.11/bin>
>     WSGIApplicationGroup %{GLOBAL}
>     SetEnv trac.locale et_EE.UTF-8
>     SetEnv trac.env_index_template /secure/home/httpd/htdocs/project/
> index.html
> </Directory>

This one will run in embedded mode. Especially if using prefork MPM,
bad idea to use embedded mode. Better off delegating this one to its
own daemon process group as well.

Graham

> </IfDefine>

[Christian Boos]

Hello Graham,

Graham Dumpleton wrote:
>
> On Oct 29, 7:00 pm, Leho Kraav <lkoogliz...@gmail.com> wrote:
>
>> hi all wsgi gurus
>>
>> my goal was to get several isolated trac no-site-packages virtualenvs
>> running under mod_wsgi: 0.11 virtualenv for bunch of live projets,
>> 0.12-dev1 for project dev1 and 0.12-dev2 for project dev2. but i am
>> somewhat unclear regarding ApplicationGroups and ProcessGroups - some
>> setup guides did it one way, some the other. so i also seem to have a
>> mix in my config file. what about having both dev1 and dev2 both in
>> ApplicationGroup %{SERVER}%, should they be in separate AG, or does
>> separate PGs take care of that? perhaps someone could tell me if
>> there's something to be fixed here:
>>
>
> For Trac, due to limitations in Python wrappers for subversion, you
> must use:
>
> WSGIApplicationGroup %{GLOBAL}
>
> So, if using subversion you don't have a choice and if need separation
> must use daemon process groups instead.
>

Speaking of that, I'm not sure if you've seen that someone recently
reported the "instance.__dict__ not accessible in restricted mode" issue
with mod_wsgi 2.5, despite his use of WSGIApplicationGroup %{GLOBAL}
(see http://trac.edgewall.org/ticket/3371#comment:73).

As we don't see the whole configuration he was using, it might be that
the WSGIApplicationGroup directive was wrongly applied. OTOH, he
reported success with a similar setup using mod_python, so it's a bit
troubling. Are you aware of situations where that RuntimeError could
still occur with mod_wsgi 2.5 even when WSGIApplicationGroup %{GLOBAL}
is used?

-- Christian

[Graham Dumpleton]

On Oct 29, 9:20 pm, Christian Boos <cb...@neuf.fr> wrote:
> Hello Graham,
>
>
>
>
>
> Graham Dumpleton wrote:
>
> > On Oct 29, 7:00 pm, Leho Kraav <lkoogliz...@gmail.com> wrote:
>
> >> hi all wsgi gurus
>
> >> my goal was to get several isolated trac no-site-packages virtualenvs

> >> running undermod_wsgi: 0.11 virtualenv for bunch of live projets,

> >> 0.12-dev1 for project dev1 and 0.12-dev2 for project dev2. but i am
> >> somewhat unclear regarding ApplicationGroups and ProcessGroups - some
> >> setup guides did it one way, some the other. so i also seem to have a
> >> mix in my config file. what about having both dev1 and dev2 both in
> >> ApplicationGroup %{SERVER}%, should they be in separate AG, or does
> >> separate PGs take care of that? perhaps someone could tell me if
> >> there's something to be fixed here:
>
> > For Trac, due to limitations in Python wrappers for subversion, you
> > must use:
>
> >   WSGIApplicationGroup %{GLOBAL}
>
> > So, if using subversion you don't have a choice and if need separation
> > must use daemon process groups instead.
>
> Speaking of that, I'm not sure if you've seen that someone recently
> reported the "instance.__dict__ not accessible in restricted mode" issue

> withmod_wsgi2.5, despite his use of WSGIApplicationGroup %{GLOBAL}
> (seehttp://trac.edgewall.org/ticket/3371#comment:73).

>
> As we don't see the whole configuration he was using, it might be that
> the WSGIApplicationGroup directive was wrongly applied. OTOH, he
> reported success with a similar setup using mod_python, so it's a bit
> troubling. Are you aware of situations where that RuntimeError could

> still occur withmod_wsgi2.5 even when WSGIApplicationGroup %{GLOBAL}
> is used?

Would need to see their full configuration to be sure. I would suspect
they must have missed something as know of no issues in this area.

The only way to absolutely verify that running in correct interpreter
is to use a WSGI wrapper such as described in:

http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response

to capture values of:

mod_wsgi.process_group
mod_wsgi.application_group

as received by Trac.

If running in main interpreter, then mod_wsgi.application_group will
be an empty string. Ie., this is what %{GLOBAL} equates to.

Graham

[Bartosz Broda]

Hello Graham,

I was reporting the problem with "instance.__dict__ not accessible in
restricted mode" in http://trac.edgewall.org/ticket/3371#comment:73. I
cannot investigate the issue in more details at the moment, as I have
a few deadlines approaching. I will try to mirror the configuration
in VM environment in next week. If the errors will still occur, then I
will be able to provide the vm image for further inspection. Perhaps I
did something wrong during the configuration of mod_wsgi for use with
Trac (I followed this guide: http://trac.edgewall.org/wiki/TracModWSGI,
but I might have miss some details).

Best regards,
Bartosz

PS. In the meantime I can provide some details concerning my
configuration - what further info do you need?

[Graham Dumpleton]

On Oct 30, 6:33 pm, Bartosz Broda <bartosz.br...@gmail.com> wrote:
> Hello Graham,
>
> I was reporting the problem with "instance.__dict__ not accessible in

> restricted mode" inhttp://trac.edgewall.org/ticket/3371#comment:73. I

> cannot investigate the issue in more details at the moment, as I have
> a few deadlines approaching.  I will try to mirror the configuration
> in VM environment in next week. If the errors will still occur, then I
> will be able to provide the vm image for further inspection. Perhaps I

> did something wrong during the configuration ofmod_wsgifor use with

> Trac (I followed this guide:http://trac.edgewall.org/wiki/TracModWSGI,
> but I might have miss some details).

So you never looked at the following?

http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac

> PS. In the meantime I can provide some details concerning my
> configuration - what further info do you need?

The Apache configuration related to mod_wsgi would be best starting
point.

Graham

[Bartosz Broda]

On Sat, Oct 31, 2009 at 10:17 AM, Graham Dumpleton
<graham.d...@gmail.com> wrote:
>
>
>
> On Oct 30, 6:33 pm, Bartosz Broda <bartosz.br...@gmail.com> wrote:
>> Hello Graham,
>>
>> I was reporting the problem with "instance.__dict__ not accessible in
>> restricted mode" inhttp://trac.edgewall.org/ticket/3371#comment:73. I
>> cannot investigate the issue in more details at the moment, as I have
>> a few deadlines approaching.  I will try to mirror the configuration
>> in VM environment in next week. If the errors will still occur, then I
>> will be able to provide the vm image for further inspection. Perhaps I
>> did something wrong during the configuration ofmod_wsgifor use with
>> Trac (I followed this guide:http://trac.edgewall.org/wiki/TracModWSGI,
>> but I might have miss some details).
>
> So you never looked at the following?
>
>  http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac

I looked there, but the only relevant thing I found concerning
multiple instances of Trac was to run all of the instances in one
python interpreter. But to tell the truth I didn't have enough time to
read modwsgi wiki in depth :(

>
>> PS. In the meantime I can provide some details concerning my
>> configuration - what further info do you need?
>
> The Apache configuration related to mod_wsgi would be best starting
> point.

For every project I have this configuration:

WSGIScriptAlias /trac/PROJECT /var/trac/PROJECT/eggs/cgi-bin/trac.wsgi

<Directory /var/trac/PROJECT/htdocs>
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>

The trac.wsgi files are created by trac-admin <env> deploy <dir>, so
it looks like that:

import os

def application(environ, start_request):
if not 'trac.env_path_parent_dir' in environ:
environ.setdefault('trac.env_path', '/var/trac/PROJECT')
if 'PYTHON_EGG_CACHE' in environ:
os.environ['PYTHON_EGG_CACHE'] = environ['PYTHON_EGG_CACHE']
elif 'trac.env_path' in environ:
os.environ['PYTHON_EGG_CACHE'] = os.path.join(environ['trac.env_path'],
'.egg-cache')
elif 'trac.env_path_parent_dir' in environ:
os.environ['PYTHON_EGG_CACHE'] =
os.path.join(environ['trac.env_path_parent_dir'],
'.egg-cache')
from trac.web.main import dispatch_request
return dispatch_request(environ, start_request)

This configuration worked rather well in case of one and two projects.
After that I added another 6 projects it started to throw
RuntimeError. It works with similar configuration using mod_python
(and it is faster then configuration based on modwsgi!).
Another thing to notice is that on the same instance of apache there
is one Django application, tomcat5.5 and a few php sites (including
some soap based web services). Half of the trac instances use mysql
and another half use sqlite.

Best regards,
Bartosz

[Graham Dumpleton]

On Nov 2, 8:31 pm, Bartosz Broda <bartosz.br...@gmail.com> wrote:
> On Sat, Oct 31, 2009 at 10:17 AM, Graham Dumpleton
>
>
>
>
>
> <graham.dumple...@gmail.com> wrote:
>
> > On Oct 30, 6:33 pm, Bartosz Broda <bartosz.br...@gmail.com> wrote:
> >> Hello Graham,
>
> >> I was reporting the problem with "instance.__dict__ not accessible in
> >> restricted mode" inhttp://trac.edgewall.org/ticket/3371#comment:73. I
> >> cannot investigate the issue in more details at the moment, as I have
> >> a few deadlines approaching.  I will try to mirror the configuration
> >> in VM environment in next week. If the errors will still occur, then I
> >> will be able to provide the vm image for further inspection. Perhaps I
> >> did something wrong during the configuration ofmod_wsgifor use with
> >> Trac (I followed this guide:http://trac.edgewall.org/wiki/TracModWSGI,
> >> but I might have miss some details).
>
> > So you never looked at the following?
>
> >  http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
>
> I looked there, but the only relevant thing I found concerning
> multiple instances of Trac was to run all of the instances in one
> python interpreter. But to tell the truth I didn't have enough time to
> read modwsgi wiki in depth :(

Huh, it actually talks about it being preferable to use daemon mode
and run different Trac instances in their own process groups for
various reasons. That is, the opposite of what you are talking about.

It is certainly a bad idea to to run multiple Trac instances in same
interpreter where not the same code base, different versions of
plugins, or dependent modules or where need distinct Python egg cache
directories for projects. Also should be avoided if relying on
os.environ for setting Trac location.

The Python egg cache is a particular problem in your code as you
change it on every request and that could screw up badly on a
multithreaded configuration.

So, that particular auto generated trac.wsgi from trac-admin is
actually a bit dangerous. Normally one should not be setting Python
egg cache directory like that. It should be set once only.

Graham

[Cooke, Mark]

> >
> > > So you never looked at the following?
> >
> > >  http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
> >
> > I looked there, but the only relevant thing I found concerning
> > multiple instances of Trac was to run all of the instances in one
> > python interpreter. But to tell the truth I didn't have enough
> > time to read modwsgi wiki in depth :(
>
> Huh, it actually talks about it being preferable to use daemon mode
> and run different Trac instances in their own process groups for
> various reasons. That is, the opposite of what you are talking about.
>

As a noob at configuring web / apache processes, I think I may have mis-understood something here. Is the wsgi daemon mode different from the WSGIApplicationGroup? I am running apache on windoze and had avoided daemon mode because of the warnings that apache on windoze does not support daemon processes (I am sure I read that somewhere but typically cannot find references now)?

~ Mark C

[Bartosz Broda]

>> I looked there, but the only relevant thing I found concerning
>> multiple instances of Trac was to run all of the instances in one
>> python interpreter. But to tell the truth I didn't have enough time to
>> read modwsgi wiki in depth :(
>
> Huh, it actually talks about it being preferable to use daemon mode
> and run different Trac instances in their own process groups for
> various reasons. That is, the opposite of what you are talking about.

Sorry, I was trying to set up the Trac as fast as possible, because
other matters were more important at the moment :(.

> It is certainly a bad idea to to run multiple Trac instances in same
> interpreter where not the same code base, different versions of
> plugins, or dependent modules or where need distinct Python egg cache
> directories for projects. Also should be avoided if relying on
> os.environ for setting Trac location.

Only one thing is different among the configurations: a svn
repository. Probably that caused all the problems...

> The Python egg cache is a particular problem in your code as you
> change it on every request and that could screw up badly on a
> multithreaded configuration.
>
> So, that particular auto generated trac.wsgi from trac-admin is
> actually a bit dangerous. Normally one should not be setting Python
> egg cache directory like that. It should be set once only.

Thanks for pointing that out. I will try to adjust my configuration
accordingly. Maybe that info should be posted on
http://trac.edgewall.org/wiki/TracModWSGI too?

Do you think that bad performance could be caused by this egg cache
misconfiguration? As I told before - mod_python seems to work way
faster then mod_wsgi.

Best regards,
Bartosz

[Graham Dumpleton]

On Nov 2, 10:47 pm, "Cooke, Mark" <mark.co...@siemens.com> wrote:
> > > > So you never looked at the following?
>
> > > >  http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
>
> > > I looked there, but the only relevant thing I found concerning
> > > multiple instances of Trac was to run all of the instances in one
> > > python interpreter. But to tell the truth I didn't have enough
> > > time to read modwsgi wiki in depth :(
>
> > Huh, it actually talks about it being preferable to use daemon mode
> > and run different Trac instances in their own process groups for
> > various reasons. That is, the opposite of what you are talking about.
>
> As a noob at configuring web / apache processes, I think I may have mis-understood something here.  Is the wsgi daemon mode different from the WSGIApplicationGroup?

Yes they are different.

Only Apache 2.X on UNIX supports daemon mode. In daemon mode it can
run like fastcgi solutions where the actual application runs in a
distinct set of processes separate from the main Apache server child
processes. Because the implementation depends on fork, it cannot work
on Windows.

Configuration of daemon mode is affected by use of the
WSGIDaemonProcess and WSGIProcessGroup directives. See:

http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide#Delegation_To_Daemon_Process

The WSGIApplicationGroup directive, rather than control in which
process an application runs, controls which named Python sub
interpreter within those processes it runs.

That is, within a single process one can have multiple sub
interpreters with different web applications running in each. This
provides a level of separation between the applications so they cant
interfere with each other. Because of limitations in Python this isn't
perfect, but in most cases good enough. By default mod_wsgi will
ensure that each WSGI application specified by WSGIScriptAlias is run
in its own sub interpreter, so not strictly necessary to define
WSGIApplicationGroup.

The big caveat on this is that some third party C extension modules
for Python will only work if code run in the Python main interpreter.
That is, the first or primary sub interpreter created within the
process when Python is first initialised.

The usual reason such modules only work in this first interpreter is
that they use the simplified C API for thread state management, an API
that will not work win secondary sub interpreters. The Python bindings
for subversion fall into this category.

Thus, if using Python bindings for subversion in conjunction with
Trac, you must tell mod_wsgi that the application must be run in that
first interpreter. This is done using:

# mod_wsgi
WSGIApplicationGroup %{GLOBAL}

where %{GLOBAL} is special name meaning the primary or first
interpreter. If using mod_python the equivalent would have been:

# mod_python
PythonInterpreter main_interpreter

> I am running apache on windoze and had avoided daemon mode because of the warnings that apache on windoze does not support daemon processes (I am sure I read that somewhere but typically cannot find references now)?

As explained, on Windows you have no choice as that feature doesn't
exist and will never exist.

For Windows this is general is not an issue as Apache on that platform
is single process and multithread and don't run up against various of
the problems you do with embedded mode that you do on UNIX systems.

You still though have to use WSGIApplicationGroup to force Trac to run
in first interpreter if Python subversion bindings used.

That you are stuck with a single process, means you can't run multiple
distinct Trac installations on one server if they use distinct Trac
code, plugins, dependencies etc. This is because for a single
interpreter you can't have multiple versions of same code coexisting.

For further information about process/threading models of mod_wsgi
read:

http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

For potential issues with using embedded mode, read:

http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html

Graham

[Graham Dumpleton]

On Nov 3, 12:48 am, Bartosz Broda <bartosz.br...@gmail.com> wrote:
> >> I looked there, but the only relevant thing I found concerning
> >> multiple instances of Trac was to run all of the instances in one
> >> python interpreter. But to tell the truth I didn't have enough time to
> >> read modwsgi wiki in depth :(
>
> > Huh, it actually talks about it being preferable to use daemon mode
> > and run different Trac instances in their own process groups for
> > various reasons. That is, the opposite of what you are talking about.
>
> Sorry, I was trying to set up the Trac as fast as possible, because
> other matters were more important at the moment :(.
>
> > It is certainly a bad idea to to run multiple Trac instances in same
> > interpreter where not the same code base, different versions of
> > plugins, or dependent modules or where need distinct Python egg cache
> > directories for projects. Also should be avoided if relying on
> > os.environ for setting Trac location.
>
> Only one thing is different among the configurations: a svn
> repository. Probably that caused all the problems...

Different subversion repositories I don't think would be the issue.
Normally Trac would handle that fine.

Looking at your configuration again, the mistake is that you are
using:

WSGIScriptAlias /trac/PROJECT /var/trac/PROJECT/eggs/cgi-bin/

trac.wsgi

<Directory /var/trac/PROJECT/htdocs>
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>

There are two issues with this.

The first is that the WSGIApplicationGroup directive isn't being used
in the first place so you aren't even using the main interpreter and
thus will definitely have Python subversion wrappers breaking
unpredictably. It would also have caused a separate copy in memory for
each Trac, using much more memory and bloating out Apache sizes. This
could cause whole system to slow down.

The reason it isn't being used is because the path for Directory
doesn't match where the WSGI script file is. It should have been:

WSGIScriptAlias /trac/PROJECT /var/trac/PROJECT/eggs/cgi-bin/
trac.wsgi

<Directory /var/trac/PROJECT/eggs/cgi-bin>

WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>

Note that have changed path for Directory directive.

The second issue is how Apache is even able to serve up the WSGI file
from that location given that there is no Allow directive for that
directory because of Directory not matching. Looks like the security
of your Apache installation is lax in some other area in allowing
access to parts of the file system it shouldn't without being
specific.

> > The Python egg cache is a particular problem in your code as you
> > change it on every request and that could screw up badly on a
> > multithreaded configuration.
>
> > So, that particular auto generated trac.wsgi from trac-admin is
> > actually a bit dangerous. Normally one should not be setting Python
> > egg cache directory like that. It should be set once only.
>
> Thanks for pointing that out. I will try to adjust my configuration
> accordingly.

I would suggest you use the configuration on mod_wsgi site of:

WSGIDaemonProcess sites user=trac group=trac processes=3 threads=25
python-eggs=/var/trac/eggs
WSGIScriptAlias /trac /var/trac/apache/trac.wsgi

<Directory /var/trac/apache>
WSGIProcessGroup sites
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.env_parent_dir /var/trac

Order deny,allow
Allow from all
</Directory>

That is, a single WSGI script file rather than many. With that single
WSGI script file being in /var/trac/apache.

Also, a single Python eggs directory specifed by python-eggs option to
WSGIDaemonProcess and at /var/trac/eggs.

Make sure eggs directory exists and writable to user that daemon
process runs as or that Apache runs as. Drop the user/group options
and/or set them appropriately depending on what user you want to run
Trac as. If options left off, then will run as Apache user.

Note that have used trac.env_parent_dir method for configuration so
that Trac knows that location is parent directory of many Trac sites.
So, read up in Trac documentation about what that is all about.

> Maybe that info should be posted onhttp://trac.edgewall.org/wiki/TracModWSGI too?

There are more than ample configurations in what is on the mod_wsgi
site.

> Do you think that bad performance could be caused by this egg cache
> misconfiguration? As I told before - mod_python seems to work way
> faster then mod_wsgi.

In summary your problems are:

1. WSGIApplicationGroup was being ignored because Directory path
didn't match where WSGI script file was installed. This would cause
subversion errors.

2. Lax security in Apache to allow WSGI script file in that location
to work without specific Allow directory.

3. Because of (1), separate interpreter used for each Trac and so lots
more memory. Plus you were using embedded mode, so will encounter
problems described in:

http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html

That is why it would have behaved worse than mod_python. Ie.,
misconfigured.

4. Not using a single Python egg directory. This wouldn't have been an
issue in end as each Trac was using different interpreter. Still bad
to change egg cache variable on every request.

5. Not using feature of Trac to manage lot of Apache sites and instead
treating them as separate.

Anyway, have to run now, but that should give you something to think
about.

Graham

[Cooke, Mark]

Wow!

Thanks for a really useful, informative answer (and apologies for top posting but that is all I wanted to add).

> -----Original Message-----
> From: trac-...@googlegroups.com
> [mailto:trac-...@googlegroups.com] On Behalf Of Graham Dumpleton
> Sent: 02 November 2009 23:36
> To: Trac Users
> Subject: [Trac] Re: mod_wsgi + multiple projects - works
> well, but unclear about a few things

[Bartosz Broda]

Thank you for very comprehensive answer. I will correct configuration
soon, and let you know how that worked out.

Best regards,
Bartosz

[Bartosz Broda]

On Tue, Nov 3, 2009 at 1:05 AM, Graham Dumpleton
<graham.d...@gmail.com> wrote:
> In summary your problems are:

Thanks for pointing them out. I managed to configure the Trac and
Apache properly now (or at least I think so). Trac is running like a
lighting now with mod_wsgi :-).

Best regards,
Bartosz