White Papers

7 Benchmark the Performance, Reliability, and Scalability of Dell EMC OpenManage Enterprise 3.2 in your data
center environment
Internal Use - Confidential
1 Impact of hardware on the performance of OpenManage
Enterprise 3.2 in PowerEdge servers and MX7000 chassis
To optimize the setup and task schedule of your appliance, it is first necessary to understand how the
hardware may affect performance. The appliance does most of the processing and stores all the data, so
both the underlying hardware and the hardware allocated to the VM will be a limiting factor in the overall
performance. Hardware must be prioritized by using the following guidelines:
• Memory—This will be a gating factor to the number and size (in devices) of tasks which can be run
simultaneously. It is recommended to manually increase the RAM from the default—up to 32 GB—when
running a max scale configuration to allow more concurrent processes.
• CPU—The appliance has multiple services that are responsible for running distinctive tasks by using
different threads concurrently. Also, OpenManage Enterprise database activities are CPU–intensive.
Therefore, it is also recommended to add more cores for better performance.
• Network—Majority of functionality in OpenManage Enterprise is based on network interactions from the
appliance to devices. This information is then transmitted from the appliance to a client which is
accessing it over the network.
o Network speed—The speed of a network defines the responsiveness of appliance and its performance.
The time taken to execute a job depends on the available bandwidth and delay that exists in a network.
o Timeout—There are many different cases where network communication to the device may fail.
Depending on the nature of the failure, this may be noticeable in the task performance. Especially, if this
happens for many devices in the task (for example, for a discovery task). For a slower network or device,
it is recommended to increase the timeout and number of ‘retries’ for a discovery job. Possible scenarios
are listed here:
▪ Sparsely populated IP range in a discovery job—Define the discovery range more
granularly to avoid this. If it is possible, define a single discovery task with a list of IPs or
ranges.
▪ Discovery uses incorrect credentials—If the devices on your network must use different
credentials, it is required to split these into separate ranges with the appropriate credentials.
▪ Device malfunctions or the protocol is disabled—The task execution history may provide
some details about a failure. This may require actions on the device to resolve.
o Device actions—The time taken running different tasks—such as firmware update and configuration
inventory—depends on the server generation, hardware inventory, and selected components.
• Hard drive—The default drive space requirements are mentioned for specific tests covered for the purpose of this
technical white paper.
Overall, smaller scale configurations will have better performance, because they manage less data and will
generally have fewer scheduled tasks running at the same time.
Multiple tasks running together have additional constraints, complexity, or dependencies which may not be
immediately obvious but will impact performance numbers. The performance of OME for monitoring and
managing FIPS‒enabled iDRAC configuration (that have TLS 1.2 installed) is similar to the iDRACs that do
not have FIPS enabled.