Opened 8 years ago
Last modified 7 years ago
#1869 new task
Switch trac to mod_wsgi
Reported by: | strk | Owned by: | strk |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | SysAdmin/Trac | Keywords: | |
Cc: | neteler |
Description
Right now it's running on mod_python which makes it harder to monitor and possibly slower.
Was suggested by Markus Neteler but I lost trac of where, so here's a ticket to trac it :)
Change History (6)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
I agree, if you are willing to test moving an instance to mod_wsgi to figure out the right configuration then we should try it. We just need to be minimally disruptive.
For standalone, are we talking standalone WSGI or the built in Trac service. The first would work and I'd be happy with uWSGI or gunicorn.
I have experience with all the above and can help with issues.
comment:3 by , 7 years ago
My initial though for standalone was using trac's service proxied through apache, which would be minimally invasive to test -- simply spin up the new trac in standalone mode and add the proxy directives; I'm not sure what would be required to get wsgi working on the currently running apache instance, considering it's age. Ideally, once a new server becomes available, it would be best to move instances to their own containers distinct from both postgres and the web server front end, and the configuration specifics should be evaluated at that time.
comment:4 by , 7 years ago
apt-get install libapache2-mod-wsgi a2enmod wsgi
- create the wsgi file, I think trac has a script to generate it (trac-admin deploy)
https://trac.edgewall.org/wiki/TracInstall#RunningtheStandaloneServer
- create the apache rule for one instance to test
service apache2 reload
I'm not sure tracd was intended for the loads we have.
comment:5 by , 7 years ago
If the wsgi module matching the running version of apache is available, then by all means install it and test it against one of the instances if the trac configuration will allow that (being sure to make a backup before attempting of course).
As for tracd in standalone mode - it wouldn't cut it on its own, but behind a proxying load-balancer (Apache, nginx, etc.), it may be on par with wsgi and would allow running instances as different users or even split across multiple servers in the long run. See https://trac.edgewall.org/wiki/TracNginxRecipe for an nginx example.
The WSGI approach is indeed a good option to improve performance; another option would be running trac in stand-alone mode and proxying it through apache.