Best Practices are methods of completing tasks, or tips that should be used based on a typical scenario.

When managing Device Sever configurations you should use the following best practices tips:

  • If your devices have spotty SNMP communications (due to device busy failures or other network traffic issues) set the retry count higher to compensate. To avoid unnecessary delays, you may want to set your timeout value lower.  

  • If your devices reliably send SNMP responses, then set the retry count to 0 or 1, but make sure to set the timeout value higher. This ensures reliable delivery of SNMP traffic in this environment.  

  • Setting your timeout and retry values too high causes long hangs and delays when devices physically are not responding.  

  • Setting your timeout and retry values too low causes successful SNMP communication to appear as though it has failed.  

  • If you typically send jobs to large numbers of devices simultaneously, setting the Maximum Threads configuration variable to a higher value allows your job to complete quicker.  

  • If you are worried about network or device traffic and Device Server performance, but are not concerned as much about the total length of time a large job takes to execute, then set the maximum threads to a smaller value.  

  • It is recommended to never set the maximum threads value to a value less than 5. Doing so could cause serious application performance degradation.  

  • To set the maximum threads value to a number greater than 20, carefully monitor the CPU, memory and disk performance of the Device Server to make sure you are not overloading the system. At peak times with maximum threads set high, system delays could cause thrashing and an overall performance degradation, along with an increase in timeout and related errors.  

  • Decreasing the config change delay increases the responsiveness the system has to changes in the system, at the potential cost of a larger number of revisions being stored when multiple changes are happening simultaneously. This can easily happen when a user is interactively changing the configuration on the device itself.  

  • Increasing the config change delay decreases the number of revisions being stored when multiple changes are happening simultaneously, but causes an increase in the delay before a changed configuration is stored in the repository.