Repository navigation
Benchmark Sniffnet performance #489
Description
This issue wants to track the need for a benchmark to accurately measure the speed of the app, measured in packets per second (pps) that can be handled without dropping frames.
This is necessary to find out ways that can help improving the performance even further.
Today I tried testing Sniffnet with
iperfon a different machine and I could observe that the current packets per second limit is higher than 100k:
Originally discussed in #373
Reacted by ignoramous and Alexander Zaitsev
Activity
GyulyVGC commentedon Jul 11, 2025
Since the introduction of PCAP files import in version 1.4, we now have a more reliable and stable way of assessing the app performance without relying on Internet connectivity and network adapter speed limits.
It's in fact enough to import a large PCAP file and divide the total number of parsed packets by the time it takes to parse the file to obtain an accurate packet per second rate.
An example of this is shown in this blog post.
Update: and this is a video showing the same file of the blog post parsed by another computer of mine running a Debian distribution on a VM.
whole_day_fast.mp4
This mini PC is way faster than the PC I used for the blog post video.
PC & VM details
Beelink SER7 Mini-PC, Ryzen 7 7840HS (8C/16T, up to 5.1GHz) Mini Computer, AMD Radeon 780M, 32GB DDR5+1TB SSD Micro Desktop, Mini Gaming PC 4K Quad Displays HDMI+DP+Dual USB4, 2.5Gbps LAN, WiFi 6
As you can see it processes 2.6 million packets in just about 6 seconds, reaching a mad rate of more than 400k packets per second!
GyulyVGC commentedon Sep 9, 2025
Update: performance remains pretty much the same (around about 6 seconds to parse that file) even after #957.
GyulyVGC commentedon Nov 3, 2025
Update: no significant difference in performance even after #992.
shishir-cyber commentedon Aug 6, 2026
Hi @GyulyVGC, I'd like to work on this. I'm planning to add criterion as a dev-dependency and create a benches/parsing.rs benchmark.
Feed a sample PCAP file through the parsing path (the same one used for PCAP import) and measure packets-per-second, matching the metric you've been tracking manually. Use black_box to make sure the compiler doesn't optimize the parsing away. Wire it up so it's easy to re-run after future PRs.
Do you have a reference PCAP file you've been using (https://sniffnet.net/news/v1.4/), or should I generate/find one to check into the repo as a fixture? Also would you prefer the benchmark to isolate analyze_headers alone or measure the full parse_packets loop end to end.
GyulyVGC commentedon Aug 6, 2026
Hey @shishir-cyber thanks so much for your proposal
The file I used for the blog post is a couple Giga Bytes in size so we definitely don't want push it in the repo
Ideally I'd like to test the full path, the most complete the better
However at the same time I don't want to have to restructure much of the backend code to accommodate this.
Plus in the
ipfixbranch I'll probably change considerably the shape of the parsing method, so that's another reason why I'd like the processing backend not to change much just to accommodate benchmarksshishir-cyber commentedon Aug 6, 2026
@GyulyVGC Thanks for the context.
Since PCAP import is already a first class capture path, I can drive that same entry point with a small fixture file about a couple MBs. Criterion re-runs the benchmark body enough times to get stable pps numbers even from a small file, so no need for anything close to GB sized. Do you have a smaller capture you'd consider representative, or should I find one?
To keep ipfix safe, I'll have the benchmark call into the current parsing entry point rather than any internals, so if that branch reshapes things later, updating the benchmark should be a small, localized fix rather than a rewrite.
GyulyVGC commentedon Aug 6, 2026
Yes please it'd be amazing if you could avoid touching existing methods shape.
Concerning the PCAP file, feel free to use a stub for now.
Later I'll replace it with a file that contains all kinds of relevant traffic (IPv4, IPv6, ARP, TCP, UDP, ICMP)
shishir-cyber commentedon Aug 6, 2026
One thing I noticed, Sniffnet's currently a binary-only crate (everything's declared via mod in main.rs) and Criterion benches need a library target to link against. I'll add a minimal src/lib.rs that re-exports the existing modules, no function signatures or behavior change, main.rs just calls into it instead of declaring modules directly. I can take a different approach if you'd rather.
GyulyVGC commentedon Aug 6, 2026
You can start like that
I'll probably just postpone the PR review to a time I have less items in the backlog so the situation is more stable.
I'll probably tackle it along with the bigger integration test refactor I personally want to do later on
LoudiliMed commentedon Aug 14, 2026
Hi, I'd like to work on this. I have experience with network programming and systems benchmarking through Rézoleo (campus ISP) Could you point me to any existing benchmark setup or target metrics you have in mind? I'll start by profiling packet capture throughput
GyulyVGC commentedon Aug 16, 2026
Hey @LoudiliMed thanks for your interest in helping out.
I don't have any benchmark code for Sniffnet.
The focus would be around testing packet processing speed in number of packets per second.
I'd suggest to use
criterionfor benchmarking as @shishir-cyber previously mentioned in this discussion.As he said, main problem right now is that Sniffnet doesn't export methods to be called in a library-like style.
LoudiliMed commentedon Aug 17, 2026
Hey @GyulyVGC thanks for the context.
since sniffet isn't currently structured as a library, would it make sense to first refactor the packet-processing logic into a lib.rs so i can call it independently i can start there , then add criterion benchmarks on top once that's in place.
LoudiliMed commentedon Aug 17, 2026
i don't know if it's makes sense to you