Controller System Requirements

This page describes hardware and software requirements for the Controller host to help you prepare for your AppDynamics deployment.

About Controller Sizing Information

Every deployment is unique. Factors such as the nature of the application, workload, and the AppDynamics configuration can all affect the resources required for your specific scenario. Be sure to test the performance of your system in a staging environment, so that you can fully understand your requirements before deploying AppDynamics to its ultimate operating environment.  

Before installation, it's usually easiest to estimate your deployment size based on number of nodes. For Java, for example, a node corresponds to a JVM. However, the best indicator of the actual workload on your Controller is provided by the metric ingestion rate.

After initial installation, you should verify your Controller sizing using the metric upload rate. You then need to continue to monitor the Controller for changing workload brought about by changes in the monitored application, its usage patterns, or in the AppDynamics configuration.

General Hardware Requirements 

The following general requirements that apply to the machine on which you install the Controller:

• The Controller should run on a dedicated machine. A production Controller must run on a dedicated machine. The requirements here assume that no other major processes are running on the machine where the Controller is installed, including no other Controllers. 
• The Controller is not supported on machines that use Power Architecture processors, including PowerPC processors.
• The Controller installer requires around 200 MB of free space to be available in the system's temporary directory. 
• Disk I/O is a key element to Controller performance, particularly low latency. SAN and other types of network-attached storage are not supported for the Controller. See Disk I/O Requirements for more information. 

Controller Sizing

The following profile-specific requirements apply to the Controller machine. 

The table shows installer profiles by metric ingestion rate and node count. As previously noted, the actual metrics generated by a node can vary greatly depending on the nature of the application on the node and the AppDynamics configuration. Be sure to validate your sizing against the metric ingestion rate before deploying to production. 

The numbers here have been updated to reflect the latest performance testing results as of August, 2017.    

Additional Sizing Considerations

Note the following additional requirements:

• Large and extra large profile installations are not supported on virtual machines or systems that use network attached storage. 
• The RAM recommendations leave room for operating system processes. However, the recommendations assume that no other memory intensive applications are running on the same machine. 
• Disk sizing shown in the sizing table represents the approximate space consumption for metrics, about 7 MB for each metric per minute.
• The motherboard should not have more than 2 sockets. 
• See Calculating Node Count in .NET Environments for information related to sizing a .NET environment. 
• The agent counts do not reflect additional requirements for EUM or Database Visibility. See the following sections for more information.

Disk I/O Requirements

One of the most important indicators of a machine's ability to support the performance requirements of a Controller is the machine's disk I/O performance. Be sure to test I/O latency on the machine for the Controller under load to best understand the hardware needed for your deployment. 

The AppDynamics Controller performs two types of I/O operations important to Controller performance. The MySQL intent log is very sensitive to latency, and exclusively performs writes using varying block sizes; the latency to the log device should never exceed 3 ms. MySQL's InnoDB storage engine uses random, asynchronous, 16kB reads and writes to move database pages between disk and its RAM-based cache. In a properly sized Controller, most reads are satisfied from the cache.

AppDynamics does not support the placement of the Controller's MySQL data directory (datadir in MySQL's configuration file) on an NFS-mounted filesystem, iSCSI or any type of Storage Area Network (SAN). Use onboard disks, and be sure to test the deployment thoroughly with real-world traffic load before putting the Controller in a live environment. 

Calculating Node Count in .NET Environments

The .NET Agent dynamically creates nodes depending on the monitored application's configuration in the IIS server. An IIS server can create multiple instances of each monitored IIS application. For every instance the .NET Agent creates a node. For example, if an IIS application has five instances, the .NET Agent will create five nodes, one for each instance.

The maximum number of instances of a particular IIS application is determined by the number of worker processes configured for its application pool, as illustrated in the following diagram:

The diagram shows three application pools — AppPool-1, AppPool-2, and AppPool-3 — with the following characteristics:

• AppPool-1 and AppPool-3 can have a maximum of two worker processes (known as a web garden), containing two applications (AppA, AppB) and one application (AppF), respectively. 
• AppPool-2 can have one worker process. It has three applications.

To determine the number of nodes, for each AppPool, multiply the number of applications by the maximum number of worker processes. Add those together, as well as a node for the Windows service or standalone application processes. 

The example would result in nine AppPool nodes. Adding one for a Windows service would result in a total of ten nodes, calculated as follows: 

AppPool-1: 2 (applications) * 2 (max number of worker processes)  = 4
AppPool-2: 3 (applications) * 1 (max number of worker processes)  = 3
AppPool-3: 1 (application) * 2 (max number of worker processes)   = 2
Windows Service or standalone application process                 = 1
------
Total:                                                            = 10

To find the number of CLRs that will be launched for a particular .NET Application/App Pool:

1. Open the IIS manager and see the number of applications assigned to that AppPool.
2. Check if any AppPools are configured to run as a Web Garden. This would be a multiplier for the number of .NET nodes coming from this AppPool as described above.

Also see: http://technet.microsoft.com/en-us/library/cc725601(v=ws.10).aspx.

Sizing the Controller for the Events Service

The Events Service is a file-based storage facility used by EUM, Database Monitoring, and Analytics. Database Monitoring uses the Events Service instance embedded in the Controller by default. The disk space required will vary depending upon how active the databases are and how many are being monitored. 

For redundancy and optimum performance, the Events Service should run on a separate machine. For details on sizing considerations, see Events Service Requirements.  

Asynchronous Call Monitoring Considerations

The Small profile is not supported for installations with extensive async monitoring. A Medium profile running 40+ agents may need to upgrade to a configuration closer to a Large profile if extensive async monitoring are added. 

Specifically, monitoring asynchronous calls increases the number of metrics per minute to a maximum number of 23000 per minute. 

End User Monitoring (EUM) Considerations

End User Monitoring (EUM) typically increases the number of metrics collected. Accordingly, the Small profile is not supported for installations that use EUM. A Medium profile running 40+ agents should be sized at a specification closer to a Large profile for EUM.

Specifically, EUM impact metrics as follows:

• Web RUM can increase the number of individual metric data points per minute by up to 22000

• Mobile RUM can increase the number of individual metric data points per minute by as much as 15 to 25K per instrumented application, if your applications are heavily accessed. The actual number depends on how many network requests your applications receive.

Database Monitoring Considerations

The following guidelines can help you determine additional disk and RAM required for the machine hosting the Controller that is monitoring the Database Agent. For very large installations, you should work with your AppDynamics representative for additional guidelines. 

For on-premises installations, the machine running the Controller and Event Service will require (for data retention period of 10 days):

• 1 – 10 collectors: 2 GB RAM, Single CPU
• 10 – 20 collectors: 4 GB RAM, 2 CPUs
• More than 20 collectors: 8 GB RAM, 4 CPUs