To find bottlenecks and to help with debugging and monitoring

How do you know what parts of the workflow need improvement? Measure it. With New Relic in place, we have graphs of our API performance and can directly see if a server or zone is causing trouble, and the impact of our changes. There’s no comparison between a real-time performance graph and “Strange, the site seems slow, I should tail the logs”.

Monitoring and Tracking slow pages in our app

Server and application performance monitoring, alerting, and page/background task tuning.

I use this to track the app performance.

Tracking

Monitoring Buildtime Trend as a Service on Heroku

Performance monitoring.

어플리케이션 서버 및 각종 서버들을 모니터링하는데 이만한 툴이 없습니다. 어플리케이션 서버의 퍼포먼스 드릴다운 모니터링이나 각 서버들의 활성화 상태를 모니터링 하는 용도로 사용합니다.

Free Heroku add-on. Not particularly useful for us. Rails profilers tend to do a better job at the app level. And I can never really figure out what’s going on with Heroku by looking at New Relic. I don’t know if we’re just not using New Relic correctly or if it really does just suck for our use case. But I guess some insight is better than none.

We use New Relic to make sure that our servers are running efficiently.

We can see performance analysis of the layers of the application.

Monitoring of applications

Continuous performance monitoring

We monitor and troubleshoot our app's performance using New Relic, which gives us a great view into each type of request that hits our servers. It also gives us a nice weekly summary of error rates and response times so that we know how well we've done in the past week.

2 years of experience using New Relic for application optimization.

Performance monitoring

To track server health and monitor all stats.

Monitoring via Open Shift integration

Monitoring our code

To monitor server availability and resources usage

Monitoring bare metal servers

We use NewRelic for monitoring our APIs, it's free with Windows Azure which is super!

I'm trying to wring more instrumentation out of New Relic as it pertains to Rack, but for the time being, New Relic is monitoring/alerting uptime and some basic performance metrics.

Tells me when something explodes

We hooked New Relic up to monitor the health or our servers and containers, as well as track the actual app performance.

Stack monitoring

Infrastructure monitoring

New Relic is used both to monitor availability and to find potential candidates for optimization.

Server logging and monitoring.

Free version is good enough

For performance monitoring and tracking deployments

New Relic is awesome for monitoring app performance and status.

basic

used it minimally at talenthouse and for a couple clients.

Server monitoring for a number of backend projects I have worked on.

Just like we care about errors, we care about metrics - especially around performance. You'd be crazy not to use it - and not surprisingly, it's a one-click add-on in Heroku.

Expensive but it gets stuff done

Mobile, Web, and Middleware performance management.

Server and app-level monitoring.

Performance and bug analysis on production environment.

Monitoring and metrics for Coolfront Mobile.

When we were facing performance issues with the new StackShare app. We originally thought it was a server issue. So we did quite a bit of research to see how many dynos we should be using for the sort of application we have and traffic profile. We couldn’t find anything useful online so I ended up asking my buddy Alain over at BlockScore. After a quick convo with him, I knew we should be totally fine with just 2 dynos.

We also tested the theory by increasing the number of dynos and running the load tests. They had little to no effect on error rate, so this also confirmed that it wasn’t a server issue.

So that meant it was an application issue. New Relic wasn’t any help. I spoke with another friend who suggested we use a profiler. We totally should have been using one all along. We added mini-profiler, which was great for identifying slow queries and overall page load times. We also had the Rails Chrome extension so we could see how long view rendering was taking. So we cleaned up the slowest queries.

We tried to use mini-profiler in production on the new StackShare app and for some reason, we couldn’t get it to work. We were in a time crunch so I asked Alain what they used and he said that they use Skylight in production. Funny enough, I remembered the name Skylight because we listed it on the site a while back. So we did that, and at first we couldn’t really see how it was useful. Then we realized what we were seeing were a ton of repeat queries on some of the pages we load tested.

Skylight is cool because it sort of gives you the full MVC profile. We were able to pinpoint specific db queries that being repeated. So we cleaned those up pretty quickly. But then we noticed the views were taking up all the load time, so we start implementing caching more aggressively. After we cleaned up the db queries and added more caching, our pages went from this: to this:

Skylight ended up being super useful. We use it in production now.

An essential for determining production performance. It provides us with clear insights into what might be slowing down responses so we know exactly what to fix.

We are a very small non profit with a very simple server setup. Our two developers do not have any special training as sys admins. That said, it was very simple to get setup with Scout and start some simple monitoring of our servers. Most of what we do is check that some key processes are running and that our URLs are up. But we're interested in learning more aboutS Scout's capabilities/ doing more sophisticated server monitoring down the line.