I've found the most valuable feature to be--
- Being able to drill down to see data, and
- Being able to capture all the timing information and different functions.
I've found the most valuable feature to be--
It comes in as part of the regular process for every application roll-out. We have a standard visibility process for any application that rolls out. It gives us the ability to train our people and provide a more responsive application. We used to have many tools with many different functions, and now APM allows us to consolidate a lot of it.
The mapping between applications to servers is not very intuitive.
Another thing we come across is that our technology just doesn’t have reporting to New Relic, but that can be addressed with a plugin/SDK. However, we can’t really make the case to put in the investment to have that happen yet.
Another thing is that we’re micro-service based, and the New Relic interface only gives us views into the top 100 services out of 50,000. Typically when we monitor our system, we use a heat map, and New Relic only provides us the second-level view of that. Ideally, it would also provide us the first-level view. Eventually, we’d like New Relic to step up to do that.
Finally, it should ideally do two things -
Sometimes when we pull data from New Relic, we time-out or drop data, and we can see when that happens, but we're not sure if it’s us or them.
Also, the alerting system has trouble with large alerts that come up slowly, requiring the operator to know the system well (yellow, red, orange) and to know what the alerts mean.
It hasn’t scaled quite right now. We use another tool for out-of-gate view. Currently, we manage about 60,000 servers in total and we don’t have a good roll-up view of the entire system. The application on the server side is OK. We use other tools to monitor the environment.
So far, the interactions have been good, and they keep us in the loop as to what’s been done. In terms of the solution, it’s just OK.
I wasn't involved in the setup.
Engage the development community within the company early, and request an integration tool to make implementation easy.
The way some transactions are recorded, you can dig through and see what’s going on with the request, how many times you’re making a certain call. That’s the biggest part – almost like application profiling.
We get greater insight into what our application is doing once it’s in production. We can identify issues faster, and being able to identify issues before they become a big problems is an improvement. We use it in load testing to identify inefficient query patterns.
At times some of the data can be opaque. Some of the aggregates over time tend to become more vague, so you lose resolution. Greater resolution going further back in time would be nice. If I start going back a month or two, the resolution is a lot lower, which is kind of challenging and makes it harder to do in-depth historical analysis.
Alongside APM, we're using New Relic servers, plugins, and pretty much everything else except Insights, Synthetics, or the mobile product.
Pretty stable. Sometimes the charts will fail to load or there are some random errors. But because of the way we use APM, there’s no significant impact.
Our use doesn’t really push the limits of New Relic, but it looks like it will scale just fine.
It was already in production when I joined the company.
I don’t see us being able to operate without New Relic. It’s important to collect a lot of metrics, but it’s more important to identify the ones that are essential to your business purposes. Know which data are really important and what you should keep an eye on.
It helps you to define the transaction percentages, average time, and highest throughput. Also, it tells us the transactions that take the most time on average. Those are the high level, most useful features.
It also tells us about every single request that comes in and how the system reacts to it. You get to see everything from the dashboard, all these breakdowns per layer of your architecture.
Error rate is the second most useful feature – there are alerts tied to that. You get paged when the error rate is above an expected percentage and that has worked very consistently and reliably for us.
The best thing is that the team has grown, and a lot of people are developing the code, but you tend to have regressions that are clearly visible in those transaction traces.
When there’s a deployment, it shows by graphing if a regression has happened, and it allows us to react. Catching regressions in performance is very important, and since we now see the breakdown in every single layer in the application, you know right away if there’s something you’re not expecting. We can then go and figure out if it’s an infrastructure or code issue. It gives you a high level view of all of the requests coming in. Error rates are a good indicator for potential rollbacks for a potential deployment – and usually it’s pretty instantaneous. At the end of the day as users, we get what we want.
For the purposes for which we’re using it, it just works. So far I don’t have any requests for new features.
Currently, it is not the only solution we have for monitoring so there are things that it’s missing – for example what Datadog does for us. Timeline series, custom timelines and graphs, and I’m not aware of those features in New Relic.
Every now and then there are little quirks, like the web site will stop refreshing by itself, or the graphs will show something that’s not happening. But in my experience just refreshing the graphs will fix it. But we’ve never had any downtime with New Relic.
We have scaled up as well in terms of number of hosts. There is some perceivable difference in performance when you’re looking at a graph versus number of hosts, but so far it has been fine. It’s definitely not the same looking at a single host versus many hosts.
The fact that I’ve never had to contact support by email or phone is a good thing. The online documentation has been fantastic. Everything you want is available in the documentation.
It was already in production. I did deployments in the staging environment, but not the first deployment. We will be doing the first deployment for mobile as well.
It was already in production. I did deployments in the staging environment, but not the first deployment. We will be doing the first deployment for mobile as well.
You need to understand what’s in their stack, what technologies, what libraries, and it takes someone who has experience with those technologies to help make the decision. It also comes down to best bang for your buck, and I’d definitely recommend New Relic APM.
My organization follows SOA architecture to address the overall complexity. We have broken our system into different services according to complexity and functionality. When we serve a customer, multiple services come into picture. To identify the exact time taken by a service or failure in a service, we had two options:
a) Go through the logs and identify the exact issue or time taken by the component (too complex and takes a considerable amount of time).
b) Install an application monitoring system that can measure the performance of different services from the customer themselves and, in the case of issues, identify the issue and/or alert (less time required to diagnose the actual issue with visual representation).
The second option is much better in all scenarios.
The installation for New Relic is butter smooth and hardly took 5 minutes for the first server. It even reduced to less than 2 minutes for additional servers.
We found the following benefits after installing New Relic:
a) Ability to pin-point the exact module/service creating issues.
b) Lightening fast issue identification since there is no need to go through gigabytes of log files and, since we have a number of servers in our cluster, it isn't even feasible to check each and every server.
c) Access to web page load-time, size, and error tracking, vital for a e-commerce.
It would have been great had it provided thread-dump analysis and a few additional JVM-related stats. For reference, we can check JVisualVM.
We have used this solution for over 3+ Year. We put this system in 2012 and it is still up and running perfectly fine.
There were no issues encountered at all.
We didn't encounter issues with stability.
There were no issues with scalability.
They were pretty helpful and quick in addressing our concerns.
Technical Support:10 on a scale of 10.
We did not use any other solution.
It was very simple and took minimal effort and time.
New Relic only comes in SaaS flavor and installation is pretty quick. We used our in-house team for implementation.
From the perspective of effort and time taken while identifying issues and resolution, we have gained a lot. Not sure about the financial ROI.
It totally depends on the organization's requirements and the effort vs. return one puts in monitoring the system. Although, it would have been great if the licensing cost could be reduced a bit.
Yes. We evaluated AppDynamics.
Go ahead if you can afford it. You won't regret the decision.
We are using the SLA reporting, server monitoring and alerting, however the main and most important feature for Mangocam is the real time application performance and capacity reporting. We are also using plugins for memcached and database monitoring and alerting.
New Relic has changed the way we are dealing with application problems. It's the first place for our administrators to check if we encounter issues. In most cases, New Relic can immediately pinpoint the root cause of the issue, be it application errors, slow transactions, external services, database throughput or high transaction count. New Relic can monitor thresholds and alert if required. We are also using New Relic to help understand performance tests and bottlenecks.
Some of the 3rd party plugins could be improved - especially the requirement for java to monitor simple network services is not ideal. Also the pricing / plans may need restructuring as there is a big gap between the free offering and the first paid tier.
About three years for Mangocam.com, also at two other companies as IT consultant for the last 4 years.
We have used the PHP and Java monitoring modules as well as the server monitoring service without many problems. There was an initial glitch with the javascript injection on parts of our site, which has been sorted out quickly with the help of the New Relic support.
None so far. The service is very mature and very stable.
None so far. However, the amount of servers and services connected is limited.
We only had to contact the support twice and in both cases the response time and professionalism were exceptional.
Technical Support:The quality and expertise of the email support was very high, we have no complaints.
We have tried different services in the past, which only offered part of the features, but again New Relic is very different - complete product that just works.
Setting up New Relic is very easy and well documented. It's using the standard operating system packaging tools and is straightforward.
We implemented it in-house.
There is no measurable ROI as we are currently utilising the free plan / option.
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/
I’ve used new relic with my rails apps for over a year now and like the service a lot. I recently noticed that they have integration with php so I decided to get the php agent configured on my server so I could get stats on an upcoming symfony 2 app.
I use Nginx / PHP-fpm to run my php apps on ubuntu. The install instructions on the new relic site worked pretty well except for one minor quirk.
I had to install php5-dev so that the new relic install script had php-config to execute to find out information about my install. After that, the install script kept complaining that it could not find a valid php install on the system.
With this particular setup, new relic would look for php in /usr/bin/php (from the php-config script) but that did not exist. There was /usr/bin/php5-fpm and /usr/bin/php5-cgi.
I created a symlink for /usr/bin/php and reran the install script.
Success!
The APM Transaction monitoring is the most valuable feature. Being able to define key transactions and collect traces has been essential to providing actionable data for fixes and improvements.
Early in our app lifecycle we would receive random reports of slow response times from users. Of course, they were never reproducible in our QA environments nor did our OS-specific monitoring tools show any problems. Implementing the APM with our app servers gave us visibility into what our Java code and JVMs were doing at the time users had problems. This allowed us to zero in on infrastructure and code issues as well as implement monitoring cases specific to our app.
Last year, there were several New Relic outages where alerts were either fired in error or not fired at all. These have been remedied over the last year, but it negatively impacted our trust in using New Relic as our sole source of analysis and alerting.
As far as suggested improvements, the Synthetics module could be much more useful if one did not have to learn yet another analytics query language.
I have used New Relic in production since mid-2013.
Since we use a 1.x version of Play Framework, there were some initial challenges in implementing the Java APM agent. The later versions of the agent have drastically improved since then and deployments are considerably less cumbersome.
The aforementioned outages and issues were vexing but, fortunately, are well in the past.
No issues encountered.
Generally excellent.
Technical Support:Generally excellent.
New Relic was an add-on to our existing operations analytics systems. We selected New Relic solely on the basis of the application monitoring feature which our existing systems did not provide.
Once we overcame the challenges of implementing the early Java agent, the remainder of the implementation was effortless. We had 90% functionality within the first 12 hours of implementation.
I performed the implementation personally.
At our usage level, the cost has been trivial compared to our overall operations monthly costs. What the product has done for us was expedite our ability to discover actionable data that led directly to improvements in our app which would have taken considerable longer if we'd had to build similar functionality ourselves.
Whilst it may be tempting to instrument all of your production and non-production environments, this is a tool that is best used where appropriate, rather than as a blanket deployment.
We evaluated building similar functionality ourselves using open source JVM monitoring and log analysis tools. We also evaluated a few semi-competitors. The home-brewed solution would have required additional engineering staff and a much longer build time. The also-ran services were astronomically more expensive.
It's a great tool for monitoring infrastructure and application performance. The only drawbacks have been cost and a few issues with outages and monitoring/alerting failures.