Conclusions
Here is the summary table for Gufo SNMP bencmarks.
| Test | Sync (ms) | Async (ms) | Async overhead |
|---|---|---|---|
| SNMPv2c GETNEXT | 215.17 | 273.66 | 27.18% |
| SNMPv2c GETBULK | 46.62 | 52.56 | 12.75% |
| SNMPv2c GETNEXT (x4) | 357.34 | 487.52 | 36.43% |
| SNMPv2c GETBULK (x4) | 155.51 | 185.20 | 19.09% |
| SNMPv3 GETNEXT | 242.40 | 289.18 | 19.30% |
| SNMPv3 GETBULK | 49.45 | 55.80 | 12.84% |
| SNMPv3 GETNEXT (x4) | 409.16 | 582.81 | 42.44% |
| SNMPv3 GETBULK (x4) | 12.77 | 20.42 | 59.89% |
Conclusions:
- Gufo SNMP is the clear winner in terms of performance.
- Async mode adds significant overhead to each I/O operation (~30%). This is especially noticeable in GETNEXT mode. We have to address this issue in future releases.
- GETBULK consistently outperforms GETNEXT. As expected, it delivers better performance and should be preferred whenever supported by the equipment.
- The encryption overhead of SNMPv3 (AES128 + SHA1) is minimal, with little impact on overall performance.
- Gufo SNMP demonstrates good scalability: running four parallel tasks takes only about 1.5× the time of a single task, indicating efficient performance even beyond Python’s GIL limitations.
- BER parsing is a complex algorithmic operation, so native CPU implementations provide significant performance gains.
- Purpose-tailored BER parsers that map directly to Python types offer substantial advantages over generic SNMP implementations.
- Complex abstractions are slow. A lean and efficient API is key to high performance.
- Wrappers over C-libraries may demonstrate an unexpected behaviour in multi-threaded applications.