I’ve been using Trac for managing all the bugs enhancements in CONGO for the last 3 years or so. For the most part, it’s been pretty useful, though I haven’t been thrilled with some performance problems I was having.
Most notably, a simple page load would take 4-5 seconds to come back.
I thought the initial problem was due to the older (v0.11) version I was running. But after a painful SVN crash and rebuild, and taking that opportunity to upgrade to 0.12 and move to a faster host, the performance problems were still there.
When reading Trac performance blogs, the first thing everyone says is “For gods sake, make sure you’re running mod_python!!!” Well, I was. So that wasn’t it.
I found the answer in an older blog post that mentioned the Chrome elements in Trac were rendered on the fly via Python. This didn’t make sense, as they were primarily static elements.
So why not cache them?
A quick tweak to the vhost configuration:
<LocationMatch /[^/]+/chrome> Order allow,deny Allow from all ExpiresDefault "now plus 12 hours" </LocationMatch>
(which, by the way, necessitated adding mod_expires in apache), and a restart, and my load times went from 6.6 seconds:
172.16.1.1 – – [13/Feb/2011:22:58:13 -0500] “GET
/chrome/site/stonekeep-ball-logo.gif HTTP/1.1” 200 6660
“http://trac.stonekeep.com/” “Opera/9.80 (Windows NT 5.1; U; en) Presto/2.7.62
Version/11.01”
down to zilch due to caching:
172.16.1.1 – – [14/Feb/2011:08:15:51 -0500] “GET
/chrome/site/stonekeep-ball-logo.gif HTTP/1.1” 304 –
“http://trac.stonekeep.com/wiki/WikiStart” “Mozilla/5.0 (Macintosh; U; Intel Mac OS X
10_6_6; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4”
Win!!!
