The number one Discovery complaint I hear is “scans are slow.” The number one cause is a MID Server in Frankfurt scanning a subnet in Singapore. Latency, not CPU, is your enemy.
Place MIDs by network proximity, not org chart
A MID Server should sit inside the broadcast domain — or at most one hop — from its scan targets. Cross-region scans through a corporate WAN add 80-200ms per SNMP roundtrip and Discovery makes hundreds per device.
The cluster-per-region pattern
For every distinct network region (datacenter, cloud VPC, branch office cluster), provision a MID Server cluster of at least two members. Use MID Server Capabilities to assign specific scan duties:
Cluster: us-east-prod
Members: mid-use-01, mid-use-02
Capabilities: Discovery, Service Mapping, IntegrationHub
IP Range: 10.40.0.0/16, 10.41.0.0/16The cluster lets you patch one node without losing coverage and lets the platform load-balance across them.
Right-size the JVM
Default MID heap is 1GB. For active Discovery on more than 5,000 CIs per cluster, raise to 4GB minimum and watch GC pauses. The relevant property in wrapper-override.conf:
wrapper.java.maxmemory=4096
wrapper.java.initmemory=2048Restart the MID, then check mid_server.log.metric for GC behavior.
Externalize the credentials store
Stop putting credentials in the platform. Use the Credentials API with an external vault (HashiCorp, CyberArk, Azure Key Vault) so credential rotation does not require a Discovery freeze. The MID resolves at scan time.
Watch the network, not the platform
The mid_server.log has request and response timing on every probe. Pull Probe sent and Result received pairs and bucket by IP block. Slow blocks tell you exactly which network path is the problem — and almost always it is a firewall doing deep packet inspection on SNMP.
What to do this week
Map every MID Server cluster to the IP ranges it scans. Anywhere a cluster is scanning across regions, file a ticket to stand up local MIDs. Discovery time will drop more than any platform tuning will deliver.
