IntroductionWe continue looking at APM CE setups that may be useful but can have hidden costs including opening support cases. This week we look at various user group situations.
Some APM administrators may not realize that they will get user information in defects whether it is set for enterprise or e-commerce mode. The difference is enterprise mode supports a wider range of user group identifiers and user information is not kept for historical reports. (Ecommerce only supports Request attribute user groups and Unidentified Users.)
Here are some common scenarios that can cause issues:
Scenario 1: Using case-sensitive user names/High number of Inactive Users
By selecting the case-sensitive user name setting, Gwashington,gwashington, and gwashingtoN are seen as three different users. This may be valid user names or user typos. For a busy enterprise mode application, this can fill up a database quickly. Combine this with a low setting for the number of days that a user becomes inactive and your APM database can fill up quickly. So cleaning up the database and changing the case-sensitive settings are two ways to alleviate this. Another way may be setting to e-commerce mode or removing the user identifier.
Scenario 2: Using a User Identifier with Ecommerce
The documentation states the following when having many user groups due to request attributes or many Client IP Subnets: Important: If your installation is a large-scale e-commerce site (hundreds of thousands or millions of users) use caution with this feature. The number of user groups created can become unmanageable.
In spite of the warning, some customers utilize a user identifier in e-commerce mode. This results in the following:
- Many users being created and stored in the database.- EM busy collecting user and session information which gets written to the database each hour. This eventually will fill up the database and it will become sluggish
So deploy users/user groups in ecommerce mode with caution and periodically assess the need for periodic database maintenance.
Scenario 3: Exceeding the Maximum APM CE User Group Limit
In the TESS-default.properties, there is a setting called maxUserGroups. It has a default value of 5000. Once reached, users are placed in the New Users Group and additional user groups are not created. However, the documentation is silent on what the highest that this value can be configured. Exceeding 5000 user groups should be done with care and will depend on your architecture and EM/database hardware.
Users/User groups are a great APM feature. But its impact on APM responsiveness should be reviewed as an ongoing task.
Questions:1. Are you a site that has seen one of these three scenarios? What did you do to resolve the situation?2. If you are using e-commerce with user identifiers, is performance and functionality working as expected?3. What other topics would you like me to cover?
Re: Scenario 3: Exceeding the Maximum APM CE User Group Limit
NOTE: As of 9.1 the maxUserGroups clamp property in tess-default.properties has actually moved to the new EM config file apm-events-thresholds.xml with property name introscope.enterprisemanager.max.transaction.user.groups : Manual Configuration File Upgrade Overview
The current APM 9.7 wiki also mentions it here: Upgrade Introscope Manually
However, there is still little guidance what is the maximum to set this to and the implications :-)
Good point - it would be very useful to know maximum recommended values for both these parameters to avoid APM DB/CEM UI performance problems.
introscope.enterprisemanager.max.transaction.user.groups and introscope.enterprisemanager.max.application.user.rows
I will kick that off internally & then we will publish some recommendations.