FusionReactor Relations Screen - "Additional XX not shown. Go to settings page to alter history size."

[Mathieu Cornille]

Hi all,

I have recently started to use FusionReactor in work and wondering if I am missing something. When looking at the details of a request and clicking on the Relations tab for requests involving a lot of calls , I get at the bottom of the list of relations a message saying "Additional XX not shown. Go to settings page to alter history size.". I have gone to the settings page and increased the settings as per below but still getting the message above even after a restart of a CF instance being monitored.

History Size: 1000
Slow Request History Size: 1000
Slow Request Threshold: 8
Sub Storage Strategy: First X
Per Type Sub Transaction Limit: 10000
Sub Transaction Limit: 10000

Is there a hardcoded maximum number of relations displayed or is that something I should be able to change from the UI?

Thanks,

Mat

[Charlie Arehart]

@Mat, while you await an answer from an engineer or someone else, I have a question that may help with this. I would think what you're doing is what you want to do to effect that change. So I wonder if you may be hitting a bug.

And to that point, can you confirm what version of FR 5 (specifically) you're using? You can do it from the FusionReactor>About menu in the top left corner (and do it for the FR instance where you're making this change, not the FRAM instance. They could be different versions.)

Also, I'd offer a thought: do be careful about raising those limits so high. The more stuff you tell FR to track, the more memory it needs, and it's running inside your app server, whether CF, Railo, or whatever. I do appreciate how useful it can be to see more info but consider that it should be showing already the slowest, you may not really need to see more than those. But if instead the problem is that you lose some type of relation (like uem or cfhttp) because too many others are there (like jdbc), I've raised that concern myself to the team. Maybe they could speak to that.

Hope that helps.

/charlie

--
You received this message because you are subscribed to the Google Groups "FusionReactor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fusionreacto...@googlegroups.com.
To post to this group, send email to fusion...@googlegroups.com.
Visit this group at http://groups.google.com/group/fusionreactor.
For more options, visit https://groups.google.com/d/optout.

[Mathieu Cornille]

@Charlie

Thank you very much for the reply! The instance in question is running Revision: 5.1.3, Build: fusionreactor.54.41891.branches/FR-5.x-MAINT. Can anybody advise as to whether this is a bug or I am doing something wrong?

Regarding your warning, yes, such high limits are a point in time thing, we are trying to debug some Slow Requests and we need to have all Relations showing underneath the requests in question to be able to properly investigate as opposed to getting only some of them.

Thanks,

Mat

[Charlie Arehart]

While we await that answer, I’m curious about what relations it would be interesting to see more of. Also, I gather that you’re also perhaps not interested not just in how many are “slow”, but how many of them there are at all, is that right? While JDBC relations can be logged, sadly the others are not, so I’ve seen that be a point of interest before.

But then you say that you’re trying to debug some slow requests, so unless there would be tens of thousands that were not slow, it would seem a surprise if lots of such non-jdbc “relations” would be the issue. Are you in fact finding that you have a slow request where most of the time is not in DB time (reported on the front page of the request details)? If so, there can be lots of explanations for that but I’ve rarely found them to be in “relations” myself (if not among the top few slowest). Just sharing some thoughts and trying to draw out more to help you resolve the specific problem, if perhaps there is some bug that’s not soon resolved.

/charlie

[Mathieu Cornille]

We are basically trying to step through the slow requests using the Relations screen to help us identify our issue. There are many different types of requests calling different CFC methods, which in turn make a number of SQL calls and in some cases HTTP calls, and as such it isn't easy to figure out which are the common subrequest(s) within the different types of slow requests that are taking more time than would be expected. We are hoping to be able to use the Relations screen to give us a starting point.

Does that make sense?

[Charlie Arehart]

Well, do you know for sure that there is slowness due to those things? Again if they’re not at the top of the relations then it would seem they are not slow.

If the issue is that you have some slow requests and can’t understand why they are slow (it’s not all DB time or some particularly slow “relation”), then I’d wonder: have you tried instead just doing a stack trace of the slow requests?

You may find that the slowness is due to something else. A stack trace would let you see, for any currently running slow request, what it’s doing at that point in time. And if you refresh it seconds later and it’s still doing that, then there would seem to be your smoking gun. And if you then looked at other currently slow requests, and stack traced them, they may show being hung up on the same thing.

Always worth a shot. I find that many don’t know about stack tracing (or misconstrue it from past experience looking at stack traces shown in CF error pages. Those are not really the same thing, in that those reflect what a request was doing when it terminated (which is rarely that useful), and which may not be at all the same thing it’s doing while it’s hung up running for an extended period of time, which often IS incredibly valuable.

I have resources on getting and interpreting stack traces here (my own and others, including a recorded session I did):

http://www.carehart.org/blog/client/index.cfm/2009/6/24/easier_thread_dumps

You can also hire intergral (makers of fr) or myself and others (cf411.com/cfconsult) to help with interpreting and using such stack traces, as well as solving server problems in general.

Hope that helps.

/charlie

 

From: fusion...@googlegroups.com [mailto:fusion...@googlegroups.com] On Behalf Of Mathieu Cornille
Sent: Tuesday, August 05, 2014 11:14 AM
To: fusion...@googlegroups.com
Subject: Re: [fusionreactor] FusionReactor Relations Screen - "Additional XX not shown. Go to settings page to alter history size."

 

We are basically trying to step through the slow requests using the Relations screen to help us identify our issue. There are many different types of requests calling different CFC methods, which in turn make a number of SQL calls and in some cases HTTP calls, and as such it isn't easy to figure out which are the common subrequest(s) within the different types of slow requests that are taking more time than would be expected. We are hoping to be able to use the Relations screen to give us a starting point.

Does that make sense?

 

[Jamie Jackson]

On Tuesday, August 5, 2014 at 11:48:00 AM UTC-4, charlie arehart wrote:

Well, do you know for sure that there is slowness due to those things? Again if they’re not at the top of the relations then it would seem they are not slow.

I've got the same question as Mathieu, and I'm confused about what you implied above: My relations are not in descending time order, as you implied (they seem to be randomly-ordered); therefore, it seems helpful to be able to capture them all. (As Mathieu mentioned, I can't seem to do that.)

[Jamie Jackson]

On Friday, May 22, 2015 at 3:13:01 PM UTC-4, Jamie Jackson wrote:

On Tuesday, August 5, 2014 at 11:48:00 AM UTC-4, charlie arehart wrote:

Well, do you know for sure that there is slowness due to those things? Again if they’re not at the top of the relations then it would seem they are not slow.

I've got the same question as Mathieu, and I'm confused about what you implied above: My relations are not in descending time order, as you implied (they seem to be randomly-ordered); therefore, it seems helpful to be able to capture them all. (As Mathieu mentioned, I can't seem to do that.)

(Minor correction, they are in ascending chronological order, which is understandable, but which still poses the same problems.) 

[Mathieu Cornille]

Hi Jamie,

If I remember correctly, you need to go to JDBC -  JDBC Settings, click on the History option and increase the Query Limit ('X') value from the default 30 to 300 (or whatever your max number of queries is) in order to have access to the full Query history.

Thanks,

Mathieu

[Charlie Arehart]

Sorry I missed this somehow last week. And wow, I see you’re replying to a thread from August of last year! :-)

Still, no, you’re right, the relations tab does not in fact list them in order (I do so wish they did). Don’t know why I said that. But you generally do see any slow relations in the list, FWIW.

 

/charlie

 

From: fusion...@googlegroups.com [mailto:fusion...@googlegroups.com] On Behalf Of Jamie Jackson
Sent: Friday, May 22, 2015 3:13 PM
To: fusion...@googlegroups.com
Subject: Re: [fusionreactor] FusionReactor Relations Screen - "Additional XX not shown. Go to settings page to alter history size."

 

On Tuesday, August 5, 2014 at 11:48:00 AM UTC-4, charlie arehart wrote:

[Jamie Jackson]

Thanks, Mathieu!

[Jamie Jackson]

On Wednesday, June 3, 2015 at 12:56:31 AM UTC-4, charlie arehart wrote:

Sorry I missed this somehow last week. And wow, I see you’re replying to a thread from August of last year! :-)

Yeah. So retro. ;-)

 

Still, no, you’re right, the relations tab does not in fact list them in order (I do so wish they did). Don’t know why I said that. But you generally do see any slow relations in the list, FWIW.

You were right where it was important, but I think the explanation should be clarified. Here's how it seems to be designed:

In JDBC > Settings > History, there's a "Query Storage Strategy" field, among whose options is "Slowest X" (the default, I guess, because I don't remember changing it), and then there's the field "Query Limit ('X')".

So, by default it seems that it really does show you only the slowest X queries, but those X queries are ordered chronologically by start time. Because it's only showing the slowest ones, I don't really need to bump up the query limit (for my needs). Nice job, FR. :-)