On Mon, 19 Jul 2021, 20:28 Roberto A. Foglietta, < roberto.foglie...@gmail.com> wrote:
> I have been reported that the bottleneck is due to the single-thread > nature of SNMP. > The bottleneck is about 1 SNMP call served per second. > That sounds like asynchronous SNMP calls. The delay is due to the response time across the network. Do you anyone considered to have a multi-thread SNMP server? Just in case, > which kind of issues will be faced and how much effort it could require > such a porting? > So the answer is yes you could multi thread a bunch of synchronous SNMP senders. This is a terrible idea. If you use an asynchronous caller then the delay is basically how long it takes to create the PDU and punt it to the kernel socket before the next one can be started. This is Quite Fast. Not fast enough? Check your reply code, maybe whatever you are doing when you get the reply is taking the time. I didn't like how long RRD files took to update so I put that part into its own thread to make sure the reply side of the SNMP code was nice and fast with a simple IPC to a rrd update thread. If that is not fast enough then you can multi thread the Async code. I'm pretty sure you won't need this. BTW when you get to silly output levels you need to be careful not to smash the SNMP agent on the remote end. Most network equipment on the control plane uses bad CPUs and worse SNMP code (or the data handler) so your now mega fast SNMP query engine can overwhelm things or even crash them. Asynchronous code is tricky to write but it is possible. It's a matter of explicitly remembering what you have sent and what you will sent. Synchronous code is easy because your for loop is the "will sent" part and the single outgoing call is the "have sent" part. - Craig
_______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
