Problem
The two-frequency hot/cold probing strategy issues 1,600-2,000 HEAD requests per 30-minute cycle against the community-operated isocpp.org server. No benchmark or performance regression test exists for this cycle. The timing characteristics — total elapsed time, request distribution, concurrent connection count, error rates — exist only as runtime observations in production logs. There is no baseline measurement, no regression gate, and no way to detect whether a shift in cycle timing comes from a code change versus a server-side behavioral change. The concurrency cap (HTTP_CONCURRENCY=20) and overrun cooldown (POLL_OVERRUN_COOLDOWN_SECONDS=300) are tuned by feel rather than measurement.
Acceptance Criteria
Implementation Notes
Use pytest-benchmark or a lightweight custom harness. The mock server should simulate isocpp.org's response patterns (200 with Last-Modified, 404, connection delays). Focus on ISOProber.probe_all() as the entry point. The HTTP_CONCURRENCY and POLL_INTERVAL_SECONDS settings should be parameterizable in the benchmark. This work also partially addresses Compound-5 (Unobservable Probe Volume) by creating a quantitative baseline that survives contributor handoff.
References
Problem
The two-frequency hot/cold probing strategy issues 1,600-2,000 HEAD requests per 30-minute cycle against the community-operated isocpp.org server. No benchmark or performance regression test exists for this cycle. The timing characteristics — total elapsed time, request distribution, concurrent connection count, error rates — exist only as runtime observations in production logs. There is no baseline measurement, no regression gate, and no way to detect whether a shift in cycle timing comes from a code change versus a server-side behavioral change. The concurrency cap (
HTTP_CONCURRENCY=20) and overrun cooldown (POLL_OVERRUN_COOLDOWN_SECONDS=300) are tuned by feel rather than measurement.Acceptance Criteria
benchmarks/directory with a pytest-benchmark (or standalone timing harness) that exercises the probe cycle against a mock HTTP serverdocs/probe-performance.mdor README section: what's normal, what constitutes degradation, what thresholds warrant investigationImplementation Notes
Use
pytest-benchmarkor a lightweight custom harness. The mock server should simulate isocpp.org's response patterns (200 with Last-Modified, 404, connection delays). Focus onISOProber.probe_all()as the entry point. TheHTTP_CONCURRENCYandPOLL_INTERVAL_SECONDSsettings should be parameterizable in the benchmark. This work also partially addresses Compound-5 (Unobservable Probe Volume) by creating a quantitative baseline that survives contributor handoff.References