New Relic Reviews

The performance of a web application plays a critical role in how an application is perceived by its users. It is important to measure it, identify the causes if it changes and react swiftly to any unexpected changes. This article describes an industry leading tool, New Relic, and how it can be used to monitor and improve your site performance.

Setting up a good web application monitoring system can be tiresome, but it’s well worth it. Without the monitoring tools the only thing we could tell is if our site is performing as expected or not. In order to improve the performance we have to be able to identify the worse performing user actions and profile them independently to pinpoint the cause. New Relic achieves that and more in just a few screens, all without manually adding any profiling code to your application.

New Relic is a real-time application monitoring service, providing various metrics about the performance of your production site, covering everything from application database queries through to the time it takes for the end-user to view a page. This data is then collected, post-processed and converted to simple and clean charts presented in the New Relic web interface. Since the New Relic agent has to collect and report the data, it does add some overhead to the application stack. Unless you’re running a service that has to respond in a few milliseconds, however, the overhead added is minimal and is far outweighed by the value of the reports enabling you to detect and solve problems early.

This article covers both the basic functionality of New Relic (that can be used for free) as well as describing what the Enterprise version has to offer.

Getting Started

The New Relic installation is split into several distinct components:

• the agent component – a PHP extension, which collects the data and reports to a locally running New Relic daemon.
• the daemon component, acting as a proxy between the PHP agents and New Relic datacenters. The main responsibility of the daemon is to reduce the time of reporting the data to New Relic.
• New Relic reporting suite – the main New Relic website, where the data is presented for the user.

Both the agent and the daemon components are installed using the provided newrelic-install script. The script will detect the available PHP installations and deploy the agent extension to all of them.

Please refer to the official documentation for more detailed information regarding the installation and configuration of the New Relic package on your specific platform.

Basic Charts

“Forever. Seriously. That’s right. Free. Just the basics.” (newrelic.com)

While the free version of New Relic does not have all the bells and whistles of the Enterprise version, it does provide some basic, yet useful, feedback regarding your site performance.

Application Performance

If you are interested in an overview of how your application performs at PHP level, this is the chart to look at. It displays the average execution time of your PHP scripts in real time, split into separate layers by their execution type:

1. time spent to execute database queries
2. time spent in PHP
3. external web service calls

Depending on which of the application layers take the most time, different optimisation (or scaling) techniques can be applied.

1. The time spent in the database can usually be reduced by doing one or more of the following:
   • analysing the queries that are executed, ensuring that they are using indexes correctly or creating new indexes for them
   • caching the most frequently-accessed and computationally-expensive result sets from the database
   • optimising the structure of your application’s data using techniques such as database partitioning
   • scaling up the database layer (e.g. adding more slave nodes)
2. The PHP time is the time that your application is processing the data and good tactics for bringing this down could include:
   • caching intermediate results
   • optimising the code, using faster algorithms
   • adding more webnodes (if the hardware limits are reached)
3. A few things that can help to optimise the network operations:
   • cache everything that can be cached;
   • introduce an asynchronous job queue if possible.

Browser Performance

Even if the performance of your application is good, there is no guarantee that the users of the site will get it loaded within a reasonable timescale. The New Relic chart for browser page load time provides an overview of how your website is performing.

Similar to the application performance overview shown previously, this chart is composed of several separate layers:

1. Web application time tells how long it takes for your application to process the requests. More information about this layer can be seen in the application performance chart shown earlier in this article.
2. Network time is the time that is spent purely for the user request to travel to your application server and then for the response to reach the browser, disregarding the time spent in the application itself.
   To optimise this component one would need to review the network performance of your system architecture by considering the following questions:
   • do you compress the response sent to the site users (depending on Accept-Encoding)?
   • is it just that the response is huge and some of it can be loaded later?
   • is the bandwidth used reaching its limits and you simply need a faster network link?
   • would distributing your servers worldwide (see more on this later) help?
3. DOM Processing includes the time from browsers receiving the HTML until the DOMContentLoaded is fired. The work done by browsers is essentially a preparation to execute your JavaScript logic, thus, it prepares the DOM structure, preloads CSS (if there are any script tags after them) and JavaScript files.
   To optimise the site performance at this New Relic layer, there are several actions that can be performed:
   • make fewer requests to retrieve JavaScript and CSS files
   • minify and compress JavaScript and CSS files
   • set caching headers so that static files could be cached by the client
   • reduce the number of DOM elements
   • use a CDN for the static files
4. Page Rendering time is the time a browser takes to download everything needed after the DOMContentLoaded event; this is usually the time when all the images are downloaded. Similarly as for the JavaScript and CSS files, the list of actions available to optimise the delivery of static content includes:
   • optimising image files
   • using CSS sprites instead of multiple images
   • using correct caching headers
   • using a CDN to bring your content closer to the user (there’s also a chart for that, shown later in this post)

An extended list of rules and how they affect your website’s frontend performance can be found at Best Practices for Speeding Up Your Web Site. Also, there are several tools that can help you to analyse the frontend performance such as Yahoo’s YSlow or Google’s PageSpeed.

More information about the Real User Monitoring functionality can be found at How Does Real User Monitoring Work? (New Relic documentation) or How we provide real user monitoring: A quick technical review (New Relic blog).

Throughput Charts

Even if your application is performing very well, it is only performing this way given the request rate at that time. As the number of users on the site increases, new bottlenecks “appear” – which can slow the overall usage of the site or even bring it down. As a result, the rate your application is handling the requests is at least as important as the time it takes for your application to send the response.

There are two separate throughput lines available – one for the browser requests and one the application. The browser throughput tells how many pages were requested per minute. Some of those requests may be served from cache before even reaching the application server, other pages may include additional application requests via Ajax. Thus – the two lines may be completely different and suggest different optimisation targets.

Apdex Rate

In addition to measuring your website performance in time, New Relic provides an Apdex score, which tells how many of your site visitors were satisfied, tolerating or frustrated by the response time of the application.

Once the target times for the browser and application servers are set, it will be used to calculate the Apdex ratio:

• satisfied requests are all requests that have completed in less than the target time (T), and “pull” the Apdex score towards 1.0
• tolerating requests are those which have taken more than T, but less than 4*T. These requests are given the score of 0.5
• frustrated requests are all the rest, and their Apdex score is 0.0

The main difference between using the Apdex ratio and the application response time, is that no one request (outlier) can affect the global ratio more than any other. This makes it a more scientific metric for the global overview of your site’s performance if your goal is to answer the question “what proportion of the site visitors see a page loaded quickly enough?”.

For more information about the Apdex score see the New Relic documentation about this metric.

Worldwide Site Delivery

Is your site performing well for local users? What about the users overseas? The Internet is really fast these days, however it is not instant. The further your user physically is from your servers, the longer distance the information packets will have to travel.

To get a glimpse of how your site is performing for different countries, you could look at the worldwide Apdex chart. New Relic also provides more detailed information for the enterprise customers.

Since the performance problem in this case is usually due to the global network speed, there is no fix that can be applied locally – you’ll need to bring your service closer to the user. Depending on your application needs one or more of the following measures can be employed:

• use a CDN to serve static files from local servers
• use local dynamic content caching servers for slower areas
• implement your service locally for the slower areas

Enterprise Functionality

“The Total Package!”

The basic functionality that New Relic offers for free can give us a lot of valuable insights about the global site performance. We can see what areas need more attention than others and this alone can save some precious time while optimising the site. Yet, it does not provide some of the (sometimes crucial) information; where exactly is the bottleneck?

In addition to the free Lite account New Relic offers two more plans (Standard and Pro) which extend the basic reports and introduce some new ones, allowing you to drill down to the root of performance problems quickly and efficiently.

Application Profile Traces

One of the best features offered to help debug performance problems is the comparison between different web transactions and the ability to see timed application traces of slow calls. New Relic provides charts similar to those described above for each web transaction type (provided that New Relic supports the framework you’re using). Also, a list of slow transaction traces is included with the detailed information.

There are already several tools available to profile your PHP code, such as Xdebug and XHProf. Xdebug is a really powerful development tool as well as offering profiling capabilities. XHProf is simple to configure and relatively easy to use, and there are also companion tools such as XHGui which make life even easier. So what is different about New Relic?

The code profiling trace that New Relic provides is a call tree with only Incl. Wall (absolute and relative) information. This tree alone is not very well suited for a generic code analysis since it does not provide the count of how many times a method was invoked, nor its total time during the application run. The power of it is that it is integrated with all other New Relic features and is easily accessible for a quick review once a slower transaction is detected. In addition to PHP code profiling, New Relic also provides a separate report for slow SQL statements, with their execution times and call counts.

With the help of these integrated traces, finding slower pieces of the application code is a straightforward task, helping to keep the focus on the site as a whole while still being able to detect problems and pinpoint them to the method level.

Compare with Historical Data

In addition to displaying the current state, New Relic also provides a comparison mode. When this mode is turned on, all the basic charts are affected – in addition to the current data they now also provide information from one day and one week ago. This mode is especially useful to show whether the site is performing any better (or worse) than before.

Scalability

How well is your website performing under load? The easiest way to answer that is to look at the scalability chart that New Relic provides. The chart plots the application response time versus the throughput.

This chart can quickly give you an idea about how well your website is responding given that there are a certain number of requests per minute. If the response time is constant as the throughput increases then your site is performing well. However, if you notice that the response time is increasing together with the throughput then it is time to take action. Finding the bottleneck using New Relic should now be an easy task using the database and application code profiling tools described above.

More information about this chart can be found in the New Relic blog.

Final Thoughts

New Relic is an amazing service to monitor your web application. It is simple and powerful – all the numbers are presented in such a way that a quick glance to the chart enables one to tell a lot about the site’s performance. In this blog post we have reviewed the common problems that New Relic can help us to detect and provided several suggestions of how to fix them.

Also, it is probably worthwhile mentioning that while New Relic is very good at what it does, it is a service to monitor your application and it usually works best if combined with a separate system to monitor the server resources or the performance of each service you’re using – understanding how the whole application ecosystem behaves is essential in order to build a stable and well performing web service.

https://techportal.inviqa.com/2013/03/14/new-relic-for-php-web-application-performance-monitoring/

Over the years I’ve come to rely on information radiators during testing to get immediate (or as quick as possible) feedback from the systems I’m testing.

Firebug, log files, event logs and many other sources of information are all very useful to a tester. They can give you insights in to what is happening in the system under test.

We’ve just taken this a step further by rolling out NewRelic on our test servers.

NewRelic is what’s termed a “Application Management Solution”.

I’ve been talking about this internally as a system that can give us three distinct insights:

• User Experience Information
• Server Information
• Product Performance Information

I’ve probably over simplified the tool and doing an injustice but it allows me to clearly explain the value we’re seeing from it.

User Experience Information

NewRelic gives us all sorts of data around how the experience is for end users when they use our product.

We can use this to ascertain how our product is being experienced by our customers, but we can also use it to understand how the experience is stacking up for our testers.

If we are testing and we observe a slow down we can check whether it really was a product slow down using NewRelic and more importantly; what’s actually happening on the stack.

We can use NewRelic to work out what browsers are being used across all of our environments. We can see the test coverage we have across browsers and we can also see what browsers our own business use from our pre-production test environments (where we test all kits before live deploy).

We can also then see which browsers are faster than others. We can see which versions are used and which browser is our most heavily used. Interesting stuff to help guide and tune our testing.

Server Information

NewRelic monitors the actual servers giving all sorts of information such as memory, CPU, process usage etc etc. This is great information on our test servers, especially during perceived slow downs or during a load test.

We have other mechanisms for measuring this also so this is the least used function in NewRelic when testing.

Product Performance Information

For me, this is the greatest information tools like NewRelic offer; they show you what the product is actually doing.

It includes what pages are being dished, how fast are they being dished, where they may be slow (in the DOM? Network?), what queries are being run, what part of the code is running them and how often they are being called.

When we dig around in the data we can find traces that NewRelic stores which give an amazing level of detail about what the product is/was doing when the trace was run.

It’s going to become a testers best friend.

In a nutshell what it allows us to do is provide an accurate picture of what the product is doing when we are testing. This means we can now log supremely accurate defect reports including traces and metrics about the product at the moment any bugs were foud.

The programmers can also dig straight in to any errors and be given the exact code that is generating the error.

We can see which queries are running meaning that if we encounter an error, a slow down or something worth digging in to we have the details to hand.

It’s still early days using the tool but already we’ve had deep insight in to how the product runs in our environments which I’ve never been able to get from just one place.

It’s immediate also. Test – check NewRelic – move on.

Imagine how powerful this could be on your live systems too.

Imagine the richness of information you could retrieve and imagine how fast you could get to the root cause of any problems. It’s powerful stuff. Expect to hear further posts on how tools like this can inform tests, provide a depth of supporting information and provide help to performance testing.

Some notes:

• There are alternatives to NewRelic.
• It’s still early days but tools like this are proving invaluable for accurate and timely troubleshooting and information gathering.
• I’m not affiliated to NewRelic in any way – I’m just a fan.

Introduction

New Relic has become an industry standard for web applications performance measurement in Rails community. Simply adding and configuring newrelic_rpm gem for your Rails application gives you a great overview of its performance with an adequate level of details.
There are still a few improvements you can do to make use of some cool and extremely useful features of New Relic monitoring. They will help you to save time and efforts when fixing performance issues, scaling application, refactoring, etc.
So what should you do to make fast and effective use of New Relic?

Record your deploys

Always record deploys with your capistrano or chief scripts. This will save you time when looking for reasons for performance improvements or drawbacks.
A detailed information about recording deploys using capistrano can be found in official documentation. You can also use simple API deployment notification described here.
Either way it is important to add a clear description of deploy along with a tag or branch name.

Note that Pro users can also see ‘Change report’ for each deploy with a detailed overview of performance metrics changes (response time, throughput, apdex etc.).

Setup additional metrics before you start

It is important to setup some additional custom metrics right after configuring and enabling New Relic before you have experienced performance issues. You can read more about custom metrics collection here.
While you can add traces to almost any method in your code, they are commonly used for tracking important/critical parts of your code. We strongly recommend you to add traces for:

• application critical parts of code;
• external services communication (redis, RPCs, external APIs, DNS resolve etc.);
• encoding/decoding methods (some json encode methods implementations can be slow for large objects).

These traces are useful even within internal network. Drawbacks may be caused by network lags or hosting provider problems.

Here are some useful examples of custom traces that you can easily add to your initialisation pipeline (e.g. application.rb).

Resque

Resolv::DNS

Redis

Setting up additional metrics have two main goals:

• measuring performance of specific parts of code;
• when investigating slow requests with a lot of ‘Application code’ segments these additional traces can be used as benchmarks.

Additional metrics will give you more detailed view of what and when is going on in your application.

Note: New Relic gem implementation already has traces for Net::HTTP methods.
Caution: Don’t be zealous on adding custom metrics, clean obsolete ones.
Collecting too many metrics can impact the performance of your application. It is strongly recommended to keep the total number of custom metrics under 2000.

Setup Server Monitoring

To look beyond application itself New Relic has introduced Server Monitoring tool.
It is critically important to setup Server Monitoring for all servers in production and even staging hosting scheme. It will help you to measure your environment performance and state.

Note. New Relic is including Server Monitoring for free for every subscription level.
You can find all required information about installation and configuration of Server Monitoring tool here.

Setup custom views and dashboards

In most cases application performance strongly depends on application state and users activity. It is also helpful to see how your application performance correlates with business metrics, database activity, internal services state etc. New Relic gives you an opportunity to setup custom metrics, group and organise them with views and dashboards.
Common useful custom metrics you should define for your applications are:

• number of active users;
• users activity metrics;
• number of active application’s core entities (e.g. active tables for poker application);
• number of connections/calls for internal/external services (some have specific thresholds);
• database additional metrics.

Official documentation will help you to find more about creating and managing custom views and custom dashboards.

You can collect any custom metric and setup a specific custom view/dashboard in order to have general view on how they correlate.
Along with monitoring, custom dashboards and views also:

• helps you to understand the reason of performance changes;
• gives you a vision of future load changes depending on custom metrics;
• provides an ability to predict critical thresholds for load values (e.g. active users);
• helps you to improve application architecture by showing bottlenecks of internal infrastructure.

Note: The Custom Dashboards feature is available with New Relic Pro and higher.
It is useful to track only those custom metrics that have impact on overall application performance.

Setup background jobs/tasks monitoring

Always trace your background jobs performance. While in most cases they doesn’t directly impact on server response time they still can impact on user’s feedback and overall application performance.

Currently the Ruby agent supports only Delayed::Job and Resque.
Read more about monitoring Ruby background processes and daemons here. Make sure you have enabled and configured everything correctly.

Within one of our products we have employed an actor based architecture where actual action is executing asynchronously in a separate thread (we use JRuby). In such complex cases, it is useful to add traces for these actions and mark them as real web transactions (controller actions).

To complete such tasks or customise your add_method_tracer options please check API documentation.
For more detailed information about available options please read perform_action_with_newrelic_trace API documentation here. The most important options of tracer methods are:

• :category — defines action type (available options: [:controller, :task, :rack, :uri]);
• :name — action name (will be used as last part of metric name);
• :params — call context parameters;
• :class_name — first part of metric name. Default is a current class.

Here is a small example of custom background task implementation using JRuby thread actors.
ApplicationController:

Scheduler::WorkerActor:

So in this case all enqueued tasks and controller actions appear in ‘Web transactions’ together.

Summary

New Relic is a solid monitoring solution, especially for Rails developers.
Make sure you have enabled and configured all basic features described in this article.
And moreover — always learn your tools.

Explained by example

The best way to explain how New Relic can help, is by example.

A few weeks back, one of the magento based webstes I manage had some serious delays at checkout. After 'submit payment' was clicked, some users reported that the site could take up to 40 seconds (and in some instances just timed out) to respond back with the resulting page. Yikes! This was just unaccepatble.

After spending nearly 5 hours tracking this down (without New Relic), and not getting a clear view of the reasons, and not being able to replicate the issue, I signed up to New Relic, and hooked the site up.

And within an hour I had the reasons, and a fixed was placed on the site.

New Relic 'Key Transactions'

New Relic has this great new feature called ' Key Transactions'. This feature gives you the ability to mark any transaction as important, and it will appear in a new menu called 'Transactions'. This feature makes it a lot easier to monitor the transactions you are specifically interested in. In my case, I marked the checkout process (/onestepcheckout/index/index) as a Key Transaction.

Ok, so now I can monitor the actual checkout process specifically, and I am ready to collect information on what the hell is going on.

I placed a test order. And yep, I could not replicate the issue, all looked good, and I got the result page within a few seconds.

But all was not lost. All I had to do was wait for New Relic to collect details about every checkout, and I coud analyze the results.

It did not take long to finally find the reason behind the intermitted delay.

The trace from New Relic for a transaction that took more than 20 seconds to complete:

as easy as that, I now had the reason for the delay: Email mailing list subscriptions at checkout!

The reason I could not replicate this issue was because my user was already subscribed to the mailing list, thus, at checkout I would never got the 'subcribe to mailing list' checkbox.

Now that I knew what was going on, I could easily relicate the issue, implement a fix, and eliminate the delay at checkout.

Easy as.

The conclusion

Without the help of New Relic, it would have been near impossible task to track this issue down. New Relic not only saved me hours of frustration, but saved me hours of time, and allowed me to quickly, effectively target, and fix the problem at hand.

Simply put: New Relic is a developers best friend.

Valuable Features:

Room for Improvement:

Other Advice:

Valuable Features:

Room for Improvement:

Other Advice: