Hello valued community,
This is a question regarding best practices and field experiences concerning URL Auto Aging and related CAS settings.
Standard the CAS has the URL count (RTM_URLAGING_COUNT) set to 500 and the URL lifetime (RTM_URLAGING_LIFETIME) on 420 minutes (7 hours).
Question is, especially in larger environment, if there other values utilized, possibly to enjoy more/longer the operations data. And what can be expected as impact, if count and lifetime values are adjusted.
A frequent, and I think related, asked (customer) question is why for some regular used applications the next day the operations are already missing. Perhaps in relation to different settings this can be addressed, but at what costs.
As reference we have a site where with the standard values, and below DB statistics. It counts 1800+ unique URLs. It's mostly a office time environment, with some night time external activity. Hence, the URLAGING_LIFETIME of 7 hours is easily reached.
Would URL count (RTM_URLAGING_COUNT) increase to 1000, 1500, 2000 be an option? Would there be reason to adjust the lifetime?
|Advanced DB Statistics||Applications|
|Advanced DB Statistics||Users|
|Advanced DB Statistics||Manual sites|
|Advanced DB Statistics||File defined sites|
|Advanced DB Statistics||AS sites|
|Advanced DB Statistics||CIDR sites|
|Advanced DB Statistics||Predefined sites|
|Advanced DB Statistics||Servers|
|Advanced DB Statistics||URLs on servers|
|Advanced DB Statistics||Unique URLs|
|Advanced DB Statistics||Services (incl URLs)|
|Advanced DB Statistics||Services (excl URLs)|
|Advanced DB Statistics||Aggregated Sessions (AS+AL)|
|Advanced DB Statistics||Aggregated Sessions (AI)|
|Advanced DB Statistics||Server samples|
|Advanced DB Statistics||Server aggregated samples|
|Advanced DB Statistics||Network samples|
|Advanced DB Statistics||Network aggregated samples|
|Advanced DB Statistics||Usage samples|
|Advanced DB Statistics||Last sample retrieved|
|Advanced DB Statistics||Raw sessions|
Solved! Go to Solution.
So far, looking in to past experience we had, there were environments where there was benefit from changing RTM_URLAGING_COUNT and/ or RTM_URLAGING_LIFETIME. Those are however not so frequent cases.
If you are for example monitoring some banking system, used 24/7, then it is not needed to change the values, as the frequency of occurrence of the most interesting urls is high enough to prevent CAS from removing them from the database.
On the other hand, if you are running some intranet application, available and utilized only during business hours, then most urls will appear and vanish on daily basis. And this is where we have have to take some decisions and actions together with the end user / business owner.
Here are some possible solutions:
1) to pick up the most critical urls, and configure them as 'monitor specific url' in RUM Console (they have to be specified explicitly, regex is not an option). Those urls will not be a subject of aging.
2) to pick up the most critical urls, and add them to a "container" like "reporting group" or "application/transaction configuration".
3) and finally the modification of RTM_URLAGING_COUNT and/ or RTM_URLAGING_LIFETIME
So as you are aware, first query checks how many operations are present in the database. If there is less than RTM_URLAGING_COUNT, then we do nothing. If there is more, then we search for those which did not appear within RTM_URLAGING_LIFETIME.
So if you have some url, that is removed by CAS, but it will appear for sure within next 24 hours, you can decide on extending the 'LIFETIME' value to reflect 24 hours, or you can change 'COUNT', or you can change both. Each approach has its advantages and disadvantages:
a) If you only change 'LIFETIME', then CAS will still review the list of urls (literally spent time running query), when there are more than 'COUNT' number of urls in the database
b) Now imagine that you only change 'COUNT'. At some point in time one of your monitored software services is changed by developers of that application. They decide to add some type of unique string inside url name (some random indentifiers of the session or so). In that case those may push out your favorite urls from the database anyway, and at the end of the day, you will have some floating list of urls on the reports (this is not just a hypothetical situation, but something I noticed on production environments of some of our customers)
c) Now let's say that you changed both - 'LIFETIME' (to 24 hours) & 'COUNT'. Your favorite urls will not vanish within 24 hours. Problematic urls from point 'b', will be also kept in the database for 24 hours, until time passes, and they are flushed. So this will have impact on number of "Advanced DB Statistics - Raw sessions", thus also performance and size of the database.
So when it comes to poit '3', that you are interested in - we do not have any formula to propose the best 'COUNT' and 'LIFETIME'settings, based on report database statistics report. It is a matter of observation, to decide what to do, and usually we first advise customers to check if options '1' & '2' are something they will benefit from.
There were however situations, where url aging mechanism, was literally killing CAS, lasting for more than 40 minutes and resulting in CAS restart. And those were the situations, where we noticed regularity in some urls appearing and disappearing from the database - which eventually was resolved by manipulation on either both, or one of the settings you are concerned about.
** Additonal note - In the text above, I was constantly using 'url' term. Aging rules equally concern xml / soap operations, mq operations, sql queries, and any analyzer that we have, which can produce name of the operation.
*** Now some quesiton from my end - you showed some figures from 'advanced database statistics' section here - are those numbers coming from production enviornment? It may be a false negative, but I am suprised with the number of 'raw sessions' here. If that is ok with you, then you may create some evaluation case for the support, so we can check the behavior of this server. In that case it will be mandatory to provide us with the full exportconfig from the CAS (with all options set, including 'data from the probes')
Thank you very much for your detailed explanation. Although familiar with the basics (and using step 1 and 2 as prefered approach), this is insight-full information in the approach of customer's setups. Option 3 to be used with great care.
Yes, the figures are from an actual life environment. By your suggestion I will raise an evaluation case with support.