1 |
NAME |
2 |
AnyEvent::SNMP - adaptor to integrate Net::SNMP into AnyEvent. |
3 |
|
4 |
SYNOPSIS |
5 |
use AnyEvent::SNMP; |
6 |
use Net::SNMP; |
7 |
|
8 |
# just use Net::SNMP and AnyEvent as you like: |
9 |
|
10 |
# use a condvar to transfer results, this is |
11 |
# just an example, you can use a naked callback as well. |
12 |
my $cv = AnyEvent->condvar; |
13 |
|
14 |
# ... start non-blocking snmp request(s)... |
15 |
Net::SNMP->session (-hostname => "127.0.0.1", |
16 |
-community => "public", |
17 |
-nonblocking => 1) |
18 |
->get_request (-callback => sub { $cv->send (@_) }); |
19 |
|
20 |
# ... do something else until the result is required |
21 |
my @result = $cv->wait; |
22 |
|
23 |
DESCRIPTION |
24 |
This module implements an alternative "event dispatcher" for Net::SNMP, |
25 |
using AnyEvent as a backend. This integrates Net::SNMP into AnyEvent. |
26 |
That means you can make non-blocking Net::SNMP calls and as long as |
27 |
other parts of your program also use AnyEvent (or some event loop |
28 |
supported by AnyEvent), they will run in parallel. |
29 |
|
30 |
Also, the Net::SNMP scheduler is very inefficient with respect to both |
31 |
CPU and memory usage. Most AnyEvent backends (including the pure-perl |
32 |
backend) fare much better than the Net::SNMP dispatcher. |
33 |
|
34 |
Another major added feature of this module over Net::SNMP is automatic |
35 |
rate-adjustments: Net::SNMP is so slow that firing a few thousand |
36 |
requests can cause many timeouts simply because Net::SNMP cannot process |
37 |
the replies in time. This module automatically adapts the send rate to |
38 |
avoid false timeouts caused by slow reply processing. |
39 |
|
40 |
A potential disadvantage of this module is that replacing the dispatcher |
41 |
is not at all a documented thing to do, so future changes in Net::SNMP |
42 |
might break this module (or the many similar ones). |
43 |
|
44 |
This module does not export anything and does not require you to do |
45 |
anything special apart from loading it *before doing any non-blocking |
46 |
requests with Net::SNMP*. It is recommended but not required to load |
47 |
this module before "Net::SNMP". |
48 |
|
49 |
GLOBAL VARIABLES |
50 |
$AnyEvent::SNMP::MAX_OUTSTANDING (default: 50, dynamic) |
51 |
AnyEvent::SNMP::set_max_outstanding $new_value |
52 |
Use this package variable to restrict the number of outstanding SNMP |
53 |
requests at any point in time. |
54 |
|
55 |
Net::SNMP is very fast at creating and sending SNMP requests, but |
56 |
much slower at parsing (big, bulk) responses. This makes it easy to |
57 |
request a lot of data that can take many seconds to parse. |
58 |
|
59 |
In the best case, this can lead to unnecessary delays (and even |
60 |
time-outs, as the data has been received but not yet processed) and |
61 |
in the worst case, this can lead to packet loss, when the receive |
62 |
queue overflows and the kernel can no longer accept new packets. |
63 |
|
64 |
To avoid this, you can (and should) limit the number of outstanding |
65 |
requests to a number low enough so that parsing time doesn't |
66 |
introduce noticeable delays. |
67 |
|
68 |
Unfortunately, this number depends not only on processing speed and |
69 |
load of the machine running Net::SNMP, but also on the network |
70 |
latency and the speed of your SNMP agents. |
71 |
|
72 |
AnyEvent::SNMP tries to dynamically adjust this number upwards and |
73 |
downwards. |
74 |
|
75 |
Increasing $MAX_OUTSTANDING will not automatically use the extra |
76 |
request slots. To increase $MAX_OUTSTANDING and make |
77 |
"AnyEvent::SNMP" make use of the extra parallelity, call |
78 |
"AnyEvent::SNMP::set_max_outstanding" with the new value, e.g.: |
79 |
|
80 |
AnyEvent::SNMP::set_max_outstanding 500; |
81 |
|
82 |
Although due to the dynamic adjustment, this might have little |
83 |
lasting effect. |
84 |
|
85 |
Note that you can use Net::SNMP::XS to speed up parsing of responses |
86 |
considerably. |
87 |
|
88 |
$AnyEvent::SNMP::MIN_RECVQUEUE (default: 8) |
89 |
$AnyEvent::SNMP::MAX_RECVQUEUE (default: 64) |
90 |
These values specify the minimum and maximum receive queue length |
91 |
(in units of one response packet). |
92 |
|
93 |
When AnyEvent::SNMP handles $MAX_RECVQUEUE or more packets per |
94 |
iteration it will reduce $MAX_OUTSTANDING. If it handles less than |
95 |
$MIN_RECVQUEUE, it increases $MAX_OUTSTANDING. |
96 |
|
97 |
This has the result of adjusting the number of outstanding requests |
98 |
so that the recv queue is between the minimum and maximum, usually. |
99 |
|
100 |
This algorithm works reasonably well as long as the responses, |
101 |
response latencies and processing times are the same per packet on |
102 |
average. |
103 |
|
104 |
COMPATIBILITY |
105 |
This module may be used as a drop in replacement for the |
106 |
Net::SNMP::Dispatcher in existing programs. You can still call |
107 |
"snmp_dispatcher" to start the event-loop, but then you loose the |
108 |
benefit of mixing Net::SNMP events with other events. |
109 |
|
110 |
use AnyEvent::SNMP; |
111 |
use Net::SNMP; |
112 |
|
113 |
# just use Net::SNMP as before |
114 |
|
115 |
# ... start non-blocking snmp request(s)... |
116 |
Net::SNMP->session ( |
117 |
-hostname => "127.0.0.1", |
118 |
-community => "public", |
119 |
-nonblocking => 1, |
120 |
)->get_request (-callback => sub { ... }); |
121 |
|
122 |
snmp_dispatcher; |
123 |
|
124 |
SEE ALSO |
125 |
AnyEvent, Net::SNMP, Net::SNMP::XS, Net::SNMP::EV. |
126 |
|
127 |
AUTHOR |
128 |
Marc Lehmann <schmorp@schmorp.de> |
129 |
http://home.schmorp.de/ |
130 |
|