Skip to content

Avoid formatting discarded scan errors - #950

Draft
bee-san wants to merge 2 commits into
masterfrom
perf/scan-error-handling
Draft

bee-san wants to merge 2 commits into
masterfrom
perf/scan-error-handling

Conversation

@bee-san

@bee-san bee-san commented Oct 1, 2026 •

Copy link
Copy Markdown
Owner

Closed and timed-out TCP probes format several discarded strings even with debug logging disabled. This change retains the original I/O error and only adds target context for enabled diagnostics. Descriptor exhaustion uses Unix/Winsock error codes instead of formatting and lowercasing OS messages.

Performance status

Draft: the strict no-slowdown condition is still not established across platforms. This version is based directly on merged Tokio master b7119f7f3eb1601e81126ef3572699ed7b3b7c0b. UDP probe, socket and timeout code is unchanged. It no longer depends on #949 or the closed Tokio alternatives.

The previous version on the alternative runtime saved 6–8% on closed-port TCP, but slowed UDP echo by 3.5–4%. That is why this remains a draft. The CI comparison now includes open-only TCP and UDP scenarios using the existing listeners, with extra repeated samples for the short UDP case. A passing broad CI threshold alone will not establish a universal speedup.

Implementation

  • Do not format or collect discarded diagnostics when debug logging is disabled or the existing message limit is full.
  • Keep debug error details and deduplication by message/IP.
  • Detect EMFILE/ENFILE on Unix and WSAEMFILE on Windows; preserve the fatal-error message.
  • Declare libc and windows-sys 0.59 directly; both versions were already in master’s lockfile. No package version changes.
  • Preserve retries, scan scheduling, result reporting, port preparation and all UDP probe behavior.

Simplification: the original draft’s UDP changes and runtime migration are removed; the diagnostic helper owns only error context and collection.

Validation so far

  • cargo test --locked scanner::errors: all 6 network-free tests passed. Disabled/full diagnostics never format discarded errors; enabled diagnostics retain details, deduplicate, and detect descriptor exhaustion by OS code.
  • cargo fmt --check and git diff --check: passed.
  • Network-free harness assertions: open-only scenarios count sockets and expected listeners correctly on Linux/macOS/Windows.
  • cargo test --locked: 79 passed, zero failed; one pre-existing ignored doctest.
  • cargo clippy --locked --all-targets -- --deny warnings: passed.
  • cargo doc --locked --workspace --all-features --no-deps --document-private-items: passed.
  • Full hosted test matrix: Linux x86_64, ARM64, macOS and Windows all passed for head 5ceb72882f2584763904fbf04f7652bf2a96fa57.
  • Matched release scan benchmark: all four jobs passed on the current head; 1,584 comparative invocations, zero failures and zero correctness mismatches. Runs are interleaved, with 9 samples per build/scenario, 27 for one-port/open-only TCP and 81 for open-only UDP. Raw durations, CPU, memory, descriptors and threads are in the workflow artifacts.

Previous benchmark evidence remains available for comparison; it is not evidence for the current Tokio implementation.

Current Tokio benchmark results

Scan-timer medians against b7119f7 in the same runner, release/LTO. Negative means less time:

Workload Linux x86_64 Linux ARM64 macOS Windows
TCP sweep, default batch -3.85% -5.39% +7.47% -0.28%
TCP sweep, batch 500 -3.68% -5.82% -34.18% +0.01%
TCP sweep, batch 10,000 -2.98% -4.73% +6.28% +0.49%
TCP open listeners only -0.69% +0.14% -16.12% +0.79%
UDP echo responders only +0.17% +0.50% +0.91% +0.16%
UDP sweep -4.90% +0.03% -2.12% -1.02%

The Linux TCP gain is consistent across batch sizes. The earlier 3.5–4% UDP slowdown did not recur in this 32-responder workload, but it is a different fixture from the earlier 256-responder workload. Windows differences are small. macOS varied widely: default TCP baseline samples ranged from 0.853 to 3.927 s and candidate samples from 0.945 to 1.853 s. Its paired uncertainty spans both improvement and slowdown, so these medians do not justify claiming a universal speedup or a clean no-slowdown result. This PR therefore remains a draft; the independently validated startup and port-preparation changes are #949 and #954.

@bee-san
bee-san marked this pull request as draft October 1, 2026 18:21
@bee-san
bee-san force-pushed the perf/lazy-dns-resolver branch from 5c88b77 to b0dedb6 Compare October 2, 2026 09:36
@bee-san
bee-san changed the base branch from perf/lazy-dns-resolver to master October 2, 2026 09:44
@bee-san
bee-san force-pushed the perf/scan-error-handling branch from 22fe44c to 5ceb728 Compare October 2, 2026 09:44

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant