We are now able to quickly identify how our product behaves in production. Before New Relic APM, we would push a build, and try to dig through a plethora of information (event logs, error messages, customer feedback, etc) to find problem spots. Instead, we now publish and can see all the key stats (apdex, response time, error rate, etc.) and quickly drill into what’s causing an issue.
More configurability through the dashboard, for example, being able to ignore transactions without the need to update the config or code.
I've been using it for two years and alongside Insights for one year.
No issues encountered.
No issues encountered.
No issues encountered.
Really high. While we’ve never had any major issue, the ticket I’ve opened have received responses within a couple hours with quality answers.
We didn’t use any other solutions prior to this.
It was straightforward. On each of our servers, we installed the agent, added our key to a config, and then within minute we were seeing metrics on our site.
In-house. Always start with your development or QA environment. While we had no issues, it’s best to take a dry run, and get a feel for how the app affects performance to see if the data is what you’re looking for.
I have no hard numbers detailing how much we get back for what we pay. However, as a dev-ops tool, it has been priceless. We are now able to pinpoint issues much quicker and can significantly reduce our downtime.
We did evaluate one additional tool but the install and integration was significantly more cumbersome. The core reason we chose New Relic was the ease of us and the quality of the metrics it gave us. Within hours of demoing the product, we were already learning more about our application than we expected.
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.
The New Relic installation is split into several distinct components:
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.
“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.
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:
Depending on which of the application layers take the most time, different optimisation (or scaling) techniques can be applied.
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:
Accept-Encoding)?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).
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.
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:
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.
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:
“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.
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.
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.
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.
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/
Cool review