Sky-high web app performance gauge reaches into browsers New Relic has long offered an online service for gauging the performance of web applications on the back-end. And now, its eponymous service can monitor your application on the front-end as well. On Tuesday, the San Francisco-based outfit announced that the service now includes "real user monitoring", using JavaScript to gauge …
but they have two big disadvantages to my mind
* Not integrated into one slick User Interface.
This is the huge one for me, if you haven't used the RPM interface then it may not be obvious but a smooth UI makes things so much easier.
* Not SaaS
In this case is quite important I think because I do not want to spend my time maintaining servers not directly used by my primary applications plus all the overhead of DBs, storage etc.
Having said that I would be interested to know exactly what free in-the-repo applications you think are comparable to New Relic, maybe I will learn some new ones.
"Not integrated into one slick User Interface."
Complex UIs around simple tools often make one less productive not more. Using find and grep is a damn sight better than using a search GUI: it's faster, more flexible, considerably more portable, and unlikely to change with the next major update to my OS.
"In this case is quite important I think because I do not want to spend my time maintaining servers not directly used by my primary applications"
You have a dev server, right?
"plus all the overhead of DBs, storage etc."
You test your apps before they go live, right? You should already have your own profiling data. Or do you out-source that too?
"Having said that I would be interested to know exactly what free in-the-repo applications you think are comparable to New Relic"
There's a bunch of lightweight profiling and benchmark tools in the repos. I try to use these rather than investing in an entire new application suite. It's the Unix way.
>Complex UIs around simple tools often make one less productive not more.
I said "Slick" UI, not "Complicated" UI. You can see all the following within about 4 clicks on the interface
* Database status (IOPS, RAM, locks etc.)
* CPU / RAM on your app / web-servers
* Request throughput and request processing time for your web application broken down by host if need be.
* Memcache status.
* Details information regarding which methods were called for each request and how long each method executed by that request lasted.
* Response time from the user's perspective.
* Background task processing.
All in near real-time.
Of course, because the information is archived you can see all this in a historical context in a nicely presented manner. You said GUIs "Often" reduce productivity and I agree, but in this case you are wrong in my opninon.
How many log files / separate apps do you need to access to get that clear a picture?
> You have a dev server, right?
Yes, a dev server I do not want to gunk up with some app + DB etc. for monitoring a part the live site.
>You test your apps before they go live, right? You should already have your own profiling data. Or do you out-source that too?
What has that got to do with anything I said? This is about monitoring / diagnosing live sites.
I have to wonder if you have you actually used it? It sounds like you have already written it off because when you heard it was web app with a *Gasp* GUI and "grep / awk / sed are good enough damnit, get off my lawn."
Logs are useful for diagnosing problems after the fact (Although NewRelic does make things easier too), not for real-time monitoring.
The interface. I don't want to waste time poking around in interfaces that change at the service providers whim.
The feature list. How many of those are available on non-compatible frameworks? Because I'm not using a compatible framework. My stack already has tools for measuring and monitoring all of those. I managed to get it together enough to write some code to tie the data together.
The injected javascript. No. For so many reasons. Not least because I'm not outsourcing this stuff to the customer.
The data. Oh I have a GUI on my data. By which I mean an HTML table. Configured how I want it. Want a new perspective? I can add it in less time than it takes for you to fire off a feature request.
The diagnosis. You've identified a bottleneck. Written a fix. Are you going to intensively profile in dev first, or patch the live system and then profile?
The dev server. Use as per above. Don't add extra resource requirements to every single production server.
The logs. Yes. What was your point? Except that you haven't heard of tail and similar.
The accusation. Well you turned a snarky, one-line, throwaway post on El Reg into an argument. I am allowed to have opinions on things I haven't used. I am allowed to have reasons for not doing things. Ever sat on your own fist?
I build web apps for a living. Why would I hate them!?
I usually post anonymous, force of habit.
You mentioned the list of monitoring apps but when I asked for a few examples you didn't give an answer apart from "Oh, there are loads of them".
I know there are loads of them, I know most of them can be scripted up and modified, If you want you could even write some scripts to pull it all together into one system.
I do not believe you can do all the above to the same level of quality without lots of faffing about. In your case you didn't mind the time expenditure, in my case I do mind. Give me a well integrated setup anyday...ok, usually.
Javascript: Again each to their own on that one, compared to the plethora of other JS stuff on the modern web ta few pings is small potatoes in my mind.
The GUI: This goes back to the time / faffing around aspect but I highly doubt you could match their current GUI functionality without a very significant time investment.
I was going to list each point but again I keep coming back to the thought. How can you make a decent comparison without having experienced it from both sides?
We have used various unix tools (including tail!, sorry for not listing every possiblity under the sun), various open source apps (Nagios + plugins etc.) and we have also used this site (and scoutapp for other ones).
From our perspective this beats the previous setup hands down, and this is coming from a bunch who HAVE done both which was why I replied to your original post in the first place.
"I usually post anonymous, force of habit."
Why?
"You mentioned the list of monitoring apps but when I asked for a few examples you didn't give an answer apart from 'Oh, there are loads of them'."
No. You asked for apps that were comparable to New Relic. Why bother with a new app, when everything you need is already installed? You want to waste time on learning and relearning new apps / services.
I want to spend time refining what what I already have. My strategy keeps the code in house, and company-owned. So ... the monitoring app becomes a potential product / service and revenue stream ...
"We have used various unix tools (including tail!, sorry for not listing every possiblity under the sun)"
Tail allows you to monitor logs in realtime. So you can put the sarcasm back in its box.
"This goes back to the time / faffing around aspect but I highly doubt you could match their current GUI functionality without a very significant time investment."
But 99% of that time has already been invested on in-house libraries. I'm just reusing what is already there, instead of investing time in yet another product.
"Javascript: Again each to their own on that one, compared to the plethora of other JS stuff on the modern web ta few pings is small potatoes in my mind."
That sort of attitude is what's killing the client side. A few pings turns into ten second page loads when all the js, css, images, flash and fuck knows what are taken into account. I like my web fast. So do my clients. So do their customers.
"I was going to list each point but again I keep coming back to the thought. How can you make a decent comparison without having experienced it from both sides?"
New Relic does not support my framework. Decent comparison made.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
