7.2
Table Of Contents
- Reference Architecture
- Contents
- vRealize Automation Reference Architecture Guide
- Updated Information
- Initial Deployment and Configuration Recommendations
- vRealize Automation Deployment
- vRealize Business for Cloud Deployment Considerations
- vRealize Automation Scalability
- vRealize Business for Cloud Scalability
- vRealize Automation High Availability Configuration Considerations
- vRealize Business for Cloud High Availability Considerations
- vRealize Automation Hardware Specifications
- vRealize Automation Small Deployment Requirements
- vRealize Automation Medium Deployment Requirements
- vRealize Automation Large Deployment Requirements
- Index
Performance Analysis and Tuning
As the number of resources collecting data increases, data collection completion times might become longer
than the interval between data collection intervals, particularly for state data collection. To determine
whether data collection for a compute resource or endpoint is completing in time or is being queued, see the
Data Collection page. The Last Completed eld value might show In queue or In progress instead of a
timestamp when data collection last nished. If this problem occurs, you can increase the interval between
data collections to decrease the data collection frequency.
Alternatively, you can increase the concurrent data collection limit per agent. By default,
vRealize Automation limits concurrent data collection activities to two per agent and queues requests that
exceed this limit. This limitation allows data collection activities to nish quickly without aecting overall
performance. You can raise the limit to take advantage of concurrent data collection, but you must weigh
this option against overall performance degradation.
If you increase the congured vRealize Automation per-agent limit, you might want to increase one or more
of these execution timeout intervals. For more information about how to congure data collection
concurrency and timeout intervals, see the vRealize Automation System Administration documentation.
Manager Service data collection is CPU-intensive. Increasing the processing power of the Manager Service
host can decrease the time required for overall data collection.
Data collection for Amazon Elastic Compute Cloud (Amazon AWS), in particular, can be CPU intensive,
especially if your system collects data on multiple regions concurrently and if data was not previously
collected on those regions. This type of data collection can cause an overall degradation in Web site
performance. Decrease the frequency of Amazon AWS inventory data collection if it is having a noticeable
eect on performance.
Workflow Processing Scalability
The average workow processing time, from when the DEM Orchestrator starts preprocessing the workow
to when the workow nishes executing, increases with the number of concurrent workows. Workow
volume is a function of the amount of vRealize Automation activity, including machine requests and some
data collection activities.
This chapter includes the following topics:
n
“Congure Manager Service for High Data Volume,” on page 18
n
“Distributed Execution Manager Performance Analysis and Tuning,” on page 19
Configure Manager Service for High Data Volume
If you expect to use a VMware vSphere cluster that contains a large number of objects, for example, 3000 or
more virtual machines, modify the manager service cong le with larger values. If you do not modify this
seing, large inventory data collections might fail.
Modify the default value of the ProxyAgentServiceBinding and maxStringContentLength seings in the
ManagerService.exe.config le.
Procedure
1 Open the ManagerService.exe.config le in a text editor.
Typically, this le resides at C:\Program Files (x86)\VMware\vCAC\Server.
Reference Architecture
18 VMware, Inc.