Request Tracker is a really neat support tool, but one of the common complaints I heard from people using it during a previous project was that it was pretty slow.
There wasn't much we could do about the (overloaded) server it was running on, but I found that
enabling mod_deflate really
helped.
After watching this
great video though, I was inspired to look into it a bit more, focussing this time on latency.
Description of tests
- RT 3.6.7-5+lenny4
- Running on a Debian Lenny vserser.
- Server is on the LAN.
- Firefox 3.6.6 client (with Firebug 1.5.0)
Also note that I was looking for the "best case" for each of the different configurations and so each screenshot was taken after reloading the homepage 10-20 times to maximize cache hits (thanks in large part to
mod_expires).
(Is there a nice automated way of measuring average latency?)
Stock RT 3.6Using the default
apache2-modperl2 config file (as supplied by RT), here's what the homepage (logged in as root) looked like before I changed anything:
The purple section here indicates the time spent waiting for the server. This shows that the server (running
Mason inside
mod_perl) is doing quite a bit of processing, including a lot more work than you'd expect while serving static files. It's quite impressive to see how fast the images are being served (directly by Apache) in comparison with the Javascript and the CSS files (which go through Mason).
The reason while Javascript and CSS files have to be served by
mod_perl is that they are in fact templates. They contain a few Mason variables which must be substituted before being served.
Looking into it further though, all of these replacements have to do with variables defined in RT_SiteConfig.pm (mostly the install path). Here's an example:
var path = "" ? "" : "/";
which gets turned into:
var path = "/rt" ? "/rt" : "/";
So as long as these paths don't change, then there is no need to re-generate these files.
Static Javascript and CSSThis next diagram was produced after configuring Apache to serve all Javascript and CSS files directly from Apache:
The way I did that (without modifying any of the original files) was by saving the Javascript/CSS sent to the browser and using
mod_rewrite rules to serve these files instead of the original templated ones:
# Serve static files directly
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/ahah.js$ /var/www/rt/ahah.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/cascaded.js$ /var/www/rt/cascaded.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/class.js$ /var/www/rt/class.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/combobox.js$ /var/www/rt/combobox.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/list.js$ /var/www/rt/list.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/titlebox-state.js$ /var/www/rt/titlebox-state.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/util.js$ /var/www/rt/util.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/css/3.5-default/main-squished.css$ /var/www/rt/main-squished.css
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/css/print.css$ /var/www/rt/print.css
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/webrtfm.css$ /var/www/rt/webrtfm.css
Removing unnecessary imagesFinally, one thing I noticed from this last graph is that the rounded corners in the theme require a number of small images. While these don't take a whole lot of bandwidth, they do require quite a bit of back and forth between the browser and the server.
So I replaced all of the "rounded corner" images in the
main-squished.css file with the following CSS attributes:
-moz-border-radius-topleft: 8px;
-moz-border-radius-topright: 8px;
-moz-border-radius-bottomleft: 8px;
-moz-border-radius-bottomright: 8px;
-webkit-border-top-left-radius: 8px;
-webkit-border-top-right-radius: 8px;
-webkit-border-bottom-left-radius: 8px;
-webkit-border-bottom-right-radius: 8px;
(yes, Internet Explorer users probably don't get the rounded corners... oh well)
This eliminated a number of roundtrips and shaved off a few more milliseconds:
Merging CSS and Javascript filesBy this stage, the pages are pretty snappy so there is not much to be gained anymore, but I figured I'd try to reduce the latency a bit more by combining all Javascript files into one (and doing the same for CSS files with the exception of print.css). This is what I got:
(Note that I also took the opportunity to
minify both squished files to reduce the filesize.)
Not a huge improvement and I unfortunately had to copy quite a few Mason templates from
/usr/share/request-tracker3.6/html/ to
/usr/local/share/request-tracker3.6/html/ and then replace all of the script tags with a single one in html/Elements/Header.
Others things to look intoI've stopped here, but there might be ways to further reduce the processing time on the server (hence the latency) by tuning
mod_perl/Mason or
Postgres. The
RT wiki also has a few pointers.
Replacing Apache with
Nginx (which means moving to
FastCGI) was something I considered, but after trying it out, it turned out that it would add about 100ms of extra latency.
Feel free to leave a comment if you've found something else that makes a big difference on your site.
Debian Day will take place on the first day of DebConf10, Sunday, August 1, 2010 from 10:00 AM to 6:40 PM at Columbia University, New York City, New York.
We would love to see you join us at Debian Day. Registration is required but is free. If you are not already registered for DebConf10, please send an e-mail with your intent to attend to debianday@debconf.org.
Debian Day and DebConf10 are going to be great. We re looking forward to seeing you in New York on August 1! More information on Debian Day is available at DebianDay.org.
the DebConf team
Whilst 
I'm running a power management track at the 
Bug-Squashing-Party in Munich
We are 
Currently I own and use an iPhone 3G. I bought it almost two years ago, when the local phone provider LMT started offering the iPhone legally. I had a pretty good experience with it most of the time, but now it is showing its age:
)
So at this point my plan is: get my iPhone repaired and get a promotion or a project where I can justify a company-paid HTC Desire and then hope that Nokia/Intel really get their stuff together and make MeeGo a great smartphone platform over the next year or two.
Update: Got my iPhone 3G back from the warranty . It is in quotes because they just gave me a new iPhone 3G. The battery lasts for 3 days of minimal use and it has not crashed yet. The recovery process was a pain again caused by iTunes: iTunes refused to restore my backup onto the new phone, because my backup was made on a iOS 4.0, while the new phone I got from the warranty has 3.1.3 on it. So I had to set this phone as a new phone, initialise it, make a backup, upgrade to 4.0, restore from the (empty) backup, then reset the phone to factory settings again and only then I could start restoring data from my original (pre-warranty) backup and start copying my data on to the device. All in all it took nearly 3 hours if iTunes doing something and almost a dozen reboots of the phone. Almost half of that time was spent doing completely unnecessary steps to work around the fact that iTunes is braindead.
I ll continue using my iPhone for now, keeping my eyes on the newest Android phones and also waiting for the long-promised first MeeGo phone from Nokia.
Last weekend (2010-07-02 2010-07-04) nine people met at the FAI developer workshop at 
), managing ~25 machines with less than 20 FAI classes. He s not using 
On Sunday we continued with discussions and development.
Our work-log of the weekend:
Some time ago, someone posted to a development mailing list about
a piece of code, Cc:ing some people who had modified the code in
recent past. Within hours, the original author replied to complain
about not being Cc'd.
Several thoughts went through my mind:
Today, virtually all of the free software available can be found in packaged form in distributions like Debian and Ubuntu. Users of these distributions have access to a library of thousands of applications, ranging from trivial to highly sophisticated software systems. Developers can find a vast array of programming languages, tools and libraries for constructing new applications.
This is possible because we have a mature 
Thanks to some recommendations from 
The current version of 
During the last three months and since my 
Many people run Debian testing or unstable or some mix thereof. This works pretty well for a development system or a general desktop system if you know a bit about what you're doing (note: nonetheless officially not recommended). Sometimes you throw packages from 