New Relic: Homepage performance

By: Tom Giddings

Tags:

  • newrelic
  • performance
  • homepage
  • memcached

Earlier this month, Keith posted about our drive to improve performance on the desktop platform with regards to JavaScript bottlenecks, so I thought I’d mention one of the many ways we have been looking at optimising the ColdFusion side of the platform.

Our member homepage has undergone a fair number of changes recently, cramming lots of relevant content into the first page a member sees on logging in. While this has been brilliant for our members, it became apparent that the volume of content being loaded into the homepage was starting to take its toll on the load time of the page. So, with that in mind, we went on a performance mission to see what we could do to improve this.

First of all, we needed to generate some metrics to see how quickly these areas were actually running. To achieve this we made use of New Relic custom dashboards, and custom metrics. Once we had gone through and surrounded various blocks of code using a ColdFusion custom tag, we ended up with a lot of fancy load time stats and graphs like this one showing load times for each chunk of content:

One of our pretty graphs

From this, we started looking at problematic areas, and the strategies we could use to improve performance, as indicated by the large blocks in the graph. One such area was our latest member feed (shown in purple above).

We decided with the nature of this particular content, that caching would be a good way to proceed, so we implemented server-side content caching using memcached for this feed; loading content from the much quicker cache to avoid database queries as much as reasonably possible (settling on a cache time of a few minutes). This resulted in some pretty noticeable differences:

  • In the space of 24 hours, we carry out around 61,000 less database queries on the homepage.
  • Our load time for this particular section fell by a respectable 82%.
  • The average response time for the homepage fell by around 30% (the graph above shows average response time in seconds).

Of course, this was just a small part of our recent performance drive, and not everything can realistically be cached in this way, but it showed the benefits of keeping detailed metrics on our code beyond the overall page view.


About the Author

Tom Giddings

Tom is a web developer based in the London office. He can mostly be found working on the ColdFusion side of the platform, occasionally delving into the world of Ruby and frontend development.