This is a guest post written by Marcus Gartner. Marcus’ passion for computers and sports runs deep. He recently graduated from Brown University where he studied computer science and competed on the men’s varsity water polo team. He’s gained invaluable software development experience while interning at Amazon, and his projects and peers at Fanium continue to nurture his web design and server administration skills.
Just as a craftsman is only as good as his tools, web developers are only as good as the software they use to create and manage their web applications. For a startup like Fanium, New Relic is one of the sharpest tools in the shed. By utilizing New Relic during our website’s launch, we were able to decrease the resource demand on our servers, and drastically reduce response times of our main app server and external API server by over 900 and 350 milliseconds respectively.
Before we get started, I’d like to tell you a little bit about Fanium. Less than six months ago, our team of Brown University undergraduates designed a new way to deliver sports information as quickly as possible. Fanium aggregates and filters Tweets in real-time from local sports writers, analysts and official team Twitter accounts. A stream of these Tweets accompanies live scores to give users the most up-to-date information about their favorite teams.
Within hours of launching, we began to question the speediness of our site. While it was not dreadfully slow by any means, we were expecting lower response times due to the clutter-free, low content nature of our pages and because of our small initial user base. This is where New Relic came in. From the minute we started using New Relic, it felt like corking a bat. It just didn’t seem fair. We had immediate insight into what was happening within our application and the servers powering it.
The first problem we discovered with New Relic was an error than occurred when AJAX requests hit our server to automatically update scores on the front end. Not only was this having a negative impact on our user experience, but it was also eating memory on our server. Because these requests are called on a frequent interval in order to keep scores as up-to-date as possible on the frontend, there were a large number of requests leading to application errors. These errors ate up memory, to a point where our more than capable server was reaching dangerous levels of 80% or more memory usage. Thanks to New Relic’s error tracking feature, we isolated the casue of the errors down to the specific lines of code without having to dig through log files. Upon deploying a fix, our server’s memory usage immediately returned to a healthy level.
As we tinkered more with the features provided by New Relic, we began to find bottlenecks in our code which negatively affected our response times. In one case, New Relic helped us discover a particular feature on our site which performs a very expensive database call. Fortunately this feature did not need to be updated frequently, so caching the generated block of HTML for minutes at a time was an appropriate solution which greatly reduced the frequency of the deadly database query. This simple change was enough to reduce our average server response time from ~1200ms to ~250ms, making a huge improvement to our site’s performance. Below is a graph of the average response time of our server, with the vertical line representing the time at which the fix was deployed.
In another case, an API server separate from the application server, which is responsible for collecting, sorting and serving up Tweets to the frontend, was performing some unoptimized sorting algorithms. By refactoring some of our code, we were able to drop the server’s average response time from ~375ms to a lightning fast ~5ms.
In addition to these specific problems, New Relic has helped solve many other issues at Fanium with incredible efficiency, freeing up time for us to do things that we love, like watching sports. For our young Internet company, New Relic will remain an invaluable tool for building and managing our services.