Last week, we upgraded our Subversion servers to improve reliability. We have never had an incident of data loss. However, with the old configuration, we had a record of about 99.5% availability - not good enough. Subversion services were down for about an hour last month, when our trac servers took heavy loads. That was shortly after midnight, one of our quietest times. Thanks to our users, if there is any SVN problem, anywhere in the world, we hear about it immediately. My email and IM lit up in about three minutes.

We used the very first build of the Assembla software to set permissions on our Subversion repositories. SCM is a requirement for distributed software teams. Even after adding dozens of NEW EXCITING and COMPELLING features, the logs still show that about half of Assembla users are mostly Subversion users. So what are we doing for those users?

We assign each new space to a set of trac and svn servers. We get new servers as we serve more spaces, ensuring responsiveness. We moved trac to a new box, away from the svn servers, to guarantee that heavy loads in trac will not slow down svn. We have also put in real-time replication of svn to failover servers.

The real-time backup is important, but we have RAID, and in our experience, Subversion itself has never gone down.

The most important thing that we did was to separate trac from svn. According to our analysis, all of the recent slowdowns in SVN were due to overloading of trac processes on the same server. Trac is designed to run on the same servers as SVN, and most hosts run it that way. However, trac has weaknesses that can cause it to become overloaded. For example, if a user commits a big file, and a web crawler asks to see that file in a changeset, trac will stop the server and start running a huge diff. Then svn is slow or apparently unavailable. We’ve patched a lot of these places where trac does stupid things, but we’ve also eliminated the impact on svn by moving trac to a different box.

This upgrade emphasizes our commitment to serve commercial and enterprise customers. The system was always important for supporting our own commercial development clients, but when we first opened up Assembla.com to outside users, we got a lot of open source and hobby projects. Now, about 85% of Assembla projects are private, and a good percentage of them are commercial and enterprise projects.  Those projects are getting infrastructure improvements, and tools, such as the new Portfolio Manager tool.

We also committed to matching our competition on availability and beating them on features.

Our subscription plan, including support, backup to your storage, and extra disk space, is $49 per month. Many of our competitors offer lower priced plans. Some of users ask “can I get a lower priced plan to start with”. Yes. How about free? Our free plan offers more than the competition offers in their lower priced plans. I’m going to discuss this pricing strategy in a future post. Quick preview: It’s hard to see the point of charging an amount that is enough to turn away users, but not enough to support a high quality service. There are better revenue models.