like to understand what, if any, performance or capacity concerns exist in cases where a BT is expected to have a large number
of splitting, but where “Store results in Performance Warehouse” in NOT
checked. All of the forum entries that I have read related to excessive
splittings refer to issues with filling up the PWD. Since it appears possible
to configure Incident Rules on BT splitting measures even in cases where the
splittings are not stored in the PWD, it seems obvious that the splitting
measures must be available in memory for Dynatrace to evaluate them. To
summarize, my main questions are:
Since you are not storing splitting in the PW, the only constraint that i can see happening is the amount of purepath data you retain based on you Live recording session size. Remember that all purepaths are retained for sometime in that live recording session (this is dependent on how much hard drive space you have allocated for this) and then measures are stored in the PW, so depending on the size of that live session will dictate how far back you can split (since no other data will be stored in the PW for that bt). to check session size for a system profile, right click the profile and view details. Hope this helps.
Thanks for your reply Nathan. If I follow correctly, what you are saying implies that the splitting measures are not being constantly calculated by DT and stored in memory... i.e., they are only calculated in response to somebody performing an interaction with the Dynatrace client that results in the PPs in the active session being processed to calculate the splittings. Is that in fact correct? If so then I'm puzzled why you can select splitting measures that are configured to not store in the PWD when defining Incident Rules.
Yes, in my experience incidents will not work if they are based on incidents work if they are based on measures not stored in the PW. Really it probably should notify you or prevent you from adding them in incidents.
I had gone through with the document and found some relevant information asked by you, perhaps, can be helpful to understand the concept about splittings and the cons to not storing the business translation in the PWH in a glance or might be you already aware about the following:
When a Business Transaction is disabled:
All other diagnostic dashboards operate as normal, without any limitations.
What remains very unclear to be is:
1. In the case where the splitting measures are configured to not store in the PWD, what is the expected memory usage? The previous answer to my question seemed to suggest that the measures would only be calculated when a user examined the PP data via the client... but since we seem to be able to define alerts on these measures there must, I presume be an ongoing calculation of the splittings... and if that is the case then would they only be calculated for whatever the evaluation period of the Incident Rule is, or would the splittings grow in memory until the default 50,000 limit is reached?
2. If the 50,000 limit is reached how would the system ever start calculating them again. I know that there is a reset capability in the DT client for splittings, but I was told that this only applies when results are stored in the PWD DB.
Memory usage would be entirely dependent on the number of splittings and volume, I am not sure this could ever reasonably be calculated but i've never seen where a BT has had so many splittings that it ate up all the memory and caused issues. If that were to occur then adjusting the server sizing (increasing memory) would be the work around for this and you would see your memory consumption being high in the built in dashboards for monitoring the health of the DT server.
Jeff, be careful with incidents based on non stored measures as James mentioned, sometimes they do not function as intended.
Splittings will be in memory for only one hour, if your number of splittings does not exceed 50,000 in that hour you will not have your BT disabled due to measure explosion. If the number of unique splittings are 33,000 at 8am, 9am, and 10am then you will not exceed the 55,000 limit as the previous ones would have fallen out of memory before even though the total unique splittings would be 99,000 over that three hour time period.
I am actually unsure when it would start recalculating them again when not stored in the PWH, this may be something you need to open a support ticket to clarify, if you feel it's needed.
I found your clarifications extremely helpful. Essentially you answered my main question by clarifying that the splittings will be stored in memory for one hour, so the memory consumption would depend on how many splittings are generated in a hour at peak time. So we would likely be "OK" as long as there are not > 50,000 in an hour during peak periods... as you note it is unclear exactly what would need to occur for calculations to resume again if that value was exceeded. I wonder if what I was told about the "reset splittings" only being applicable in cases where the results are stored in the PWD was wrong... any rate, probably not a concern in the case I am dealing with where the hourly volumes should be < 50,000.
You're very welcome Jeff. While i'm not sure either of us will ever run into it but... I'll make a pact with you to seek out and update this thread if we ever find out if/how to reset the splittings in the event that measure explosion turns off the BT even when not storing them in the PWH.