Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I configure Analytics for on-premises Controllers?

 Analytics' Recipe Book for on-prem configuration

 

Overview

The following tables contain data based on EUM Processor and Events Service load testing combinations under synthetic load. The tables have been normalized. 

 

Once the EUM traffic profile has been estimated, you can use these maximum load measurement results to establish which T-shirt size the EUM Processor and Events Service should be.

 

How do I account for multiple traffic types?

If you plan to consume more than one type of traffic, then you should add EUM loads using beacons, and add Events Service loads using Normalized Performance Events.

 

 

 

Normalized EUM Processor and Events Service Load Testing Tables

Use the following maximum load measurement results to establish the EUM Processor and Event Service T-shirt sizes.

 

Web Maximum Load Testing Results

EUM size
Events Service size
Max. EUM Beacons/min
Max. ES Browser record events/min
Max. ES Browser session events/min
Max. ES Normalized Performance Events/min

S

S

60K

60K

3K

  • 60k browser records/min * 0.33 Normalized Performance Events / browser record event
  • 3k Browser session events/min * 5 Normalized Performance Events / session event= 35k Normalized Performance Events / min

M

M

120K

120K

6K

  • 120k browser records/min * 0.33 Normalized Performance Events / browser record event
  • 6k Browser session events/min * 5 Normalized Performance Events / session event = 70k Normalized Performance Events / min

L

L

300K

300K

12K

  • + 300k browser records/min * 0.33 Normalized Performance Events / browser record event
  • 12k Browser session events/min * 5 Normalized Performance Events / session event = 160k Normalized Performance Events / min

 

Mobile Maximum Load Testing Results

EUM size
Events Service size
Maximum EUM Beacons /min
Maximum
ES Mobile snapshot events /min
Maximum ES
Mobile session events /min
Max. ES Normalized Performance Events / min

S

L

90K

70K

40K

  • + 70k Mobile snapshots/min * 0.33 Normalized Performance Events / Mobile snapshot event
  • 40k Mobile session events/min * 5 Normalized Performance Events / session event = 223.3k Normalized Performance Events / min

M

XL

130K

110K

61K

  • 110k Mobile snapshots/min * 0.33 Normalized Performance Events / Mobile snapshot event
  • 61k Mobile session events/min * 5 Normalized Performance Events / session event
  • 341.7k Normalized Performance Events / min

L

XXL

550K

1.35M

118K

  • 3.5 Mobile snapshots/min * 0.33 Normalized Performance Events / Mobile snapshot event
  • 118k Mobile session events/min * 5 Normalized Performance Events / session event = 1756.7k Normalized Performance Events / min

 

IoT Maximum Load Testing Results

EUM size
Events Service size
Max. EUM Beacons/min
Max. ES IoT records/min
Max. ES Normalized Performance
Events/minute

S

M

110K

500K

  • 500k IoT records / min * 0.33 Normalized Performance Events / IoT record event
  • 166.7k Normalized Performance Events / min

M

L

300K

600K

  • 600k IoT records / min * 0.33 Normalized Performance Events / IoT record event
  • 200k Normalized Performance Events / min

L

XL

600K

1M

  • 1M IoT records / min * 0.33 Normalized Performance Events / IoT record event
  • 333.3k Normalized Performance Events / min

 

EUM Processor T-shirt Sizes

T-shirt size
EUM recommended instance type
EUM Processor JVM heap size

S

4 core, 16GB RAM, disk 300GB 600IOPS (m4.xlarge)

11GB

M

8 core, 32GB RAM, disk 300GB 600IOPS (m4.2xlarge)

30GB

L

16 core, 64GB RAM, disk 300GB 600IOPS (m4.4xlarge)

50GB

 

 

Node Configuration and System Architecture

The Events Service node network setup used in this example has speeds of >= 1 GBPs. Latencies are similar to a switched network, such that:

  • Average SSD latencies are < 1.2ms per read/write operation
  • Average nVME latencies are < 0.4ms per read/write operation

 

If SaaS deployment is not an option, consider splitting the deployment on the Application level into multiple accounts and multiple controllers.

 

AppDynamics strongly recommends using SSD-backed instances for Analytics—SAN is not recommended. This is because AppDynamics follows the official Elasticsearch hardware guidelines, configurations vary widely, and AppDynamics cannot guarantee that a particular SAN configuration is supported.

 

Finally, you should avoid network-attached storage (NAS). A NAS solution is often slower, displays larger latencies with a wider deviation in average latency, and is a single point of failure.

 

 

Events Service T-shirt Sizes

The following table shows the recommended number of nodes and node configuration for each T-shirt size.

See Stipulate throughput by license type in the Quick Method.

 

T-Shirt Size
Number of Nodes
Normalized Performance Events/min
Recommended Node Configuration
SaaS Recommended/
Required?

X-Small

1

50000

4 core, SSD (ideally as nVME) or HDD 7,200 RPM

No

Proof of Concept, Dev, & Demo

Small

3

100000

4 core, SSD (ideally as nVME)

(i2.xlarge)

No

Medium

3

195761

8 core, SSD (ideally as nVME)

(i2.2xlarge)

No

Large

5

284000

8 core, SSD (ideally as nVME)

(i3.2xlarge)

Recommended sometimes

XLarge

10

438000

8-16 core, nVME 
(i3.2xlarge)

Recommended

XXLarge

20

600000

8-16 core, nVME

(i3.2xlarge)

Depending on query load and other factors that impact performance, larger nodes may be more suitable

Required

  • On-prem deployments of this size are not supported
  • Overall deployment should be structured as multiple smaller deployments, each with its own controller

 

Once you determine your T-shirt size, refer to the non-virtual hardware specifications that correspond to the relevant EC2 instance size:

The Events Service should be on separate, dedicated server(s).

 

 

Shard Replication in Elasticsearch

We assume a replication factor of 1 for Elasticsearch. Performance tests show that there is an upper limit to the average CPU performance of a cluster. Due to the replication and synchronization of Elasticsearch node segments, the limit decreases as the number of nodes increases.

 

Risks and Benefits

Not enabling Elasticsearch replication has both risks and benefits:

Risks
    • The lack of redundancy highly increases the likelihood of data loss if any nodes in the Events Service cluster go down.

 

Benefits
    • CPU ingestion utilization decreases by approximately 55%
    • Data drive storage requirements decrease by approximately 50%

 

Data Replication

Since Elasticsearch builds in redundancy with replicas, there is no need for RAID configurations other than RAID 0. For this reason, Elasticsearch recommends using RAID 0 and increasing write throughput.

 

If RAID (1,3,5) replication is selected, AppDynamics does not provide support for disk performance or data integrity issues.

Version history
Revision #:
11 of 11
Last update:
‎03-31-2020 05:15 PM
Updated by:
 
Labels (1)


Found this article helpful? Click the Thumbs Up button.
Have an additional comment? Post it below.
0 Kudos