
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-23-2019 09:43 AM
As part of our due-diligence on deploying discovery across our environment, I am looking for situations where discovery scans have had a significant negative impact on network performance.
We will be deploying discovery even if there is a risk of it having a negative impact on network performance, but if there are known examples of problems that we could anticipate, we would like the opportunity to address those problems.
So if you know of circumstances and situations where discovery scans have a negative impact on network performance, I'd appreciate you commenting on this question.
Thanks,
Cody
Solved! Go to Solution.
- Labels:
-
Discovery
-
Multiple Versions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-23-2019 11:53 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-23-2019 09:57 AM
So, there's the mid server talking to the instance and the mid server talking to the targets.
There are two features that try to reduce the chatter between the mid and the instance:
- Caching of results, where the instance sends a hash of the results of the last run of this probe for this device. If caching is turned on for this probe, and the hashes match, the mid just reports that the result matches and no change gets reported.
- Post-processing, where a script is run on the mid server to boil the raw output down to a concise form.
These represent some significant improvement in data traffic over the last few years.
Since the traffic between mid and instance is over the WAN, this tends to be where the expensive bits are, so this is a good thing.
Traffic between the mid and the target does not get the benefits of these improvements, and tends to be chattier.
Most of the complaints I have heard have been customers trying to discover Windows when the mid is in one location and the target is in another connected by VPN. Those Windows protocols are quite chatty. (I believe that was WMI. I'm not sure if PowerShell is more parsimonious with the bits.)
So, you want to keep the mids on the same LAN with the targets for this reason and also to reduce the dropped packets for SNMP discovery which is more sensitive to loss.
I don't have details on bits per discovery per target handy, but empirically, it's enough to make customers complain when run over a WAN and not enough to make them complain over a LAN, and Windows is the worst offender when they do complain.
- Tim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-23-2019 11:53 AM
Discovery resource utilization https://docs.servicenow.com/bundle/london-it-operations-management/page/product/discovery/reference/...

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-29-2019 08:48 PM
To append these fine answers I’ll add my document around how to perform your own bandwidth testing. Based on the testing (not related to ServiceNow) I did around monitoring data collection via Mgmt protocols such as snmp/wmi/ssh va agent-based collection. This takes into account target device resources, source to target network congestion, and source to collection network/resource consumption. Hopefully it helps.