Follow these guidelines to minimize potential resource issues on the NAM Probe and to also minimize resource problems on the report servers that the NAM Probe sends data to.
When dealing with capacity issues in NAM, capacity problems experienced by a report server are often caused by having the NAM Probe monitor too much detail at too many levels. Always review your requirements and expectations as the first step in dealing with capacity issues in NAM. The report server can be configured to reduce the load, but it is always best to avoid overwhelming the server with data in the first place.
The following configuration settings affect the NAM Probe itself and possibly the report servers, while other NAM Probe configuration settings may affect the servers in particular, while leaving the NAM Probe largely unaffected. These are indicated where needed.
Configure the NAM Probe to use user-defined software services only, provided that this agrees with your monitoring requirements.
The effectiveness of such filtering and its impact on performance is heavily dependent on the traffic profile and the CPU power required to analyze the traffic that is not filtered out. The NAM Probe can filter out more traffic when monitoring more analysis-hungry protocols such as HTTP, but less traffic for generic TCP traffic.
Minimize the number of individual list-based monitoring definitions.
Make sure that the total number of definitions related to the monitoring entities does not expand unnecessarily. This applies to all of the objects types defined in the NAM Probe configuration as lists, such as user-defined software services, URLs, static frames, custom metrics, custom attributes, and grouping parameters.
Applies to DC RUM 2017
Ensure that the NAM Probe is configured so that the number of observed dimension values does not expand unnecessarily.
The ADS can experience memory problems if the observed values of a dimension used for measurements—such as users, URLs, or sites—are unusually dynamic, particularly when this happens over a long period of time. For example, if the user name is set to be the session ID string, this will be unique for every new user session. Consequently, each day the ADS will receive a new batch of distinct user names, eventually causing the set of observed users to grow dramatically.
Also, if you configure the NAM Probe so that every URL string is registered as unique—by, for example, including the time stamp as a page parameter—the list of unique URLs will grow very large and cause memory problems on the ADS.
Minimize the number and complexity of regular expressions used in your configuration settings.
Regular expressions are used, for example, for user name recognition, application error definition, or URL monitoring.
Minimize the number of defined server ranges.
The NAM Probe performs well with up to 100 server ranges defined in its configuration, though it may also cope well with higher values, depending on other configuration settings.
Minimize monitoring of compressed pages, if possible.
Compressed page monitoring is handled automatically and there are no configuration options to turn this functionality on or off. However, you may be able to filter out traffic containing these pages before it reaches the NAM Probe. NAM Probe performance tuning
The processing of compressed pages may have an additional effect on performance and memory usage, but only if actual decompression needs to be performed as part of the analysis. For example, when monitoring HTTP application errors (responses) or custom attributes, compressed pages need to be decompressed before this information can be extracted.
Minimize monitoring of long POST payloads.
Even if no actual long POST payloads occur in the monitored traffic, selecting this configuration option will cause additional memory usage because larger buffers are allocated for the analysis. Additional resource usage will be incurred if long payloads are found.
Minimize monitoring of chunk-encoded data and dynamically generated content.
You cannot turn this functionality on or off, but it is good practice to minimize monitoring of such traffic, since the additional processing required to handle this type of traffic does significantly increase NAM Probe resource usage.
Minimize monitoring of HTML frame sets.
Monitoring HTML frame sets consumes additional NAM Probe resources. Define your automatic frame set recognition on a per-service basis, if you do not need to configure automatic frame set recognition globally for all monitored services. However, the global option for enabling frame set recognition (the option not referring to “automatic” frame set recognition) must be turned on in order to enable any analysis of frames at any level, automatic or static.
Applies to DC RUM 2017
Filter the ADS data at the NAM Probe (old AMD) level.
Subject to your data center architecture, try to filter or omit certain traffic before it reaches the NAM Probe. On the NAM Probe itself, reduce the number of monitored services or reconfigure them using the following filtering methods:
- Configure the level of monitoring per URL. Flag each URL or URL mask defined by a regular expression to be included in the NAM Server (CAS) and ADS data or only in NAM Server data. Enable ADS data only for the most important web transactions in order to limit the number of pages per day to be kept by the ADS.
Use the ADS to provide low-level diagnostic details for troubleshooting and configure it to keep these details only for the most important transactions or URLs on the site.
- Perform similar filtering on per user basis, so that you select (by name or IP address) the users that are most important and should be monitored in more detail.
What to do next
After adding a new complex configuration definition—such as one containing a regular expression, frame sets, or complex user recognition rules—test whether it significantly affects NAM Probe performance, memory usage, and stability. Also, when extending the range of monitored services, observe the performance of the report servers.\