bartosz.broda at gmail
Nov 3, 2009, 11:48 PM
Post #14 of 15
(877 views)
Permalink
|
|
Re: mod_wsgi + multiple projects - works well, but unclear about a few things
[In reply to]
|
|
Thank you for very comprehensive answer. I will correct configuration
soon, and let you know how that worked out.
Best regards,
Bartosz
On Tue, Nov 3, 2009 at 1:05 AM, Graham Dumpleton
<graham.dumpleton [at] gmail> wrote:
>
>
>
> 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 [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
|
