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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
