The AppDynamics Controller

The AppDynamics Controller is the central management server where the data for an AppDynamics deployment is stored, analyzed, and presented. The Controller serves the user interface (UI) for configuring and monitoring your environment. 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 and App Agents provide full internationalization support, with support for double- and triple-byte characters. This support provides the following abilities:

• Users can enter double- or triple-byte characters into text fields in the UI
• The Controller can accept double- or triple-byte characters from applications

Controller System Requirements

Controller Hardware Requirements

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.

Use Dedicated Hardware for the Controller

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.

Controller Performance Profiles

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.

* 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 Tuning for Large Scale Deployments.

Calculating Performance Profiles for a .NET Environment

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:

• AppPool-1 and AppPool-3 can have a maximum of two worker processes (known as a web garden)
• AppPool-2 can have one worker process

If applications are assigned to application pools as follows:

AppPool-1: AppA and AppB

AppPool-2: AppC, AppD and AppE

AppPool-3: AppF

Use the following formula to estimate the number of nodes:

AppPool-1 * number of applications * max number of worker processes
+
AppPool-2 * number of applications * max number of worker processes
+
AppPool-3 * number of applications * max number of worker processes
= 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:

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.

Hardware Requirements per Performance Profile

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.

* 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.

Note that the RAM recommendations shown here leave room for operating system processes. However, the recommendations assume that no other memory intensive applications are running on the same machine. The actual RAM allocated by the installer per profile size for the Controller application server and database in gigabytes are 1.6, 3, 12, 24, and 48, respectively. 

Similarly, the disk storage sizes shown in the table indicate the amount of space that must be available on the target machine. 

To complete an installation, the Controller installer requires there to be around 200 MB of free space available in the system-defined temporary directory, typically /tmp on Linux or c:\tmp on Windows. 

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.

Additional Disk I/O Information

The AppDynamics Controller always writes and reads using the following block sizes:

• Read block size: 16 K
• Write block size: 64 K

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. 

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.  

Additional Sizing Considerations

Event Store

The Event Store is an Elastic Search-based file store used by the Database Monitoring feature. If you intend to use Database Monitoring, you should provide for an additional 40 GB of disk space to accommodate the Event Store on the Controller machine.

Asynchronous Call Monitoring and End User Experience Monitoring (EUEM)

Monitoring asynchronous calls and using End User Monitoring (EUM) typically increases the number of metrics collected.  As a result:

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

Specifically the features affect the workload of the system as follows: 

• Monitoring asynchronous calls increases the number of metrics per minute to a maximum number of 23000 per minute. 
• EUEM
  • Web EUEM can increase the number of individual metric data points per minute by up to 22000
  • Mobile EUEM 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.
     The number of separate EUEM metric names saved in the Controller database can be larger than the kinds of individual data points saved.  For example a metric name for a metric for iOS 5 might still be in the database even if all your users have migrated away from iOS 5.  So the metric name would no longer have an impact on resource utilization, but it would count against the default limit in the Controller for metric names per application.  The default limit for names is 200,000 for Web EUEM and 100,000 for Mobile EUEM.

Linux file descriptor limit

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.

Running the Controller on Virtual Machines

The Controller can run on virtual machines, but with a few additional considerations: 

• Large or extra large deployments in virtual machine environments are not supported.
• The Controller license is bound to the MAC address of the host machine. To run the Controller on a virtual machine, you must ensure that the host virtual machine uses a fixed MAC address. 
• The virtual machine that hosts the Controller must meet hardware resource requirements that are equivalent to physical machines, including I/O performance. 

To ensure that your virtualized storage subsystem is providing the required I/O capacity, run the following disk I/O rate tests.

To measure available Disk I/O

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.

1. Download the free IOzone tool.
   • Download IOzone for Linux
   • Download IOzone for Windows

2. Execute the following commands:

   	For Linux	For Windows
   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

3. Verify available disk I/O.

The results from these tests should match the Disk I/O requirements specified in Hardware Requirements Per Performance Profile.

Network Bandwidth Requirements

See Install Agents for information on bandwidth usage in an AppDynamics deployment.

Additional Requirements

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 Controller itself  is required for very large installations, as detailed in Tuning for Large Scale Deployments.

Learn More

• Logical Model
• Configure File Descriptor Limits on Linux
• Controller Sizing FAQ