BT

New Relic updates RPM to Improve Collaboration and Integration

by Robert Bazinet on Feb 19, 2009 |

New Relic announced the availability of RPM 1.2 which goes a long way into making the job of the developer better with improved collaboration and integration.

RPM 1.2 introduces features which address pain points seen by many Ruby on Rails developers today.   InfoQ caught up with the New Relic CEO Lewis Cirne at a recent conference and was able to witness the features first-hand.  Lewis gave us the opportunity to discuss the features and explain how they will be used by a development team.

When asked what the new feature, Deployments Analysis and Tracking, is and why it is an important update for developers:

When developers update an application with new code, they typically hold it in a staging environment while they are testing and then when the code Is ready for prime time, they deploy it to production, typically using a deployment tool like Capistrano. It is this time in an application’s lifecycle that its most critical in terms of performance and stability. New features and changes may have introduced unforeseen performance problems. RPM now supports this critical deployment process in several ways: First, we “mark” the time of each deployment as a reminder to the developers that a new version of the application took place at a specific time so they can see in every graph an instant comparison of performance before and after that version was deployed; second, we save all the key performance indicators for each application in an archive so the team can see the progress of their improvement efforts from version to version.

The level of detail a developer can gleam from this type of tool is obviously important and will determine if the tool will be useful, Lewis explains what we can expect:

For each new version of the application deployed, RPM captures the title of the deployment, time, who was responsible, and the average CPU utilization, memory utilization, app response time, throughput, database response change and errors per minute in the time since that deployment took place. This data can be immediately compared to the same stats for the last several deployments. This enables the team to track its progress. It also enables the team to instantly recognize when they have released a version of the app with serious problems. Using RPM’s drill down capabilities, users can trace problems with an application down to very granular level – to specific SQL queries, specific controller actions, etc.

The explanation of the new Integration with Other Development and Communication Tools features includes tools used by popular communication utilities we all use:

A team of developers typically use a lot of tools in their work for coding, testing, deploying, prioritizing work, and communicating.  What can be frustrating when the team is moving fast and under deadline pressure is the transition from tool to tool. It usually involves a lot of cutting and pasting from one tool to the next. RPM has taken some of the pain away by allowing RPM users to integrate with some of the most commonly used tools. Twitter is often used by teams to communicate and new RPM can send a message (a tweet) to the team’s account when there is either an incident detected in the application or a new deployment has been completed. The Tweet contains links directly back to the relevant page in RPM. Campfire is another tool designed for rapid messaging by a development team. RPM also sends incident alerts and deployment notifications to Campfire accounts. Lighthouse is a trouble ticketing application. Within the RPM errors page, we have created a link which says “file a ticket with Lighthouse”.  Click on the link and all the error data gets sent to Lighthouse and a new problem ticket is opened automatically. Finally, Capistrano is a popular deployment tool used in the Ruby on Rails community. RPM can automatically detect a new deployment of your app and get information about that deployment out of Capistrano such as who was responsible for the deployment, what changes were included in the version deployed, and other data which will be helpful to the team if problems with that version arise.

On the future of the new Performance Data API and creating opportunity for third-party developers:

Actually we have already seen some interesting uses for the API. The API currently does two main functions – it automates the creation of a New Relic RPM account from within another application and it allows top level performance data to be pulled into that other application or environment. Our first public use of the API was by RightScale, the leading provider of cloud management tools. They have integrated both API functions within their cloud management console. So now Rails apps deployed on cloud infrastructures like Amazon EC2 can be monitored from within the cloud management solution the team uses. We have several other customers and partners developing integrations. One allows app data to appear in the browser status bar. There are two other cloud hosting examples coming as well. We currently have an API contest running to encourage our customers to come up with creative integrations.

One new feature in RPM 1.2 is the idea of Notes which allows team members to communicate better.  It is explained as:

Notes is a really exciting feature designed to enable better, richer communications within a team. Anyone with access to an RPM account can see the notes for that application. With Notes, any RPM user can capture a performance graph, make his own observations about what is shows, and send the graph and his notes to a shared collaboration space. He can then capture another graph as his investigation proceeds, append that to the previous Note and continue in that way gathering data and making observations. He can direct his teammates to check out what he has observed and contribute their own analysis. The graphs, the underlying data, and the observations are all stored for later use. They make great teaching tools. They also enable a team to understand an application’s behavior by having a record they can go back and review as time allows.

Ruby on Rails developers know how critical it is to have an efficient controller and database access.  One of the newest features which will help developers using the plug-in is Controller and Database Summary, described as:

These reports are similar and both very useful to teams looking for ways to continuously improve performance. A question the developer often asks himself is “what is the best thing I can work on next to improve performance?” These reports help answer that question. The Controller Summary provides a list of all the controller actions in an application in one report. The RPM user can choose a time window, like, say, the Last 24 Hours. For each controller action, performance is aggregated for the time window in these categories – Times the controller was called, average response time, standard deviation from the average (sometimes the average masks the fact that the controller occasionally has really bad response time – why?), the min and max response times (to give you the outliers), the total time this controller action consumed in this time window, and what percentage of all the time each action consumed. From this one report a developer can see what controller is being called most often and how is it performing. The Database Report is similar but focused on analyzing performance of ActiveRecord model operations (database calls.) It shows all the ActiveRecord operations for a selected time window and allows you to sort them using several metrics including total time consumed, average time, and throughput time. For every operation you can compare to the same time window yesterday and a week ago so you can follow the behavior as your application changes. 

When asked which single feature he sees at the most important one to developers, Lewis states:

Not to sound like an economist, but it depends. I think the Deployments features will be really appreciated by teams that are updating their applications frequently. We have a few customers who re-deploy every day, if you can imagine it. For teams that are dispersed around the country or around the world, our various integrations and collaboration tools will be very useful. Finally if you have an app that uses a lot of database activity and is dependent on good database interaction, you will love the new Database Report.

More information about the new release of RPM is available on the New Relic web site.  A free version called RPM Lite is available to get users started but folks should refer to the table of available versions to determine which is best for their needs.  It only takes about 2 minutes to implement the solution.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT