In our previous post, we discussed how we were planning to make some changes to address some of our recent performance issues. Since that post, we have been working hard to speed up Unfuddle and decrease load times. You can see below for some highlights of what we have done so far.
We have moved all Unfuddle accounts to more powerful and capable servers. We previously used a fleet of Amazon’s m1.large instances but we have migrated to m1.xlarge instances. This means significantly increased memory and CPU. This has already greatly reduced some of our more common server-related issues.
We used to have an embarrassingly small amount of caching (of any kind) implemented in Unfuddle. We have now gone through the entire application and begun caching at a number of different levels. This has had a direct result on page load times and API requests across all of Unfuddle.
Ticket reports have unfortunately been one of the slowest API endpoints as a result of their complexity. We have been working to reduce the time it takes to generate a ticket report and to display it in your browser once it has been generated. We are also caching report data where feasible to further reduce the load times.
We were careful to measure our average response times before making any changes so that we would have empirical data telling us if we were going in the right direction. Here are the results for select API endpoints:
As you can see, on average, most requests are taking about 33% of the time. That’s a huge improvement!
And we are not done...
While the improvements listed above have made a difference, we are not done yet. Over the next few weeks we are going to continue our optimization efforts. We will be working to improve the speed of Subversion and Git repository access as well as further optimizing ticket reports.
After that, keep an eye out for some changes to the Unfuddle interface. We are going to be implementing some things that we think you will find pretty helpful...