FusionReactor 8.7.7 released, enhances the recent DB and API Time feature
I had blogged in early November about how FusionReactor 8.7.4 had added at that time a new feature where it lists on request summary pages the DB and API Time of each request, so you could readily tell how much of a request's duration might have been caused by time spent waiting for either of those kinds of resources.
Now in 8.7.7, which was released last week (Mar 1), the benefit of that feature has been extended so that a) the same information is written to both the FusionReactor request logs and b) it's also now available in FR crash protection alert emails. In this post, I'll show you examples of what's changed for each, and I'll note another related changes in the prior FR update, 8.7.6.
I'd also love to see all this new DB and HTTP timings available on the "Main" tab for a transaction. All we have is "JDBC" ATM which is only part of the picture.
As for your second paragraph, those two colum s ARE indeed shown at the top of the page when viewing a request's details page (or the that for a transaction). It's not in the "main" tab, per se, but it seems adequate. Did you miss that, or do you disagree?
Finally, as for what the api time covers (your addition of micronaut, okhttp, etc.), I had in fact asked overnight for confirmation of that. I didn't want to hold up the post while awaiting the answer--which I'd in fact gotten before your comment here, but I'd just had not yet updated the post. I will now.
I'd also asked if it might ever include calls to soap web services (as cf offers with cfinvoke, cfobject, or createobject). That would expand things beyond "just http", to your point. But the answer was that it does not, for now. (As for why I didn't just test that myself, It was late last night as I was wrapping up and I was out of time. Again I didn't want to hold up the post for that rather minor point. I figured I'd have had time this morning to update it once I had the clarifications, which I'll do now.)
Yes, I've discussed with Mikey. It sounds like their reasons were mostly that people kept all telling them different things it should be called, so they went with whoever was yelling the loudest, lol. I still maintain "HTTP" time is the most appropriate name as it describes exactly what it is and makes no assumptions about the nature or higher-level semantics of the HTTP call.
> it seems adequate. Did you miss that, or do you disagree?
Yes, I saw them and yes I disagree :) Having them there is great, but it's still a half-implemented job. I LOVE the JDBC section on the "main" tab of a transaction as it has more detail than just the total (for starters, the NUMBER of JDBC calls can be a huge red flag). The "DB" time column includes JDBC AND MongoDB, Redis, Elastic, Cassandra so there's a lot more info than just JDBC that I'd love to be able to get that "high level view" of right there on the main tab before I dig into the other tabs. And the same for HTTP-- how many HTTP requests? What type? Average time? There's a lot of missing high level stats that I think deserve to be featured on that main tab. The two columns are great (other than the poor naming) but they're just the tip of the iceberg.
> your addition of micronaut, okhttp, etc.
Yep, my list came from my discussions with Mikey this morning.
> include calls to soap web services
SOAP web service calls, are still just HTTP requests. The fact that the high level semantics of the message request body and response body follow a SOAP (or even an XML-RPC) spec doesn't change that it's still just an HTTP call. Now, I don't mind if they provide a breakdown of the different types of HTTP calls, if it's even possible for FR to differentiate, but I would expect SOAP calls to be included in the "HTTP" column since that what they are.
And indeed, since http counts and details are in the relations tab, it does seem rather a nit that the count's not on the main tab also, but ok.
And as for web service calls being just another form of http, OK sure. My point was to let folks know that those are NOT currently tracked in the new api column, though it seems they should be.
Maybe they will hear you/us.