Showing results for 
Show  only  | Search instead for 
Did you mean: 
AppDynamics Team (Retired)

When planning instrumentation for deploying Analytics on-prem, how do I build the traffic profile?


Table of Contents


How do I understand my traffic for sizing?

Understanding the characteristics of your traffic is the foundation for successful sizing. To build a traffic profile, answer the following questions.


If I have Business Transactions (BTs) in an APM application I want to enable Analytics on:


Am I seeking to enable Analytics on an existing or new APM application?

Existing APM application
  • Identify the BTs you need to instrument from the APM application page.
  • For each BT, count how many tiers, and on average how many requests are going through each tier for a single origin BT. Each tier for a single BT produces at least one event if a request passes through the tier and node.
  • Identify the peak sum of BTs per minute for all BTs and sum the count of events per those BTs to estimate the peak events per min. This enables you to size for the number of nodes and CPU.
New APM application
  • For a more accurate option, instrument and then go through an existing application.
  • If not instrumented, you should try to access using the available number of requests coming through each tier by:
    • count of log lines/timestamps

    • existing database aggregations

    • Q/A with application stakeholders

Figure 1 shows an example of how many BT events per tier are generated. Figure 2 shows the estimated number of events per APM BT.  


A tier can be called multiple times by originating BT, thus producing multiple events. If the request performs asynchronous calls on a single node then it's possible that a single request on a single tier could output multiple segments (events). Each async thread call becomes its own segment in the Java Agent. In .NET, results from an async call could be merged into one or more segments (events). 



Figure 1:  Example of how many BT events per tier are generated




Figure 2: Estimated number of events per APM BT



Do I have Log Analytics licenses?

If so, then:

  1. Collect log samples for a period of time per source.
  2. Determine the start and end times of each log
  3. Determine the file sizes which determine the required disk size for the Events Service footprint
    (which is approximately = file size * 1.7)
  4. Determine the number of lines or timestamps. Each is counted as one event
  5. Calculate the average number of events per minute for each log source

Avg number of lines per source number 1 =
(file 1 num of lines / (end time file 1 - start time file 1) + … + (file N num of lines / (end time file N - start time file N)) / number of files in source number 1
Then, sum the averages for an overall average number of log events

  1. Logs



You can also use these additional estimation methods:

What licenses do you have?

  • The limits on traffic that licenses specify serve as useful benchmarks when you estimate events later in the Instrument, Run, and Refine process.

What is the shape of traffic over time?

  • Is your traffic consistent or spiky?
  • What times of the day, week, month, season, or year produce changes?
  • You should plan your deployment to perform well at peak loads, or at least at the 90th percentile loads.

What are typical numbers for concurrent users?

  • Does this vary over time, and if so, what are the patterns?

What are typical patterns of user behavior?

  • Are users doing the exact same thing repeatedly, or taking diverse actions?
  • How are the patterns concentrated or spread out over time?

Mobile app crash rate

  • If any, what is the typical crash rate for your mobile apps?



How do I consider End User Management (EUM) usage when building my Events Service traffic profile? 

Unlike Business Transaction (BT) or Log Analytics licenses, the number of EUM licenses does not translate into a good basis to estimate what size machine can support a particular deployment. EUM performance depends on the number of beacons.


To accurately estimate expected beacons, you must understand:

  • The millions of browser page views and/or IOT events allowed by the licenses can be distributed in many ways over the year. Temporal distribution of traffic is key. 
  • Mobile licenses, by contrast, allow some thousands of mobile agents to connect per month—but any of those agents can send an unlimited number of requests. User behavior is key.


When building the traffic profile, you need detailed and accurate information.

The following will help you determine the projected EUM Analytics load: 




Browser Request User Monitoring (BRUM)

How many page views?
  • How many beacons per page view? Typically, it is one. 
    Typically, each beacon would produce one session event and one browser request event.
Mobile Request User Monitoring (MRUM)
  • How many session events per user event? Typically, it is one. 
  • How many MobileSnapshots per user event? Typically, it is one. 
  • How many crashes in a worst-case scenario?
    Review the MobileCrashReport.
Internet of Things (IoT)
  • How many devices and device types?
  • What is a typical transmission rate per minute per device type?


This table lists the unit-to-beacon relationship for each EUM license type.

License Type
Unit-to-Beacon Relationship

one million page views/year

One to one


TBD million IOT events/year

One to one


5K mobile agents/month
can connect

No unit-beacon relationship can be derived because:

  • Each mobile agent can send unlimited requests per month.
  • The total number of mobile beacons is not limited.

EUM license types and their unit-to-beacon relationships


Note: For up-to-date licensing information for EUM Analytics, click here.


Note: By default, each EUM Analytics event type is limited to 50GB per day. You can adjust that limit inside each Events Service node’s properties located in this directory: <Events-Service-Home>/conf/ in the folder
Version history
Last update:
‎02-12-2020 09:59 AM
Updated by: