On this page:

Related pages:

This page describes general hardware and software requirements for the machines that host Events Service nodes.

General Requirements

About Hardware Capacity and Resource Planning

When estimating your hardware requirements, the first step is to determine the event ingestion rate (for transaction analytics) or the amount of data being indexed (for log analytics). This helps you to determine the number of analytics license units you will need.

Once you determine your license units requirements, it is important to consider other factors that affect the hardware capacity, such as the processing load of queries run against the Events Service and the actual type of hardware used. A physical server is likely to perform better than a virtual machine. You should also take into account seasonal or daily spikes in activity in your monitored environment in your considerations. 

An event is the basic unit of data in the events service. In terms of application performance management, a transaction analytics event corresponds to a call received at a tier. A business transaction instance that crosses three tiers, therefore, would result in three events being generated. In application performance management metrics, the number of business transaction instances is reflected by the number of calls metric for the overall application. In End User Monitoring, each page view equates to an event, as does each Ajax request, network request, or crash report. 

Events Service Node Sizing Based on License Units

The data in this section can help you plan your hardware requirements. It describes recommended hardware configurations (in the context of Amazon EC2 instance types) corresponding to the number of license entitlement units for log and transaction analytics. See License Entitlements and Restrictions for details about license units for log and transaction analytics. 

The hardware shown for each license amount represents the hardware capacity of a theoretical combined load of both transaction analytics and log analytics events. The numbers used were derived from actual tests that were performed with an uncombined load, from which the following numbers were extrapolated. Note that the test conditions did not include query load and so may not be representative of a true production analytics environment.

The following table shows sizing recommendations and describes the size of the cluster used for testing. This does not mean you are limited to a seven-node event service. If you need to go beyond seven nodes, contact your AppDynamics account representative to ensure proper sizing for your specific environment.

Event TypeAWS Machine Instance Type
i2.2xlarge (61 GB RAM, 8 vCPU, 1600 GB SSD)i2.4xlarge (122 GB RAM, 16 vCPU, 3200 GB SSD)i2.8xlarge (244 GB RAM, 32 vCPU, 6400 GB SSD)
1 node3 nodes5 nodes7 nodes1 node3 nodes5 nodes7 nodes1 node3 nodes5 nodes
Transaction analytics license units203744632241841135394120
Log analytics license units71017191619324439116270

The following points describe the test conditions under which the license units-to-hardware profile mappings in the table were generated:   

The tests were conducted on virtual hardware and programmatically generated work load. Real world work loads may vary. To best estimate your hardware sizing requirements, carefully consider the traffic patterns in your application and test the Events Service in a test environment that closely resembles your production application and user activity.

Sizing for EUM and Database Visibility Analytics

End User Monitoring and Database Visibility include analytics-related features that can also send data to the Events Service. In End User Monitoring, each page view equates to an event, as does each Ajax request, network request, or crash report. There can be a few dozen Ajax requests for every page load. In general, the ingestion capacity and sizing profile for EUM or Database Visbility analytics events are equivalent to that for Log Analytics, with the raw events size being about 2 kilobytes on average.

Calculate the Sizing for EUM

To calculate the sizing for EUM, multiply the peak number of browser records in a day by 12 KB. If peak capacity is reached, the Events Service simply starts dropping traffic.

The table below provides details about the memory and storage of different types of browser records. The default retention period is configurable.

Browser Record TypeMemory Requirements Per EventOptionalDefault Retention
base page, iframe, virtual page1 KB / 1.5 KB (with sessions enabled)No8 days
Ajax requests1 KBYes

Ajax requests aren’t stored in the Events Service by default.