It’s time for something new

After 14 years we’re hanging up our keyboards. Our team is joining the lovely people at Culture Amp, where we’ll be helping build a better world of work.

Icelab

New Relic, Heroku and Rails Streaming Responses

By Tim Riley20 Jan 2012

For Ticketscout’s payment processing, we use a custom Rails action with an HTTP streaming response. It shows the user a spinner and a “please wait” message, then periodically sends empty strings to the browser until the credit card transaction is completed. This streaming response keeps the request connection alive longer than the 30 second timeout period that is the default on the Heroku Cedar stack. The technique works well and ensures we don’t ever lose track of any slow-to-process credit card payments.

During development, we found that the streaming responses on Heroku did not work if we had the New Relic add-on enabled. Instead of seeing the page content incrementally delivered while the request ran, we’d see nothing until the request completed, then all the content delivered at once.

To deliver the feature on time, we simply disabled the add-on and released. Everything worked smoothly, but it was unnerving to run the app “blind” without New Relic’s useful metrics. This became especially problematic now that we’re wanting to pay some more attention to improving the app’s performance. I finally contacted New Relic support, and it turns out that a working solution is fairly simple: disabling the real user monitoring.

Turns out that the real user monitoring is currently incompatible with streaming responses. I disabled the automatic instrumentation in my newrelic.yml config file:

browser_monitoring:
  auto_instrument: false

I also switched off the “Enable end user monitoring” setting in the “Settings > Application” page. Then, after fresh deploy to Heroku, I re-enabled the add-on and we had both the metrics collection and streaming responses working together!

Granted, we’ve lost access to some useful real user metrics (like network load, page rendering and DOM processing times), but it’s better to have some metrics than none at all!

Down the track, we can probably get the best of both world’s by manually enabling the real user monitoring instrumentation in all the pages layouts except those used for the streaming responses. Hopefully further down the track, the automatic instrumentation will be compatible with streaming responses out of the box. In the meantime, it’s good to have our charts back!