AppDynamics Application Intelligence Platform
The AppDynamics Controller is the central management server where all data is stored and analyzed. The Controller serves the Flash-based user interface (UI). All AppDynamics Agents connect to the Controller to report data.
The Controller uses an embedded Glassfish application server and an embedded MySQL database. It has a browser-based Administration interface for various system parameters.
The Controller installer ships with and automatically installs all of its required software. You do not need any additional software to install the AppDynamics Controller.
The Controller is supported on the following Operating Systems:
Linux (32 and 64-bit)
Microsoft Windows (32 and 64-bit)
The AppDynamics UI works best with the latest version of any modern browser along with the latest version of Flash. The Controller UI has been tested with the following browsers and versions:
The Controller UI requires Flash Player 10 or greater; AppDynamics recommends version 11.
You can use an external directory server to authenticate and authorize user access to the Controller UI. The Controller works with directory servers that comply with LDAP (Lightweight Directory Access Protocol) version 3. While the Controller should be able to work with any LDAPv3-compliant server, it has been verified against these LDAP products:
The Controller performs large-scale real-time data analysis and correlation supporting multiple agents at any given time. It constantly persists large amounts of data to the storage system. For the Controller to be responsive, it must have appropriate hardware. Use these recommendations in the performance profiles to determine the hardware needed for your Controller.
These recommendations represent a good starting point only, your requirements may vary depending on the number of metrics per minute generated in your environment.
AppDynamics strongly recommends that you install the Controller on a dedicated machine. The hardware requirements described in this document assume that no other major processes are running on the machine where the Controller is installed. A Controller with more than 250 nodes must run on a dedicated machine.
For information about using a Virtual Machine for the Controller, see Running the Controller on Virtual Machines.
Size the Controller hardware requirements using a performance profile based on the number of nodes in your environment and the number of metrics per minute being reported to the controller. For general information about applications and nodes, see Logical Model.
The Controller performance profiles are based on the number of nodes. When the number of app servers is static, it is easy to determine. However, WebSphere on z/OS, dynamic cloud environments, and .NET environments dynamically spawn new agents. For z/WebSphere and clouds you need to consider historic data to estimate the correct sizing. For .NET see Calculating Performance Profiles for a .NET Environment.
Controller Performance Profile
Number of Nodes*
Number of Business Apps
Recommended for VMs
Up to 5
Up to 10
Up to 50
Up to 250
Custom - Contact Support or TAM****
* In a Java environment there is usually one AppDynamics App Agent for Java per node. In contrast, one AppDynamics App Agent for .NET may support multiple nodes. See Calculating Performance Profiles for a .NET Environment to arrive at the number of nodes for a .NET environment.
** AppDynamics neither recommends nor supports Large or Extra Large deployments in virtual environments.
*** For configuration information applicable to deployments in the Extra Large performance profile and larger (500+ nodes), see Configuring a Controller Environment for the Large Enterprise.
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 5 instances the .NET Agent will create 5 nodes.
The maximum number of instances of a particular IIS application is determined by the number of worker processes configured for its application pool. Consider the following diagram:
The diagram shows three application pools: AppPool-1, AppPool-2, and AppPool-3 with the following characteristics:
If applications are assigned to application pools as follows:
AppPool-1: AppA and AppB
AppPool-2: AppC, AppD and AppE
Use the following formula to estimate the number of nodes:
In this case the numbers would be:
AppPool-1 nodes = 4 (2 applications * 2 worker processes)
AppPool-2 nodes = 3 (3 applications * 1 worker process)
AppPool-3 nodes = 2 (1 application * 2 worker processes)
for a total of 9 nodes.
To find the number of CLRs that will be launched for a particular .NET Application / App Pool:
For larger deployments with hundreds of nodes, sizing the hardware for a Controller depends upon the number of agents and the complexity of your business transactions. The number of metrics can become very large. The following recommendations are a starting point.
Supported OS platforms
CPU # of cores
Linux (32 & 64-bit)
2 CPU Cores
up to 5
5 K max
Linux (32 & 64-bit)
4 CPU Cores
25 K max
8 CPU Cores
250 K max
24 CPU Cores
32 GB RAM
512 K max
24 CPU Cores
64 GB RAM
1 Million max
* Also see Controller Performance Profiles. The agent count requirements do not reflect the use of End User Monitoring (EUM). See Additional Sizing Considerations for more information about EUM.
** When sizing in the Extra Large profile range or higher, contact your AppDynamics Technical Account Manager or the AppDynamics Support Team for assistance.
For information on hardware requirements for AppDynamics for Databases, see AppDynamics for Databases, Hardware Requirements.
The Demo profile is only for demonstration and evaluation environments and is not suited for production installations.
The AppDynamics Controller always writes and reads using the following block sizes:
When considering I/O requirements listed in Hardware Requirements per Performance Profile, keep in mind that while onboard disks typically satisfy the I/O requirements, in a SAN environment, the bottleneck in terms of I/O write and read speed becomes the latency between the CPU and the SAN-based storage. For information on I/O and off-board storage, see the next section, Off-Board Storage System Considerations.
AppDynamics strongly recommends that you avoid installing the Controller or putting the Controller's data directory, db/data, on an NFS-mounted filesystem. NFS adds latency and throughput constraints that can affect Controller performance and even lead to data corruption.
Similarly, you should avoid iSCSI or other SAN technologies that are subject to quality of service issues from the underlying network.
For best performance, if not using on-board disk storage, consider using a robust Fiber Channel, FCoE, or iSCSI over 10Gbit Ethernet SAN. Whatever underlying technology you use, keep in mind that your system must provide disk data read and write speeds over the connection between the CPU and storage that are equivalent to the disk I/O requirements listed in Hardware Requirements per Performance Profile. In all cases, be sure to thoroughly load test the deployment with real-world traffic load before putting the Controller into a live environment.
Monitoring asynchronous calls and using End User Monitoring (EUM) typically increases the number of metrics collected. As a result:
Monitoring asynchronous calls increases the number of metrics per minute to a maximum number of 23000 per minute. This does not apply for .NET environments because async monitoring is not supported for .NET.
The use of Web EUM in your applications can increase the number of metrics per minute by up to 22000 metrics.
The use of Mobile APM can increase the number of metrics 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.
For Linux environments, it is important to set the file descriptor limit to at least 65535. For more details see Configure File Descriptor Limits on Linux.
The Controller can run on virtual machines, but with a few additional considerations:
To ensure that your virtualized storage subsystem is providing the required I/O capacity, run the following disk I/O rate tests.
These tests write 32 GB of data to your disk and may take some time to complete. They produce numbers for write, rewrite, read, reread,random read, and random write.
Execute the following commands:
Test for WriteSpeed
/opt/iozone/bin/iozone -s 32000m -r 64k -i 0 -i 1 -w -f /<path-to-your-partition>/test1
<path-to-your-partition>/Benchmarks/Iozone3.353/iozone -s 32000m -r64k -i 0 -i 1 -w -f test1
Test for RandomRead
/opt/iozone/bin/iozone -s 32000m -r 16k -i 2 -w -f /<path-to-your-partition>/test1
<path-to-your-partition>/Benchmarks/Iozone3.353/iozone -s 32000m -r16k -i 2 -w -f test1
The results from these tests should match the Disk I/O requirements specified in Hardware Requirements Per Performance Profile.
In addition to the correct sizing of the hardware, special tuning of the operating system, the Glassfish application server, the MySQL as well as the Controlleritself is required for very large installations, as detailed in Configuring a Controller Environment for the Large Enterprise.