As per my understanding , one SNMP session can hold at max 31767 (PDU_MAX_RID - PDU_MIN_RID). so if i want to monitor more devices say 500 with around 30 scalar oids for every 60 sec.
I see SNMP++ takes more time on getting the request id for snmp request(asynchronous).
if i want to monitor then around 2000 devices , i feel one SNMP session can not handle so many requests.
Kindly let me know your thoughts of working around this limitation.
Your understanding of the request ID is not correct. If the maximum value is reached SNMP++ will use the minimum value again. Thus, there is no real limit. With the default implementation you can have 31000 concurrent (yet unresponded) requests. If you need more, you can overwrite the long Snmp::MyMakeReqId() and you run 2^31 concurrent requests.
additionally you could add more than one oid to each request. If you can get 10 (or even more) oids in one request you will greatly reduce the overhead. Just take care that the resulting size of the response will not get too big (around 1400 bytes) or the time for the agent to respond will not get too long to trigger a timeout.
Thanks for your reply. in case of V1 if i try to get value for more than one oid in one request, due to error handling logic of V1, i could not receive response for all oids even if one oid fails. but i agree in case of V2c and V3 it will be helpful to query multiple oids in one get request.
I think, that if your usage scenario will likely hit the 31000 outstanding async requests, you should use multiple Snmp sessions. I cannot say how many devices per Snmp session is the best for your use case, but if you (from your first post) see performance problems when you query 30 oids every minute from 500 devices, maybe 200 devices per session seems reasonable.