Introducing Unified Transaction Types

The separate pages for web transactions and all other transactions (background tasks) have been consolidated into a single page to provide a consistent experience, no matter the type of transaction.

Read all about the new page on our blog, and give us your feedback here!

6 Likes

This topic is now pinned. It will appear at the top of its category until it is either unpinned by a moderator, or the Clear Pin button is pressed.

It’s a good step, but we are still running a separate Heroku App for our workers. We want to see the memory information on the Instances tab independently for requests and other transactions.

Hopefully improvements to the Instance tab are coming soon? :smile:

Glad to hear it is a good step! We plan to keep making these kinds of improvements and I expect the Instance tab will be a part of the ongoing improvements.

Thank you for sharing your thoughts!

How could we opt out of this? We don’t want to see background jobs in the final apdex score. We do our heavy-lifting, non-OLTP in delayed jobs and we know that they take a long time to run. But now they are skewing our important metrics and giving a false perception of bad performance to the user.

If you are finding that you don’t like seeing all the transactions mixed together, you can filter by type and choose just “Requests” (ex: Web Requests) to block out the delayed jobs. Does that work for you?

I apologize for not directly addressing this point in my last message. Although we unified the data in to a single view, we continue to only report on Apdex for web transactions. That means you shouldn’t see any changes. Are you, or was that just a concern of yours?

We do have plans to eventually allow background jobs to have an Apdex score, but it’s down the road and when we do it’ll be opt-in on a per-transaction basis.

1 Like

That addresses our concern. Thanks.

Fine to have the requests together,
however the choosen naming is simply plain wrong.

As you’ve rightly stated in the Blog-Post
“Requests” and “Other transactions”
refer to
“web-based” and “non-web” activity.

So you’s better name them:
“Web-Requests” and
“NonWeb-Requests”

instead of illnamed:
“Requests” - Which ones ?
and
“Other - *” - Which ones ?

Sometimes it’s that simple as that (just read what you’ve written)
to get over semantics and semantic discussions.

hth regards Georg

Hi Georg,

Thank you very much for your thoughts! We spent an incredible amount of time going over these names internally.

We seriously considered the idea of “Web Requests” and “Non-Web Requests” because it is very descriptive of the distinction between the two classes of activity. However, we decided against it because “Non-Web Requests” doesn’t seem to make for a good label in the UI.

This is very helpful feedback and I will let the team know.

Thanks again,
Greg

Ahoi Greg,
Thanks for your timely response. I got your point regarding “non-web-requests”; no question here anymore.

However I fail to understand why your’re labelling “Web-Requests” plainly as “Requests”.
As mentioned in the Blogpost & SO right, they ARE “Web-Requests” and not some “Requests” from any undefined client/source (as far as I understand).
Any chance to get that label rightly named?

Thanks, kind regards Georg

Hi Georg,

Thanks to your (and other customer) feedback our design team is actively working on some label changes. There is a good chance we’ll have a different label coming soon.

Thank again,
Greg

I have to say I’ve never quite understood the right way to use new relic on a worker, i.e. an a process where there are no web requests. For example, we have a number of node.js apps that either listen on an amqp queue and do parcels of work based on the incoming messages, or poll a a database for available work. How do you tell new relic what constitutes a ‘transaction’ in this case…? I just concluded that New Relic was really not geared up for this use case but now I’m not so sure…
Thanks
Tim

Great question. In general you can monitor non-web work with New Relic and it is great to see that this UI change made that more obvious.

For Node, I don’t believe there is a way to create or name transactions outside of an HTTP context yet, but I’ll double-check with someone more knowledgeable with Node and get back to you tomorrow.

Some of the agents instrument non-web work out of the box. For example, the Java agent will identify transactions based on taking messages off of a queue through JMS.

In Java you can use the Trace annotation for identifying your own transactions.

In PHP call newrelic_start_transaction to start a transaction.

For Node there isn’t a way to create a transaction outside of an HTTP context yet, so there would need to be built-in instrumentation for the amqp or database polling work provisioning at the moment.

Thanks for clarifying!

Hey Tim,

We’ve just released Custom Instrumentation for our Node.js agent which will allow you to define custom transactions, segments and background (ie: non-web) transactions.

I suspect this could/should address your ampq use case at some level; we are also considering specific instrumentation for ampq, but there hasn’t been a ton of interest in that yet.

Here’s some initial documentation on Custom Instrumentation that should help get you started:

Node.js Custom Instrumentation