Share This:

Hardware requirements for Virtual Machines

Server hardware and hypervisors must support 64-bit guests. Each instance of the various BMC Real End User Experience Monitoring components has the following minimum resource requirements:

Minimum resource requirements per component instance

Component

Processor

Memory

Disk

Number of network interfaces

BMC Application Performance Management Console

1 vCPU

4 GB

20 GB

1

Real User Analyzer

2 vCPU

8 GB

16 GB1

1

Real User Collector

2 vCPU

8 GB

28 GB

2

Performance Analytics Engine

2 vCPU

4 GB

10 GB

1

 

 

  The Above chart shows the minimum requirements needed to deploy the APM VM’s.    Each component requirements will be discussed in the preceding pages.  At the end of this document will be procedure how to adjust these settings in a VMWare environment

 

APM Console:  The console will not need more than 20 GB of hard disk space as it does not hold information in databases, it provides a ‘window’ into the data collected by its components.  It will run on 1vCPU and 4 GB but as more users are logged into the console at the same time, the responsiveness will decrease.  Less than or equal to 5 users can run with minimum requirements and above 5 users, more CPU and RAM should be allocated.  Also, more dashlets and dashboards being used by the current user at the same time will also demand more resources.  Best practice is to give minimum 2vCPU, 4-8GB of RAM and increase resources when you start to experience slowness when using the Console.

 

Real User Analyzer: The 1st Analyzer hard drive will never need to be greater than 16GB in size.  This hard drive is used for the OS of the Analyzer.  The 2nd hard drive added to the Analyzer is used to increase the data retention of the session browser database.  Using only the built in 16GB and not adding a 2nd hard drive will yield only a 1GB of session browser database storage.  The 2nd hard drive should be added with a minimum size of 100GB up unto a maximum size of 570GB.

Data Drive Size / Session Browser Size
570GB / 394GB (maximum)
200GB / 132GB
100GB / 61GB (minimum)

Memory and CPU:

Size

Processor

Memory

Disk

Expected volume of traffic

Low

2 vCPU

8 GB

16 GB *

900 to 2,000 hits per second

Medium

4 vCPU

16 GB

16 GB *

1,500 to 3,500 hits per second

High

8 vCPU

24 GB

16 GB *

2,500 to 7,500 hits per second

 

The analyzer vm has been tested against different resource allocations and it has been rated to handle the amount of traffic as mentioned in the chart above.  It should be mentioned that the chart above does not reflect all traffic scenarios. It is more of a guideline.  All deployments handle different volumes and density of web traffic.  If you have low number of hits but the traffic itself has very large cookies or other attributes that make it ‘fat’ the amount of hits per second that your analyzer will be able to process will decrease.  The hardware itself also has a huge effect on the amount of HPS (hits per second) it can handle.  Old CPU’s or RAM that run at a lower clock frequencies  will not be able to compete against newer processors and RAM that are rated to handle more  calculations or bytes per second.  A huge potential bottleneck for an analyzer is disk IO.  In order to store all of the hits that it is processing for the session browser, enough IO bandwidth is needed so as to not to delay processing while waiting to write to disk.  Another factor is analyzer configuration.  Custom field configurations, AIM and other configurations will also drain resources.

Best practices for Analyzer deployment:

CPU and RAM

If your traffic calls for 8 vCPU and 24GB of RAM to process your traffic and you are deploying on a host that has 8vCPU and 24GB of RAM, it is important to note that the Hyper-Visor will need to ‘steal’ some cpu and ram in order to run the vm.  It is best practice to deploy an Analyzer with 8vCPU and 24GB RAM requirements on a host that has more than the requirements of the VM – i.e.: 12vCPU and 32GB of RAM.

Reservation vs. Allocation:

The whole idea behind virtualization is to share resources and make the most of them. That being said, if you are using EUEM in a high traffic environment, it needs to have plenty of resources and waiting to get the resources needed can lead to a slow-down of the system.  If processing is needed to be as real-time as possible and the traffic rate is high, reserving the resources is the best practice.

Disk:

The Analyzer is very write intensive on its database. High IO bandwidth is needed in order not to cause back pressure on the processing of pages and objects in the form of ‘data delay’.  Best practices for the Disk are multi-disk Raid 10 with a large RAM cache on the controller card with a battery backup.  Multiply disk raid 10 provide more spindles for writing to and a fail-safe should one of the disk fail.  The large RAM cache on the controller card  provides high bandwidth IO for the large traffic spikes and the battery backup provides a safety measure should power loss occur.

 
Real User Collector:  The Collector hard drive requirement is 28GB.  It will never use more or less than 28GB.  The collector only uses 1 hard drive.  It can supply data to 12 different analyzers on the data it collects at one time.  It will store data for up to 2 hours or 1GB whichever threshold is hit first for each data feed.  The 2 hour time is dependent on a configuration on the analyzer.

 

Memory and CPU:

Size

Processor

Memory

Disk

Expected volume of traffic

Low

2 vCPU

8 GB

28 GB

900 to 2,000 hits per second

Medium

4 vCPU

16 GB

28 GB

1,500 to 3,500 hits per second

High

8 vCPU

24 GB

28 GB

2,500 to 7,500 hits per second

 

The collector vm has also been tested against the different resource allocations and it has been rated to handle the amount of traffic mentioned in the chart above.  There are many scenarios that can dictate the amount of traffic a collector can process. As in the case of the Analyzer, the hardware itself also has a huge effect on the amount of HPS (hits per second) it can handle.  Old CPU’s or RAM that run at a lower clock frequencies  will not be able to compete against newer processors and RAM that are rated to handle more  calculations or bytes per second. 

Other factors that can eat resources of the collector are the amount of traffic the collector must decrypt, the amount of traffic it receives that is not HTTP/HTTPS (this traffic has to processed in order to decide if it is HTTP/HTTPS or not).

A high amount of retransmits or a slow network can also lower the amount of HPS a collector can handle.

 

Best practices for Analyzer deployment:

CPU and RAM

The same rule goes when deploying a collector.  The Hyper-Visor host should have more than the resource being allocated to the VM itself. If resources are to be shared on a host with another vm such as the Analyzer, performance will decrease during higher peak traffic rates.

 

Reservation vs. Allocation:

The whole idea behind virtualization is to share resources and make the most of them. That being said, if you are using EUEM in a high traffic environment, it needs to have plenty of resources and waiting to get the resources needed can lead to a slow-down of the system.  If processing is needed to be as real-time as possible and the traffic rate is high, reserving the resources is the best practice.

The Collector is not IO intensive and does not have a requirement for a high IO bandwidth for disk.

 

Performance Analytics Engine:  The PAE 1st hard drive will only need to be 10GB in size.  A 2nd hard drive added to the vm or a share can be used for PAE storage.  Although there is no hard limit of the amount of analyzers that the pae can connect to for data collection, it is recommended that no more than 3 be analyzers be used to store data for the PAE that is using minimum requirements (shown in chart below).

 

Memory and CPU:

Size

Processor

Memory

Disk

Low

2 vCPU

4 GB

10 GB

Medium

4 vCPU

8 GB

10 GB

High

8 vCPU

24 GB

10 GB

 

 

When determining hardware requirements for a Performance Analytics Engine instance, use the following considerations in your estimates:

Typical disk throughput is 50 megabytes per second. However, depending on your traffic, the amount of content that you are capturing, and the number of custom fields that you have defined, daily throughput could range from 100 gigabytes to 1 terabyte.

 

Best practices for PAE deployment:

The PAE will work with minimum requirements but the amount of users accessing it to perform queries will determine the responsiveness of the query.  Disk IO is a major factor for PAE performance.  Although it is possible to add an NFS or CIFS share to store the data, it is recommended that you add storage by way of adding a 2nd hard drive to the PAE vm – even if this disk is on a share.  Part of the PAE operation is to determine when to roll data and determining this becomes more difficult on network shares.  Adding storage as a local hard disk allows for a quicker determination when to roll data (less cycles spent trying to figure this out).

 

 

How to adjust VM resources:

 

To reserve CPU and RAM for a VM:

Open up VSphere, locate and right click the vm you wish to modify the resources on and select edit settings:

 

edit vm.png

In the following window, select the Resources tab:

resource_Tab.png

 

You can adjust the amount of CPU to reserve by moving the slider bar to the right.  Moving it all the way means that your vm is guaranteed the amount of CPU’s assigned to it. The same method is used to reserve RAM – click the Memory Settings on left and adjust slider on right.

 

To increase the amount of CPU and RAM for a VM:

 

 

In order to add more CPU’s or Memory, you will first have to power off the VM.  Once powered off, you can edit the hardware properties by right clicking the vm (as described previous page – right click and select edit):

adjust CPU and Memory.png

 

Once you have selected Memory or CPUs, you can adjust on the right hand side (increase from 512 MB to desired amount)

When this is complete, power on the vm.