3 ms·
> every transaction/request taking place. It's definitely gotten better, however I think the default view is still just averaging all requests, which isn't ver
by grandalf 11y ago
> every transaction/request taking place.
It's definitely gotten better, however I think the default view is still just averaging all requests, which isn't very helpful.
For a blocking server (like most Rails apps use) the key insight has to do with which controller actions need to be optimized to prevent slow user-facing aggregate response times.
I don't currently have it in use on any of my apps, but next time I'll give that query a try.
- Lightbody 11y agoYes, the first graph is for the entire app. But we (try to) make it easy to quickly drop down to a view that shows you the most time consuming controllers and then let you quickly see performance for just a single one. Feel free to drop me an email at lightbody@newrelic.com if you decide to check it out again and have more feedback. Take care!
- grandalf 11y agoI appreciate the response here, and appreciate the offer.
- joshwa 11y agoThis is a problem with other APM tools, too... someone inevitably wants to know in one number how the system is responding, and the best you can do naively is to average all of them. Defining critical transactions, and measuring them against their SLAs is really the only valid way of summarizing total application performance (x% of traffic is meeting SLA, y% is 1 stddev above, z% 2 stddev, etc).