Time to upgrade! NAM is scheduled for end of support. It's time to move to Dynatrace our all-in-one software intelligence platform.

ADS database sizing and performance in DC RUM 2017

Applies to DC RUM 2017

A very large ADS database results in slower report execution. Because the size of the ADS database grows more or less proportionally to the volume of the analyzed traffic, you can address this issue either by reducing the volume or reconfiguring ADS to the large website mode. To resolve ADS database sizing issues, try the following:

  • Do not use the NAM Server to store all the details for URLs that are loaded only a few times a day, because they have a negligible effect on overall website performance. If every URL has to be reported for troubleshooting purposes, consider using the ADS as a solution in small and medium size environments where the number of pages does not exceed the ADS limits.
  • If you have installed the CAS and ADS on the same machine and if either needs more memory, consider installing them on separate machines with additional memory. The same is true with SQL Server when it is installed on the same machine.
  • If you are using a 32-bit report server, consider upgrading to a 64-bit report server.
    The best way to avoid the memory limit issue on 32-bit machines is to upgrade to 64-bit ADS on a 64-bit machine.

Use data filtering

Limit database growth by checking the operation volume for all monitored applications and then attempt to reduce it. Such a reduction can be achieved at various stages:

  1. Filter the ADS data at the AMD level.
    Subject to your data center architecture, try to filter or omit certain traffic before it reaches the AMD. On the AMD 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 CAS and ADS data or only in CAS 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.
      Tip: 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.
  2. Filter data at the report server level.
    Reconfigure the ADS to selectively read from the AMD and extract only the data related to specified servers or clients defined by IP ranges. Note that this filtering is secondary to filtering done at the AMD level, where you can specify which data is to be sent to the report server.
  3. Disable the generation of ADS data for the software services that require a lower level of detail in reporting. For example, disable front-end HTTP services but do not disable back-end database services.

Change the report server mode of operation

Consider re-configuring the ADS to the Large website option.

If the ADS is configured to monitor small websites, consider changing to the Large Website model if your monitoring requirements allow this. The Large Website model reduces database size, although at the price of reduced granularity of analysis because there will be no specific hit data stored in the database. This reduction in the level of stored information will take effect for all new data received from the AMD, but the existing data will not be purged until the normal aging processes delete it.

Load Sequence Step-Chart from URLs will not be available.

For more information, see Configuring ADS Scalability Options.

Scale the solution

  1. Consider using a remote SQL server, provided that it offers faster disk I/O speed than the machine hosting the server and that these benefits are not nullified by other factors.
    For more information, see SQL Server offload - advantages and disadvantages.
  2. Expand the system.
    Increasing the number of machines in the system will solve problems, but this should be treated as the last option, only in the unlikely situation when revising the requirements is impossible or insufficient. Depending on the specific architecture, there may be various ways of splitting the monitored infrastructure between different NAM systems.