Since we seem to have lots of issues with our Trac install (most people find it slow; some find its availability disappointing), I thought I'd look at the Trac website to find out how their dev team advises on these matters. Well, the conclusion is simple: we're using the 'tracd' method of running Trac and this is certainly the only way how *not* to do it.
They advise CGI for small sites or FastCGI/WSGI for larger sites. I estimate us to be in the latter category, so I took my own VPS (which is in the former category, but also runs Trac) and configured it for FastCGI. The steps turn out to be quite simple. I volunteer to make the same changes on c-l.net (which drewc already set me up for), but I'm posting here for review. The last thing I'd want is to open up a security hole in the site.
Steps are:
* Install mod_fcgid (although I used mod_fastcgi, which is older and not recommended by the Trac team; it works though) * Add the script handlers and the script alias to the httpd.conf file within the virtual host section for trac.c-l.net:
AddHandler fastcgi-script .fcgi ScriptAlias / /path/to/apache/cgi-bin/trac.fcgi/
* copy the 'web/' subdir of the installed Trac into the cgi-bin directory * copy in the cgi-bin directory "fcgi_frontend.py" to "trac.fcgi" * add to the trac.fcgi script - before the first 'import' statement:
import os os.environ['PYTHON_EGG_CACHE'] = "/tmp/httpd-egg-cache" os.environ['TRAC_ENV_PARENT_DIR'] = "/path/to/parent/trac/project/dirs"
* create /tmp/httpd-egg-cache with the user and group used to run httpd and '700' access settings * restart apache
Comments?
The effect of the change is this: by default, a single trac.fcgi application will be loaded - just as with our current situation. However, on high demand, additional instances will be spawned - contrary to the current situation, where a single tracd will try to handle all requests. When the load is over, the number of servers is scaled back to normal (1).
Bye,
Erik.