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. |
26 |
|
27 |
This integrates Net::SNMP into AnyEvent: You can make non-blocking |
28 |
Net::SNMP calls and as long as other parts of your program also use |
29 |
AnyEvent (or some event loop supported by AnyEvent), they will run in |
30 |
parallel. |
31 |
|
32 |
Also, the Net::SNMP scheduler is very inefficient with respect to both |
33 |
CPU and memory usage. Most AnyEvent backends (including the pure-perl |
34 |
backend) fare much better than the Net::SNMP dispatcher. |
35 |
|
36 |
A potential disadvantage is that replacing the dispatcher is not at all |
37 |
a documented thing to do, so future changes in Net::SNP might break this |
38 |
module (or the many similar ones). |
39 |
|
40 |
This module does not export anything and does not require you to do |
41 |
anything special apart from loading it *before doing any non-blocking |
42 |
requests with Net::SNMP*. It is recommended but not required to load |
43 |
this module before "Net::SNMP". |
44 |
|
45 |
GLOBAL VARIABLES |
46 |
$AnyEvent::SNMP::MAX_OUTSTANDING (default: 50, dynamic) |
47 |
Use this package variable to restrict the number of outstanding SNMP |
48 |
requests at any point in time. |
49 |
|
50 |
Net::SNMP is very fast at creating and sending SNMP requests, but |
51 |
much slower at parsing (big, bulk) responses. This makes it easy to |
52 |
request a lot of data that can take many seconds to parse. |
53 |
|
54 |
In the best case, this can lead to unnecessary delays (and even |
55 |
time-outs, as the data has been received but not yet processed) and |
56 |
in the worst case, this can lead to packet loss, when the receive |
57 |
queue overflows and the kernel can no longer accept new packets. |
58 |
|
59 |
To avoid this, you can (and should) limit the number of outstanding |
60 |
requests to a number low enough so that parsing time doesn't |
61 |
introduce noticable delays. |
62 |
|
63 |
Unfortunately, this number depends not only on processing speed and |
64 |
load of the machine running Net::SNMP, but also on the network |
65 |
latency and the speed of your SNMP agents. |
66 |
|
67 |
AnyEvent::SNMP tries to dynamically adjust this number dynamically |
68 |
upwards and downwards. |
69 |
|
70 |
Note that you can use Net::SNMP::XS to speed up parsing of responses |
71 |
considerably. |
72 |
|
73 |
$AnyEvent::SNMP::MIN_RECVQUEUE (default: 4) |
74 |
$AnyEvent::SNMP::MAX_RECVQUEUE (default: 64) |
75 |
These values specify the minimum and maximum receive queue length |
76 |
(in units of one response packet). |
77 |
|
78 |
When AnyEvent::SNMP handles $MAX_RECVQUEUE or more packets per |
79 |
iteration it will reduce $MAX_OUTSTANDING. If it handles less than |
80 |
$MIN_RECVQUEUE, it increases $MAX_OUTSTANDING. |
81 |
|
82 |
This has the result of adjusting the number of outstanding requests |
83 |
so that the recv queue is between the minimum and maximu, usually. |
84 |
|
85 |
This algorithm works reasonably well as long as the responses, |
86 |
response latencies and processing times are the same size per packet |
87 |
on average. |
88 |
|
89 |
COMPATIBILITY |
90 |
This module may be used as a drop in replacement for the |
91 |
Net::SNMP::Dispatcher in existing programs. You can still call |
92 |
"snmp_dispatcher" to start the event-loop, but then you loose the |
93 |
benefit of mixing Net::SNMP events with other events. |
94 |
|
95 |
use AnyEvent::SNMP; |
96 |
use Net::SNMP; |
97 |
|
98 |
# just use Net::SNMP as before |
99 |
|
100 |
# ... start non-blocking snmp request(s)... |
101 |
Net::SNMP->session ( |
102 |
-hostname => "127.0.0.1", |
103 |
-community => "public", |
104 |
-nonblocking => 1, |
105 |
)->get_request (-callback => sub { ... }); |
106 |
|
107 |
snmp_dispatcher; |
108 |
|
109 |
SEE ALSO |
110 |
AnyEvent, Net::SNMP, Net::SNMP::XS, Net::SNMP::EV. |
111 |
|
112 |
AUTHOR |
113 |
Marc Lehmann <schmorp@schmorp.de> |
114 |
http://home.schmorp.de/ |
115 |
|