Optimize Collection Time
When a snapshot takes too long to collect, the fix is rarely a single setting. Use the Onboarding Dashboard to find which part of collection is slow, then apply the matching lever. This page maps dashboard signals to the settings that change them.
For the settings themselves, see Collection Concurrency and Rate Limits and Collection Settings.
Find the bottleneck
The Onboarding Dashboard is per-network. Open it and read these views before changing anything. Each row below names what to look at on the chart and how to read what you see.
| View | What to look at | How to read it |
|---|---|---|
| Collection History (Network onboarding overview) | The collection-duration trend over the last several snapshots. | A duration rising snapshot over snapshot means collection is slowing down — start there. A flat trend is a steady baseline for this environment; whether that baseline can be improved depends on the levers below. A single spike is likely a one-off. |
| Task Progress timeline (Collection Health → Task Progress) | The network concurrency-usage line over the run, and the per-jump-server concurrency lines. Hover a point to see its usage as a percentage of the configured limit. | A line near 100% of the limit (per the tooltip) for most of the run identifies concurrency as the constraint. A line well below the limit means the collector does not use the concurrency it has. |
| Slow commands (Collection Health → Collection details) | The list of commands above the time threshold (default 10 minutes; lower the threshold to surface more). | A handful of commands far above the rest set the total time. Many commands just over the threshold indicate broad device or network slowness instead. |
| Connectivity Status / Collection Status history (Collection Health) | When red (auth or connectivity failures) first spikes, and what changed around that date. | A spike that starts right after a settings or infrastructure change usually points back to that change — for example, a rate limit set too low. |
| Collector Exceptions (Collection Health → Collector Exceptions) | The exception domain, occurrence count, collector version, and impacted devices, with an expandable stack trace. | A high occurrence count concentrated on one device set tells you where collection is stalling rather than failing outright. |
The limit that the Task Progress tooltip measures usage against is the collector's Global connection concurrency, set on the collector's Settings tab (Platform → Collectors → click the collector). It caps how many devices the collector collects from at once. Hover the concurrency-usage line to read each point as a percentage of that limit. Three patterns are worth recognizing:
- Usage well below 100% with spare collector CPU and memory: the limit is not the constraint. Find what blocks collection — a slow source, or a jump server already at its own session limit — before you raise concurrency.
- Usage near 100% for most of the run: the Global connection concurrency cap is the constraint. Raise it whenever the collector's memory allows. Concurrency is a collector-resource decision; use rate limits, not a lower concurrency, to control load on shared infrastructure such as AAA servers.
- A few tasks running long after the rest finish: a handful of slow devices or commands set the total collection time, and concurrency is not the lever. Use the Slow commands view to identify them.
Match the symptom to a lever
| Symptom | Lever | Direction | Configure at |
|---|---|---|---|
| Concurrency underutilized, collector has headroom | Global connection concurrency | Raise | Collector → Settings |
| Collector CPU or memory pressure during collection | Global connection concurrency | Lower | Collector → Settings |
| AAA (TACACS / RADIUS) overloaded, false auth-failure spikes | Maximum device authentications / command authorizations | Lower | Organization collection settings → Limits |
| A few slow commands dominate the tail | Last resort: disabling a command affects model completeness — investigate with Forward support first | — | Identify them in the Slow commands view |
| Large RIB tables make per-device collection slow | Cap with Max number of routes, Required subnets, VRF filters — or, for Junos BGP, switch to BMP | Cap | Organization collection settings → Advanced → RIB |
| Per-device time dominated by sequential VRF or context walks | Extra connections per device | Raise | Organization collection settings → Advanced |
| vCenter is the slow step and the collector has memory | vCenter collection concurrency | Raise | Collector → Settings |
| Cloud API requests run one at a time, or the provider throttles them | Per-source maximum concurrent API requests, timeouts | Raise / Lower | Sources → Cloud setups |
| One jump server is weaker than the rest and slows collection | Maximum sessions, Maximum startups (for that server only) | Lower | Sources → Jump servers |
A few notes on the rows above:
- Collector CPU or memory pressure is not shown in the Onboarding Dashboard — judge it from the collector host itself (the VM's CPU and memory) or from out-of-memory entries in the Collector Exceptions view. If the collector is consistently under pressure, lowering Global connection concurrency relieves it, but contact Forward support to size the collector for the workload rather than running it pinned.
- Large RIB tables on Junos sourced from BGP have an alternative to capping: enable BMP. BMP collects BGP route data over a binary protocol instead of parsing CLI/SSH text output, which is significantly faster for very large routing tables. See Collecting with BMP.
Rate limits before concurrency
When the slow step is upstream load — AAA servers reporting rate-limit errors, device audit logs filling with failed-auth events — lower the authentication and command-authorization rate limits rather than collector concurrency.
The two controls do different things:
- Rate limits cap authentication and command traffic to network devices over time. They are the right lever for protecting TACACS, RADIUS, and other shared infrastructure.
- Collector concurrency caps how much work one collector runs in parallel. Its main job is managing the collector's own CPU and memory. It does affect upstream load indirectly — fewer devices in parallel means fewer simultaneous authentications — but only by throttling overall throughput, not by capping the request rate the way a rate limit does.
Lowering concurrency to relieve an overloaded AAA server is a blunt instrument: it reduces load only by slowing the whole snapshot, and the moment a burst of devices lines up it can still spike the server. A rate limit caps the request rate directly without sacrificing parallelism elsewhere. Set a rate limit instead.
Rate limits that are set too low slow collection without reducing the device count collected. Connectivity tests authenticate to a device several times in a short window, so an aggressive authentication limit can make them fail. Lower rate limits to protect infrastructure, then raise them again once collection is stable.
Source- and device-level levers
Some load is best controlled at the source rather than the collector:
- Prefer direct collection over jump servers — A direct collector-to-device connection collects faster than a jump server, which adds a hop and its own session limits. Collect a device directly when the collector can reach it, and use a jump server only when it is the device's only route.
- Jump servers — Per-jump-server Maximum sessions and Maximum startups cap load on that one jump server. In the Task Progress view, a jump server's concurrency line at its limit identifies that limit as the bottleneck — raise it when the jump server has capacity. (Task Progress plots concurrency usage against the configured limit; it does not report the jump server's own CPU or load.) Lower these limits in the opposite case: when one jump server is older or weaker than the rest, lower Maximum sessions or Maximum startups for that server alone rather than throttling collection across every jump server. See Jump Servers.
- Cloud accounts — AWS, Azure, GCP, NSX-T, Velocloud, and Meraki expose per-source Maximum concurrent API requests (AWS, Azure, and GCP also expose API timeouts). Raise concurrency when the collector has spare capacity but collects each account's resources one at a time; lower it when the provider returns throttling errors.
- vCenter — Collection defaults to one operation at a time per collector because the vCenter collection libraries are memory-heavy. Raise vCenter collection concurrency only when the collector VM has the memory for it.