Factors affecting performance

Performance figures are guidelines only and differ between environments. There are certain factors, configurable and otherwise that can affect performance. When scanning with BMC Discovery, the rate at which the IPs can be processed will vary depending on how many of them are actually devices, as opposed to empty space. For example, scanning a range of 100 IPs where only one is in use, will behave differently to scanning 100 IPs where there are 90 in use.

The following lists present a non-exhaustive catalog of factors which might affect the performance of BMC Discovery. The first list includes factors that you can configure to help improve performance. This is followed by a list of non-configurable factors.

Configurable performance factors

• Automatic grouping—Automatic grouping is enabled by default. The information provided by this feature is not often required, so it can be disabled. A reasonable performance improvement is seen when this feature is disabled. 
• IP optimization—Reducing the Scan Optimization Timeout will cause a degradation of appliance performance. This is because where a host has more than one IP address, some discovery is performed for each of those IP addresses.
• Concurrent discovery requests—The number of concurrent Discovery requests might impact performance in environments where the network is particularly slow to respond. See Configuring discovery settings for information about how to change this.
• DDD removal—If discovery (or consolidation) is in progress for most of the available time, contention might exist between the removal (aging out) of DDD nodes and the creation of new nodes. This can affect the performance of in-progress discovery runs. You can avoid this performance impact by scheduling times where the appliance is not scanning to coincide with DDD removal blackout windows when no DDD removal is undertaken. This provides time for the DDD removal activity to catch-up if necessary. See DDD removal statistics for more information.
• Log level—By default this is INFO. A log level of DEBUG will cause a degradation of appliance performance.
• Overlapping AD Windows proxy IPs—Where multiple Windows proxies scan the same range of IP addresses, an attempt will be made to login by each Windows proxy if no successful login has been achieved by any Windows proxy.
• Number of credentials—When scanning a machine for the first time, each credential that matches the IP address is attempted until one succeeds. The presence of many matching but incorrect credentials slows the initial discovery, and may potentially also trip intrusion detection systems. Once a credential has been used successfully for an IP address, it is remembered and tried first in future.
• Consolidation—If the appliance is configured as a scanning appliance and is sending data to one or more consolidation appliances then you can expect a performance drop of between 5 and 10%. See also the Consolidation Appliance notes on this page regarding the time taken for a Consolidation Appliance to consolidate data from multiple appliances.

Non-configurable performance factors

• Host complexity—Discovered hosts which are information-rich, and therefore more complex than those which contain less data, inevitably take longer to scan than simpler hosts. This might cause a degradation of appliance performance, particularly when a large contiguous block of large hosts is scanned.
• Types of patterns—Some patterns are more complex than others and take longer to run. Therefore, if your network includes a significant number of these complex patterns, it might increase the overall run time. Care should be taken when building custom patterns and applying them to BMC Discovery. If you have any questions on this matter, contact Customer Support.
• Responses from switches for non-routable IP addresses—Where any response is received for a scanned IP address, BMC Discovery assumes that there is an IP device at that address. If a switch is configured to send a response for a non-routable, or unassigned IP address, this might cause a degradation of appliance performance.
• Scan ordering—Where response time (including network latency) is an issue, this is not noticeable for individual isolated hosts. However, a contiguous block of slowly responding hosts or a high latency network segment can reduce performance noticeably. If all addresses have slow response times, then any performance degradation would be more noticeable.

Appliance performance

When deploying a BMC Discovery Appliance into your infrastructure, consider the following points:

• Disk I/O—When actively scanning, BMC Discovery places a heavy read and write load on the database. Consequently the performance of BMC Discovery benefits greatly from giving it the fastest disks possible; the slower your disk I/O, the slower BMC Discovery will be. As a rule of thumb, if you are spending money on infrastructure to support BMC Discovery, then choosing to spend it on fast storage first is a good strategy. For example:
  • Local Solid State Disks—SSDs local to the appliance are likely to be the fastest option. This is true for physical appliances as well as virtual appliances where the hypervisor's datastores map to SSDs that are local to the hypervisor.
  • Remote Storage Area Network—although likely to be slower than local SSDs, remote storage can be a good choice, assuming that the storage is close in network terms to the consuming appliance. Again SSDs will be faster than HDDs.
  • Local Hard Disk Drive—local HDDs are likely to be the cheapest, but also slowest option. If forced to use HDDs then always use the fastest possible.
• RAM—Ample RAM benefits BMC Discovery performance in at least three ways: 
  • Datastore cache—BMC Discovery will automatically adjust the amount of RAM used for the datastore cache.  Accessing data from the cache is much faster than reading it from disk. Faster datastore access means faster discovery as well as improved user interaction.
  • Reasoning—during discovery the reasoning sub-system holds large amounts of data in memory. Providing ample RAM to the BMC Discovery appliances avoids excessive disk swapping.
  • Improved disk I/O—the operating system of the appliance has many levels of I/O caching.  Increasing the available RAM can also benefit disk I/O performance.
• CPU—BMC Discovery automatically scales the number of ECA Engines based on the number of CPUs and RAM available. Provisioning multiple CPUs to the appliance allows for more parallelism during the discovery process.
• Avoid shared resources—All software systems suffer performance degradation when the resources they are trying to use, be that CPU, RAM or Disk, are shared with others. This is especially true for virtual appliances. By default, hypervisors share resources between all their hosted virtual machines, effectively overprovisioning capacity. From a resource efficiency perspective this is a good thing, but it can cause problems for performance. For maximum, predictable performance you should provision BMC Discovery virtual appliances with reserved resources, not shared with other Virtual Machines.

Consolidation Appliance 

As described in Consolidation, you can configure a BMC Discovery instance as a Consolidation Appliance that receives data from multiple Scanning Appliances. A Consolidation Appliance can process scan data at approximately the same rate as an equivalent Scanning Appliance can. Therefore, the time required to consolidate the data from all configured Scanning Appliances is approximately the same were you to add together the time taken by all Scanning Appliances to perform their scans. For example, if you had five Scanning Appliances each taking one hour to scan, then the corresponding Consolidation Appliance might take five hours to consolidate all this data. You must take this into account when planning your deployment as it is possible to end up in a situation where the Consolidation cannot keep up with the amount of data being sent to it by the Scanning Appliances.

A Consolidation architecture is intended for the purpose of scanning isolated network environments. It is not a scale solution. To use multiple BMC Discovery appliances together to achieve greater scale and performance, use a BMC Discovery Cluster deployment.