Pulse Hardware Sizing and Performance Information

This article describes the result of load testing performed using Pulse release 8.5.101 and serves as a guideline for Pulse capacity and resource usage. For a production deployment, you must test Pulse in your own environment under a production load to ensure its performance meets your expectations and is sized properly.

Architecture

• Each Pulse Collector can handle about 300K statistics with a 10 second refresh rate. The Collector adjusts the load based on the refresh rate.

Important

If you use change-based notifications for anything other than Agent Current State, you might have a significant number of notifications for each of these statistics per second. You must configure sensitivity appropriately and account for these additional notifications in sizing.

• If you use Pulse Collector Cluster configuration, the statistics are dynamically distributed across the Collectors in the cluster.

• Genesys recommends you have a dedicated Stat Server for each Pulse Collector. If you to have multiple Collectors for each Stat Server, contact Customer Care to evaluate your solution.

• Each Pulse Collector supports only a single connection to Stat Server (HA pair). All Stat Servers used for all Collectors in a cluster must be connected to the same sources (for example, T-Servers, SIP-servers, IXN-servers).

• Each Pulse plug-in can render the statistics and views across all Pulse Collectors in a cluster.

• You can have multiple Pulse Collectors for each GAX.

• Determine the number of GAX instances depending on number of concurrent users and numbers of Collectors depending on number of Stat Request notifications per second.

• For High Availability environments, you need a pair of Pulse Collectors to present a node.

• Pulse components (GAX, Pulse plug-in, Pulse Collector, Stat Server, DB Server) are operational in Site 1 (primary region) and Site 2 (failover region).

• The GAX and Pulse User Interface is normally accessed only in Site 1.

• Pulse in Site 2 can provide reports, but users only connect to the Site 2 if the failover from Site 2 is initiated.

• GAX and Pulse databases are replicated from Site 1 to Site 2 through a periodic backup and restore process.

• WebDav is used when GAX needs to pull snapshot data from Pulse Collector that is not installed on the local (same) host. Genesys supports Lighthttd http server with lighttpd-mod-webdav.

Generic Architecture Example

Environment Configuration

2 nodes Amazon AWS:

	vCPU	ECU	Memory (GiB)	Instance Storage (GB)
c3.8xlarge	32	108	60	2 x 320 SSD

Each node has cluster of 3 Pulse Collectors, 3 Stat Servers and 1 GAX instance

Collectors and Stat Servers are connected to each other in HA mode (1 Pulse Collector on each node is connected to Stat Server on same node and StatServer on another node).

Key performance impacting dimensions of the environment:

Widget and Statistic notification rate: 10sec

Important

Change based statistics (and quick updates feature of Pulse) are not used.
If you use change based statistics in your configuration (and they are not Agent State statistics) make sure you set sensitivity such that Stat Server sends notifications no more often than once a second.
Amount of Stat Server notifications with change based statistics can be unpredictable and be an order of magnitude greater than with time based so they must be carefully tuned (using sensitivity) and tested

Number of layouts (widgets) = 2400

Total Number of Statistics Requests to Stat Servers = Sum of (Number of Objects * Number of Stat) across all widgets = 1,740,000 (1.7M)
As result we get 1.7M notifications from Stat Servers every 10 seconds so 170K updates per second.

Pulse DB size is 31260672 bytes for ~ 2500 layouts so 12.5Kbytes per layout (widget)

 

This load was split between 3 Pulse Collectors/Stat Server pairs (in cluster)

Each Pulse Collector in cluster processed 800 layouts and consumed following:

• Memory (about 2K per statistic for 64bit version): up to 5GB
• CPU up to 800% (this means 8 cores)
• Bandwidth: ~1GBit/s between Pulse Collector and Stat Server (on the other node)

Important

Because Collector queues the messages that come from Stat Server the memory consumption above is achieved when there is no backlog - i.e Collector is able to process all layouts and save them as it gets the data.

If Pulse Collector cannot process all Stat Server messages it receives, it expands its memory size (use statistic-request-handling/max-stat-data-queue-size option to control it)

 

GAX resource consumption:

• Memory usage 9MB per logged in user session
• CPU usage peaks at 800% (8 cores)
• User with 5 widgets with refresh rate 10 sec (total sum of number of statisic * number of object in these widgets is 5781) receives about 600KB per minute (so average traffic is about 80Kbit/s).
• 1 GAX instance handled 200-300 concurrent users