Sizing for the NAM Server is determined mainly by the type of analysis required for your deployment.
Note: This is part of the Capacity planning guide
Basic planning of NAM Server sizing
Determine the basic configuration settings to be used for the NAM Server.
The number of monitored users is usually the most important factor for the overall number of sessions. If the NAM Server is deployed in a large environment (such as more than 50,000 users), do not store single-user information in the NAM Server database. Keep the number of unique users that the NAM Server is tracking in its database below 50,000. This number includes aggregated and individual users.
Note that the Enable on-demand access to user activity details option for the NAM Server may allow you to view user details while still performing user aggregation for performance reasons. For more information, see Configuring NAM Server scalability options.
Applies to DC RUM 2017
Determine the scalability mode to be used for the ADS: Small Website or Large Website.
For more information, see Configuring ADS scalability options.
Compare your expected NAM Server requirements with the capacity and sizing limits to gauge whether capacity problems are likely to occur.
Compare the number of sessions, users, operations, servers, and locations with NAM Server limits and anticipate that memory will be consumed faster if your environment has atypical characteristics such as many more URLs than users. In less typical cases, especially when there are many URLs or sites, the cache limits can be reached earlier.
Determine the SQL database server to be used.
SQL I/O disk performance is the greatest capacity limiting factor for the NAM Server. Do not offload the SQL database from the NAM Server machine to another server unless the other server offers faster disk I/O speed and, if the other server is shared, the effective available I/O on the other machine is at least the same as that of the local hardware. For more information, see SQL Server offload - advantages and disadvantages.
Additional steps for planning of NAM Server sizing
Do not plan to install any other memory-consuming processes on the NAM Server unless your estimates of resource usage allow for this.
Applies to DC RUM 2017
Avoid installing the NAM Server and ADS on the same machine. Plan separate installations unless your estimates ensure that there will be no capacity problems.
Perform any physical memory upgrade before installing the NAM Server. Adding memory after installing the NAM Server will not automatically cause Java to use this new memory. For more information, see Report server memory sizing and performance.
Consider using server farms. The monitored data can be split among servers in a farm cluster, which provides a ready-to-use set of reports that automatically aggregate data from a number of servers.
A server farm cluster offers automatic load-balancing. For example, you can use definitions of IP ranges for clients (in Advanced Properties Editor) to separate one group of users (such as Internet anonymous users) from another group of users (such as internal VIP users or partners).
After you separate the data and set up a server farm, all existing DMI reports on the master server will automatically switch to show data from all of the report servers of the farm. For new DMI reports, you can choose whether that report takes data from a single report server or from all report servers, either separately or aggregated. Note that the same user existing on different slave servers will be double-counted on the master server.
Estimated report server capacity
NAM Server estimated capacity
NAM Server estimated capacity is 6 million, which is the estimated number of sessions stored in the database per configuration.
A session in this context is a unique combination of server, URL, user, location, interface (NAM Probe), application, server port, protocol browser and operating system. Depending on the server configuration, a user may be represented by an IP address, user name or both; or by an aggregate that groups together a number of IP addresses. For more information, see NAM Server capacity considerations.
Note, however, that this is an approximate limit only and, depending on the actual traffic profile and complexity, it is possible that many more sessions can be stored in the database without significant performance problems.
To check the number of sessions, view the Number of sessions chart on the Capacity Status report, which is accessible through Tools ► Diagnostics ► NAM Server capacity on the report servers.
ADS estimated capacity
Applies to DC RUM 2017
Estimated ADS capacity is as follows:
Small website -
2M operations per day.
Large website -
10M operations per day.
Note that the actual capacity of an ADS for storing data in practical cases may be two to three times higher than these estimates. The estimates take into account both the capacity of the system and an acceptable response time of the ADS-based reports (8 to 30 seconds). If these capacity figures are exceeded, the response time may become unacceptable, even though the system can physically store more data.
Note that the capacity limits that are configured for the installation on the Scalability screen can be exceeded. If the capacity limits are exceeded, the data is still collected but a warning is displayed.
For the details of recommended hardware configurations for report servers, see General hardware requirements.
NAM Server planning examples
The following planning examples refer to NAM Server deployments for monitoring the specified aspects of a network. They do not attempt to estimate the requirements for monitoring all aspects of an entire network.
Example: small website and enterprise network with a large SAP GUI component
For the enterprise's LAN traffic, assume a large SAP GUI component, approximately 200 K operations per day and approximately 350 users, peak traffic rates of 300 Kbps. For the web traffic, assume approximately 4,000 web users who access about 500 unique URLs on several web servers; website users load 500 K pages daily.
- Using single-user recognition for NAM Server should not present a problem. Because of the small number of users, you can plan to store single-user information. The expected total of 4,000 web users is well within the NAM Server limits.
- In the context of capacity, a session is a unique URL that is accessed one or more times by a given user on a specific server. Assuming an average of 10 sessions per day per user, the 4,000 users will generate approximately 400,000 sessions in a 10-day interval. This is well within the capacity limits, so you can plan to keep detailed 5-minute data stored for ten days or longer, as well as 30 days of one-day roll-ups and 12 months of monthly roll-ups.
- Web monitoring can be performed by the NAM Server operating in the small website mode.
This example is illustrated in the context of a specific network in NAM deployment example: small website and enterprise network
Example: large internet-facing website
This example assumes that the website serves hundreds of thousands or millions of users grouped into the top 250 ISPs, who are accessing hundreds of URLs on dozens of web servers. Website users load nearly 20 million pages daily. Traffic levels are of the order of 2 Gbps, with 25% of that amount being an SSL component, 3 million operations per day, and with approximately 175 K users per day and nearly 1 million sessions.
- Do not plan to use single-user recognition on the NAM Server. Instead use aggregate users (ASN aggregation and individual user counting). If single-user details are required, use the User activity details and server statistics on demand option. For more information, see NAM Server capacity considerations.
- Assuming 1 M sessions per day, plan to keep detailed 5-minute data stored for three days. In addition to that, plan to keep 30 days of one-day roll-ups, 12 months of monthly roll-ups.
- Install each report server on a different machine.
- The machines should be 64 bit before the software is installed.
- Consider monitoring back-end data using a second NAM Server that will keep data for the database only. For this case, set up filtering by client IP address, where the client is not the Internet client, but rather the back-end of the web server.
This example is illustrated in the context of a specific network in NAM deployment example: large website and supporting multi-tier infrastructure.