Tim's Bits and Pieces: Work

Speedup of Trac Static Content

TimP — Wed, 25 Aug 2010 23:03:54 +0200

At work I recently spent some time working on getting our hosted Trac to run faster. I found one simple little trick that gave up to a 20% speed improvement, so I thought I'd share it here.

The basic idea is that Trac has a lot of overhead due to executing a pile of Python code for each requested file including static content like the logos, background images, CSS, etc. If you tell Apache just to skip the Python code for the static content you can save a lot of time and processing power. All the default static content is under "/python/library/path/site-packages/trac/htdocs" which Trac servers up as "/chrome/common/". Basically a request for http://server.com/trac/chrome/common/logo.png will get a file from somewhere like /usr/lib/python2.5/site-packages/trac/htdocs/logo.png on the harddisk. To skip Trac for this we want to add something like the following to the Apache configuration (AliasMatch is part of mod_alias):

 	AliasMatch ^/(.+)/chrome/common(.*) /usr/lib/python2.5/site-packages/trac/htdocs$2

This matches any request for a path that matches /something/chrome/common/something_else, and then sends back the file located at /usr/lib/python2.5/site-packages/trac/htdocs/something_else; preventing the Trac Python code from running. Since there is about a dozen images, CSS files, and JavaScript files for each Trac page the time saved by this very quickly adds up.

Joel on DRCS

TimP — Mon, 22 Mar 2010 23:03:54 +0200

We where talking about merging today and one of my co-workers pointed out that some of the advantages of Distributed Revision Control Systems (DRCS), are actually more of a case of "distributed rcs rules because I never read the manual for svn and drcs is complex enough that it forced me to read the manual". For example Joel Spolsky (of Joel on Software) writes about Mercurial:

The interesting part is that these systems think in terms of changes, not in terms of versions.

That's a very zen-like thing to say, I know. Traditional version control thinks: OK, I have version 1. And now I have version 2. And now I have version 3.

And distributed version control thinks, I had nothing. And then I got these changes. And then I got these other changes.

Uhmm, no, that's not quite right. On the back-end Subversion stores changesets not versions, and since way back in the 1.0 days the documentation has always encouraged a model of thinking about changes not versions, see the section on merging in the old Subversion book for instance. The difference is that when he didn't understand Subversion it was forgiving enough that he could still use it, but with Mecurial he had to go and read the manual. Not that there aren't real benefits to using Mecurial or Git, but they often "solve" problems with Subversion that are just as well solved by reading the Subversion manual.

By the way Technically most revision control systems store changesets rather than versions, and then generate the "version" you need when you request it, at least back to RCS from '82. Though some would encourage you to have a mental model of versions instead of changesets.

PS. I use Git myself for most of my personal projects, and the company I work for (Codesion) plans to add support for Git some time this year, and also switch our internal development over to Git at some point, so it's not like I have some sort of hatred of DRCS.

The Company Formerly Known as CVSDude

TimP — Tue, 02 Feb 2010 23:03:54 +0200

The company I work for has changed it's name from CVSDude to Codesion. I'm going to miss CVSDude, but I think Codesion is probably better.

The main reason for the change is to make our company more enterprisy. Apparently our sales team where having some problems in the enterprise market, with both the CVS and Dude parts of the name. CVS is an obsolete technology, 90%-95% of our customers use the more modern Subversion instead, and with the planned addition of Git later this year, it would become even worse. In addition some people apparently have trouble trusting a company with Dude in it's name.

Bulk emails should not come from support

TimP — Fri, 18 Dec 2009 23:03:53 +0200

Today my company sent out a bunch of emails about a service update to our customers. Approximately 16,000 emails. To make things easy for customers who wanted to ask questions about the changes we set the reply to field on the emails to be our support email address. This was a mistake. The first problem is that out of 16,000 people a reasonable number are going to be out of the office a week before Christmas, but that was OK, you just delete the dozen or so new Cases with "Out of Office Auto-reply" in the subject. No, the real problem was the infinite loops of auto-replies that our case management system created with some customers ticket systems.