How exactly should you gain visibility into the performance levels your customers are seeing when they use your Web applications? One method that’s still in wide use is compelling users to install plug-ins and background processes. But for many users, that’s not just performance monitoring, that’s behavior monitoring. You don’t want your analytics tool straying too far into the realm of potential privacy violations.
Until HTML5 can fully implement its standard methodology for capturing browser performance specs, Web developers need alternatives. One candidate, provided by a company RWW spoke with called New Relic, is to have Web apps servers supply performance measurement agents to clients while the apps themselves are being served. These agents communicate not with your server, but with New Relic instead, and the results are made visible as analytics charts through your browser.
“The difference between what we’re doing and what our competitors are doing is, we essentially come up with what we call ‘curated’ metrics,” explains Graham Dumpleton, New Relic’s principal engineer. “We work out what we think is going to give you the most value quickly, and highlight those metrics. That way, when you install the product… instantly you’re getting data. So you don’t have a situation where the customer has to fiddle with it, configure it, work out what it is they can actually get out of it that’s useful to them. We find out what are the things that are truly important to a majority of people, so as soon as they turn it on, they’re instantly getting value from it.”
Like many companies in the Web app space, New Relic started out as a tool for Ruby on Rails. It soon expanded into Java, .NET, PHP, and added Python to the mix earlier this month. As Dumpleton explained, the measurement processes for each language and corresponding framework may be entirely different. For example, measuring Java performance may require bytecode manipulation, literally inserting instructions into the interpreter stream. PHP, by stark contrast, is written in C, so measuring PHP performance requires communicating with its internal APIs. For a dynamic scripting language like Ruby, inserting the measurement code may be done using monkey patching – modifying the dynamic classes on the fly.
“That’s a big challenge for us, because you can’t provide just one solution for each language,” explains Dumpleton. “You have to try to instrument the specific frameworks… and target specific implementation problems. It has to be targeted. You can’t just blanket-profile everything in the language and what’s happening in the code, because there’s too much overhead. So we target specific items of interest, and that’s how we get the set of curated metrics.”
New Relic’s new Python agent is designed to work with the language’s standard Web Server Gateway Interface (WSGI). As Dumpleton spelled out quite clearly on his Google+ feed earlier this month, “The New Relic Python agent is not just for Apache/mod_wsgi. Any WSGI 1.0 compliant WSGI server should work.” That includes cloud-based WSGI deployments. (By the way, mod_wsgi is Dumpleton’s own contribution to Apache.)
Once the files are installed on the Web app server, the admin adds the name of the path to New Relic’s .INI file as a pair of instructions to the WSGI application script file. Then there is a small but not unimportant matter: the addition of a wrapper function around the entry point of the Python app itself. This is the only addition that needs to be made to the actual code. Python allows the use of so-called decorators to augment the default functionality of an existing function or method without creating a new subclass. In this case, the syntax @newrelic.agent.wsgi_application() may be used for an app whose entry point is a function named application.
New Relic’s information collection model is layered, Dumpleton goes on. At the lowest level of its model is what it calls the harvester, where the data is collected and sent off to the core app. Above that is an aggregation layer, followed by another layer that captures data applicable to a specific framework or language, and at the top the hooks for the framework itself. The bottom two layers are the same for all New Relic agents, from Ruby through .NET to Python.
Just after Dumpleton was brought into the company last December, he developed a Python agent on top of the existing C-language core for the company’s PHP agent. Later Dumpleton and his colleagues were able to slide the Python agent onto a Python core for New Relic’s latest agent for Python apps.
“We’ve actually optimized our own application at New Relic by monitoring it with New Relic,” admits the company’s marketing director, John Essex. The company’s suite of tools now includes server monitoring as well as client-side, using a so-called “AppMap” that takes account of third-party Web services incorporated into an app. “It maps your environment for you; you can look into any third-party service connected to an application and tell if there’s a bottleneck or not.
“We find that in many shops, people wear more than one hat… and developers fulfill many roles, one of them being operations,” Essex adds. “We’ve often called this the operations tool that developers love.”
