Hi,
We are having an issue with RTEs during polling of SNMP data due to the size of the system/distance of the device to the hub. To provide a little context to our issue, we made the move from native DataMiner polling to Qaction polling to improve performance, while speed has improved, we are now running into an issue with RTEs. Obviously, the improved polling time is desirable but not at the expense of RTEs within the system. What actions can we take to have a solution that will prevent RTEs regardless of system size or distance? Currently, we are requesting 40 cells per call and setting 1000 rows at a time within the table but the obvious flaw there is we attempt everything within one process.
A solution we had in mind is to split the calls up in chunks(Buffering/Queueing) base on a time limit where a stopwatch will run until it hits a certain time e.g. 12 mins it will then exit that process and reenters to poll the remaining data if it exists. This is the classic way of dealing with large data sets, the only drawbacks with be managing the queue and making sure an infinite loop does not occur. We are open to any other options that might be more efficient.
Thank You
Hi Aldrick,
Instead of doing this time based have you considered to poll the data in chunks of for example 100 rows (this is just an example) at a time?
The main drawback to your current implementation is that it blocks your entire protocol flow as long as this polling is ongoing (assuming it’s triggered from poll groups/timer). If we poll a large SNMP table using the built-in functionality (not via a QAction), then we can use the partialSNMP option which allows sets to be done in between the snmp polling. This is missing in your current implementation and could be improved by polling the data in batches of x rows and triggering the next batch via a poll group again. This does imply indeed that you implement a Queue to keep track of what still needs to be polled.
Another option is to use a queued QAction that can run for a longer time without RTEs (as the main reason you have RTEs is the time the QAction has to run and this one is cleared once all polling is done). However, I wouldn’t advise doing this.
OK perfect, the approach with setting 100 rows seems like the best approach.