[Sujan]

Especially the remarks about the costs and alleged fails of NewRelic seem totally wrong to me.

As a very happy NewRelic customer, I can say they did exactly what they advertise: Help monitor the application performance in the server (!). The queueing that now seems to be a problem of Heroku doesn't happen in the server that is processing the request, so by default it can't show the time needed.

Actually I'm quite sure that using one part of NewRelic, RUM (real user monitoring), should have shown the problem quite obviously. It shows how long a user had to wait for the request complete, including DNS lookup and network time. So if users waited longer for answers to their requests than the backend time should indicate, every developer should have taken this as a hint to investigate further.

Well, even using the application should have been enough to know that something is wrong when NR reports 250ms backend time, but page need at least 1200ms to return first byte to the customer.

[makomk]

Errrm, unless I'm entirely mistaken the problem is that the queueing does happen in the server that's processing the request, and New Relic just doesn't report it.

[Sujan]

Well, as I understood it the queueing happens in some kind of load balancer that is responsible for routing the requests between different servers ("dynos" in Heroku speak) to handle the requests. New Relic is a plugin for your server and hooks into Apache and PHP (or this case Rails) to learn how long it takes to process the requests (and retrieve data from the database and/or a cache). This means, to me, that queueing strictly is out of the scope of what NewRelic normally does.

However it's great that they and Heroku now found a way to report the correct queueing time. As far as I understood it, they use a special header added by Heroku to calculate the time themselves and report it in their dashboard.