| … | |
… | |
| 32 | |
32 | |
| 33 | Also, the Net::SNMP scheduler is very inefficient with respect to both CPU |
33 | Also, the Net::SNMP scheduler is very inefficient with respect to both CPU |
| 34 | and memory usage. Most AnyEvent backends (including the pure-perl backend) |
34 | and memory usage. Most AnyEvent backends (including the pure-perl backend) |
| 35 | fare much better than the Net::SNMP dispatcher. |
35 | fare much better than the Net::SNMP dispatcher. |
| 36 | |
36 | |
| 37 | Another major added fetaure of this module over Net::SNMP is automatic |
37 | Another major added feature of this module over Net::SNMP is automatic |
| 38 | rate-adjustments: Net::SNMP is so slow that firing a few thousand |
38 | rate-adjustments: Net::SNMP is so slow that firing a few thousand |
| 39 | requests can cause many timeouts simply because Net::SNMP cannot process |
39 | requests can cause many timeouts simply because Net::SNMP cannot process |
| 40 | the replies in time. This module automatically adapts the send rate to |
40 | the replies in time. This module automatically adapts the send rate to |
| 41 | avoid false timeouts caused by slow reply processing. |
41 | avoid false timeouts caused by slow reply processing. |
| 42 | |
42 | |
| 43 | A potential disadvantage of this module is that replacing the dispatcher |
43 | A potential disadvantage of this module is that replacing the dispatcher |
| 44 | is not at all a documented thing to do, so future changes in Net::SNP |
44 | is not at all a documented thing to do, so future changes in Net::SNMP |
| 45 | might break this module (or the many similar ones). |
45 | might break this module (or the many similar ones). |
| 46 | |
46 | |
| 47 | This module does not export anything and does not require you to do |
47 | This module does not export anything and does not require you to do |
| 48 | anything special apart from loading it I<before doing any non-blocking |
48 | anything special apart from loading it I<before doing any non-blocking |
| 49 | requests with Net::SNMP>. It is recommended but not required to load this |
49 | requests with Net::SNMP>. It is recommended but not required to load this |
| … | |
… | |
| 69 | case, this can lead to packet loss, when the receive queue overflows and |
69 | case, this can lead to packet loss, when the receive queue overflows and |
| 70 | the kernel can no longer accept new packets. |
70 | the kernel can no longer accept new packets. |
| 71 | |
71 | |
| 72 | To avoid this, you can (and should) limit the number of outstanding |
72 | To avoid this, you can (and should) limit the number of outstanding |
| 73 | requests to a number low enough so that parsing time doesn't introduce |
73 | requests to a number low enough so that parsing time doesn't introduce |
| 74 | noticable delays. |
74 | noticeable delays. |
| 75 | |
75 | |
| 76 | Unfortunately, this number depends not only on processing speed and load |
76 | Unfortunately, this number depends not only on processing speed and load |
| 77 | of the machine running Net::SNMP, but also on the network latency and the |
77 | of the machine running Net::SNMP, but also on the network latency and the |
| 78 | speed of your SNMP agents. |
78 | speed of your SNMP agents. |
| 79 | |
79 | |
| 80 | AnyEvent::SNMP tries to dynamically adjust this number upwards and |
80 | AnyEvent::SNMP tries to dynamically adjust this number upwards and |
| 81 | downwards. |
81 | downwards. |
| 82 | |
82 | |
| 83 | Increasing C<$MAX_OUTSTANDING> will not automatically use the |
83 | Increasing C<$MAX_OUTSTANDING> will not automatically use the |
| 84 | extra request slots. To increase C<$MAX_OUTSTANDING> and make |
84 | extra request slots. To increase C<$MAX_OUTSTANDING> and make |
| 85 | C<AnyEvent::SNMP> make use of the extra paralellity, call |
85 | C<AnyEvent::SNMP> make use of the extra parallelity, call |
| 86 | C<AnyEvent::SNMP::set_max_outstanding> with the new value, e.g.: |
86 | C<AnyEvent::SNMP::set_max_outstanding> with the new value, e.g.: |
| 87 | |
87 | |
| 88 | AnyEvent::SNMP::set_max_outstanding 500; |
88 | AnyEvent::SNMP::set_max_outstanding 500; |
| 89 | |
89 | |
| 90 | Although due to the dynamic adjustment, this might have little lasting |
90 | Although due to the dynamic adjustment, this might have little lasting |
| … | |
… | |
| 103 | When AnyEvent::SNMP handles $MAX_RECVQUEUE or more packets per iteration |
103 | When AnyEvent::SNMP handles $MAX_RECVQUEUE or more packets per iteration |
| 104 | it will reduce $MAX_OUTSTANDING. If it handles less than $MIN_RECVQUEUE, |
104 | it will reduce $MAX_OUTSTANDING. If it handles less than $MIN_RECVQUEUE, |
| 105 | it increases $MAX_OUTSTANDING. |
105 | it increases $MAX_OUTSTANDING. |
| 106 | |
106 | |
| 107 | This has the result of adjusting the number of outstanding requests so that |
107 | This has the result of adjusting the number of outstanding requests so that |
| 108 | the recv queue is between the minimum and maximu, usually. |
108 | the recv queue is between the minimum and maximum, usually. |
| 109 | |
109 | |
| 110 | This algorithm works reasonably well as long as the responses, response |
110 | This algorithm works reasonably well as long as the responses, response |
| 111 | latencies and processing times are the same size per packet on average. |
111 | latencies and processing times are the same per packet on average. |
| 112 | |
112 | |
| 113 | =back |
113 | =back |
| 114 | |
114 | |
| 115 | =head1 COMPATIBILITY |
115 | =head1 COMPATIBILITY |
| 116 | |
116 | |
