chore: initial sanitized public snapshot
This commit is contained in:
Aria2 Rust Pro Contributors
@@ -0,0 +1,283 @@
|
||||
# Optimization Ranking
|
||||
|
||||
This file is the current Phase 6 ranking for `aria2-rust-pro` Take 2.
|
||||
|
||||
It is intentionally evidence-first. Each item below exists because current
|
||||
benchmarks, size reports, or runtime traces show a real remaining cost or a
|
||||
real verification gap.
|
||||
|
||||
## Current Ranking
|
||||
|
||||
### 1. Shared-runtime live HTTP fixed cost
|
||||
|
||||
Why it ranks first:
|
||||
|
||||
- this is the hottest still-open product path inside the current Phase 6 work
|
||||
- it already has multiple real wins landed in Take 2
|
||||
- the latest product-side scheduler change removed the previous loose-cap/cache
|
||||
pressure cliff, so remaining work is now narrower fixed-cost work rather than
|
||||
broad fanout underutilization
|
||||
- it is still the clearest place where a product-side win can move the current
|
||||
benchmark surface
|
||||
|
||||
Current evidence:
|
||||
|
||||
- after the latest scheduler and writeback pass, focused Criterion runs now
|
||||
land at:
|
||||
- `loose_cap`: `23.429 .. 23.998 ms`
|
||||
- `tight_cap`: `23.592 .. 24.049 ms`
|
||||
- `tight_cap_6way`: `26.089 .. 26.510 ms`
|
||||
- `cache_pressure_6way_256k`: `20.255 .. 21.380 ms`
|
||||
- after the later CLI config-projection cleanup, exact reruns kept the same
|
||||
`tight_cap` band and pushed the current shared-runtime `6way` absolute band
|
||||
materially lower:
|
||||
- exact `tight_cap`: `23.224 .. 23.603 ms`
|
||||
- exact `tight_cap_6way`: `13.422 .. 13.824 ms`
|
||||
- after the latest small-segment probe and admitted-download segment-budget
|
||||
pass, the current focused shared-runtime band moved again:
|
||||
- `loose_cap`: `12.567 .. 13.399 ms`
|
||||
- `tight_cap`: `12.674 .. 13.071 ms`
|
||||
- `tight_cap_6way`: `13.773 .. 14.212 ms`
|
||||
- `cache_pressure_6way_256k`: `7.793 .. 8.019 ms`
|
||||
- the later broader short bench-surface refresh kept that band and improved it
|
||||
slightly:
|
||||
- `loose_cap`: `11.696 .. 11.935 ms`
|
||||
- `tight_cap`: `11.732 .. 11.957 ms`
|
||||
- `tight_cap_6way`: `12.649 .. 12.855 ms`
|
||||
- `cache_pressure_6way_256k`: `7.137 .. 7.452 ms`
|
||||
- Criterion reports significant improvement in all four shared-runtime lanes:
|
||||
- `loose_cap`: roughly `-7.2% .. -3.4%` wall time
|
||||
- `tight_cap`: roughly `-4.4% .. -1.6%` wall time
|
||||
- `tight_cap_6way`: roughly `-31.9% .. -29.3%` wall time
|
||||
- `cache_pressure_6way_256k`: roughly `-14.9% .. -9.5%` wall time
|
||||
- the new result is a product-path Phase 6 win: runtime now recognizes the
|
||||
upstream-compatible `max-concurrent-downloads` surface, does not throttle
|
||||
already-registered same-runtime HTTP bootstrap work through the smaller
|
||||
active-download queue value, uses even worker partitioning instead of
|
||||
under-filling workers on `6 / 5` style workloads, and collapses segment
|
||||
dispatcher writeback to the final response per download
|
||||
- before that fix, the loopback driver imposed a serialized service-side floor
|
||||
near `96 ms` / `192 ms` because one server worker processed `12` / `24`
|
||||
range requests one at a time with an `8 ms` synthetic response delay
|
||||
- direct timing with `ARIA2_RUST_PRO_HTTP_TIMING=1` showed that, in the shared
|
||||
runtime live HTTP path, the dominant remaining fixed cost was in
|
||||
request/connection/send rather than dispatcher writeback
|
||||
- the same timing probe also confirmed that bootstrap/segment
|
||||
`record_http_transfer_result` work is currently `0 ms` on this host in the
|
||||
hot shared-runtime lane, so further wins need to come from request shape or
|
||||
transport cost rather than from more dispatcher-writeback trimming
|
||||
- the latest exact `tight_cap_6way` timing rerun now shows the hot small-file
|
||||
shared-runtime lane completing all six downloads in the bootstrap request
|
||||
alone:
|
||||
- `planned_segments=0` for every download
|
||||
- `bootstrap_persist_ms=0`
|
||||
- `bootstrap_record_ms=0`
|
||||
- per-request `send_ms` is now typically `10 .. 11 ms` on top of the driver
|
||||
`8 ms` response delay
|
||||
- that means the previous app-side bookkeeping cliff is gone in this lane; the
|
||||
remaining cost is now mostly transport-side send/response floor rather than a
|
||||
large remaining dispatcher or persistence tax
|
||||
- after the latest writeback and segment-tag cleanup, targeted reruns from the
|
||||
current tree show the larger segmented/cache-pressure lane is back in the
|
||||
fast band and the small 6-way lane improves again:
|
||||
- `tight_cap_6way`: `13.008 .. 13.228 ms`
|
||||
- `cache_pressure_6way_256k`: `7.819 .. 7.988 ms`
|
||||
- after the latest reqwest prepared-request contention pass, focused exact
|
||||
reruns stay in the same fast band while trimming one more product-path fixed
|
||||
cost in the shared-runtime connector hot path:
|
||||
- `tight_cap_6way`: mean about `13.117 ms`
|
||||
- `cache_pressure_6way_256k`: mean about `7.900 ms`
|
||||
- root cause for that pass: in concurrent shared-runtime small-file bursts, the
|
||||
private prepared-request cache could become mostly contention cost because
|
||||
many one-shot URI shapes fought over the same mutex before any real reuse
|
||||
existed
|
||||
- the current connector now treats prepared-request caching as opportunistic:
|
||||
repeated shapes still reuse cached URL/header preparation when the lock is
|
||||
available, but contended callers fall back to local uncached preparation
|
||||
instead of blocking on the cache mutex
|
||||
- this pass specifically addresses the broader segmented workload instead of
|
||||
spending more time on the already near-floor no-follow-up small-file path
|
||||
|
||||
Already-landed wins in this lane:
|
||||
|
||||
- shared default reqwest client reuse for no-proxy traffic
|
||||
- initial probe widened from `bytes=0-0` to the first real segment span
|
||||
- tiny post-probe tails that would previously fan out into three one-alignment
|
||||
follow-up requests are now coalesced into two larger follow-up requests
|
||||
- small-alignment segmented transfers now let the initial range probe cover two
|
||||
complete `max-connection-per-server` windows, reducing real follow-up range
|
||||
request count for small live HTTP transfers
|
||||
- shared-runtime segment fanout now budgets against already-admitted downloads
|
||||
rather than reusing the smaller active-download queue cap after admission
|
||||
- the live reqwest connector now also raises its same-host idle connection
|
||||
budget, keeps idle range-transfer connections warm for short bursts, and
|
||||
enables TCP keepalive; the broader bench-surface rerun kept live HTTP lanes
|
||||
fast after this connector change
|
||||
- `max-concurrent-downloads` is now part of the compat option registry and
|
||||
runtime projection, with an upstream-compatible default of `5`
|
||||
- small static HTTP work sets are partitioned evenly across available workers
|
||||
instead of using contiguous chunks that can under-fill the thread set
|
||||
- shared-runtime follow-up records now update dispatcher state once per
|
||||
download from the final segment response, instead of once per range response
|
||||
- direct URI dispatcher registration
|
||||
- incremental verified-prefix writeback
|
||||
- shared-runtime follow-up dispatch through one connection-budgeted segment
|
||||
batch
|
||||
- no-clone first-attempt retry fast path
|
||||
- concurrent loopback segment-server handling in the Criterion suite, which
|
||||
prevents synthetic service-side serialization from hiding client/runtime
|
||||
concurrency
|
||||
- shared-runtime follow-up segments now execute through one batched fanout based
|
||||
on active downloads and `max-connection-per-server`, instead of spawning
|
||||
nested per-download segment workers during bootstrap preparation
|
||||
- live streamed response sinks no longer perform an explicit file flush after
|
||||
every `reqwest::blocking::Response::copy_to`; write/copy errors are still
|
||||
surfaced, while range-heavy live transfers avoid a repeated per-response
|
||||
writeback tax
|
||||
- shared-runtime segment batches now carry the download index as the tag and
|
||||
store each segment target path once per download, removing one `PathBuf` clone
|
||||
per planned segment and reducing batch-result allocation churn
|
||||
- reqwest prepared live-request caching now falls back to local request
|
||||
preparation when the shared cache lock is contended, which keeps repeated
|
||||
range-request reuse available without forcing one-shot concurrent request
|
||||
bursts to wait on the cache mutex
|
||||
|
||||
Explicitly not counted as a measured shared-runtime win yet:
|
||||
|
||||
- proxy-specific reqwest clients are cached by proxy config, but there is still
|
||||
no dedicated proxy-path benchmark proving its standalone impact; keep it as
|
||||
sensible hot-path cleanup rather than counting it as ranked measured evidence
|
||||
|
||||
What still looks promising:
|
||||
|
||||
- lower per-request request/connection/send overhead
|
||||
- more disciplined validation of where blocking reqwest still pays fixed cost
|
||||
- only product-path reductions, not benchmark-only cosmetics
|
||||
|
||||
What has already been tried and rejected:
|
||||
|
||||
- forcing shared-runtime follow-up parallelism to honor the global overall cap
|
||||
regressed the lane by about `9% .. 10%`
|
||||
- swapping the local worker batches to rayon did not produce a meaningful win
|
||||
- leaking prepared-request state into the public `HttpRequestModel` was rejected;
|
||||
the kept version confines reqwest-specific URL/header preparation cache state
|
||||
to `ReqwestHttpConnector`
|
||||
|
||||
### 2. Binary size pressure from the RPC + HTTP/TLS stack
|
||||
|
||||
Why it ranks second:
|
||||
|
||||
- size evidence is now in-tree and clearly points at one dominant cluster
|
||||
- the current binary is already smaller than both the checked C++ Pro Core and
|
||||
the upstream Windows binary, so this is no longer emergency work
|
||||
- there is still a clear future size lane, but it is less urgent than the live
|
||||
shared-runtime HTTP hot path
|
||||
|
||||
Current evidence:
|
||||
|
||||
- current Windows Rust binary: `4.94 MiB` (`5,184,512` bytes)
|
||||
- current checked upstream Windows aria2 binary: `5.39 MiB`
|
||||
- current checked C++ Pro Core binary: `10.88 MiB`
|
||||
- top `cargo bloat --crates` buckets are:
|
||||
- `aria2_rust_pro_rpc`
|
||||
- `reqwest`
|
||||
- `rustls`
|
||||
- `std`
|
||||
- `aria2_rust_pro_protocol`
|
||||
|
||||
Interpretation:
|
||||
|
||||
- deeper size work should focus on the combined RPC + HTTP/TLS surface
|
||||
- one recent owned-code win already landed inside the CLI bucket by replacing
|
||||
repeated config `BTreeMap<String, String>` materialization with direct
|
||||
last-wins directive lookup, which notably shrank
|
||||
`derive_http_session`, `derive_runtime_config`, and
|
||||
`build_ftp_transfer_parts`
|
||||
- current CLI-side LLVM IR evidence is refreshed at `53,272` total lines across
|
||||
`307` function copies, down from the older `59,204` / `320` snapshot
|
||||
- this is now a ranked future optimization lane, not a closure blocker by
|
||||
itself
|
||||
|
||||
### 3. RPC pressure guard depth
|
||||
|
||||
Why it ranks third:
|
||||
|
||||
- current synthetic RPC responsiveness evidence now covers both a deterministic
|
||||
integration guard and Criterion pressure anchors
|
||||
- this remains a ranked lane because the workload is still synthetic and should
|
||||
not be overclaimed as a public-swarm certification
|
||||
- it is no longer an immediate Phase 6 evidence blocker
|
||||
|
||||
Current evidence:
|
||||
|
||||
- the current pressure guards:
|
||||
- repeated `tellStatus`
|
||||
- sampled `getFiles`
|
||||
- repeated `tellActive`
|
||||
- repeated `tellGlobalStat`
|
||||
- BT-like synthetic runtime churn
|
||||
- the denser mixed guard now covers 96 BT-like magnet tasks over 6 rounds,
|
||||
including 576 `tellStatus` calls and 72 sampled `getFiles` calls under
|
||||
per-download runtime tick churn
|
||||
- current Criterion anchors include:
|
||||
- `rpc_mixed_pressure/mixed_rpc/96`: `92.383 us`
|
||||
- `rpc_mixed_pressure/mixed_rpc/192`: `175.169 us`
|
||||
- `bt_visibility_pressure/bt_visibility/32`: `2.3293 ms`
|
||||
- `bt_visibility_pressure/bt_visibility/64`: `2.1302 ms`
|
||||
- the current guard is documented in `rpc-pressure-evidence.md`
|
||||
- that document explicitly says the thresholds are broad and not a final
|
||||
performance certification
|
||||
|
||||
Needed future expansion:
|
||||
|
||||
- higher scheduler pressure
|
||||
- clearer resource counters suitable for long-term perf reporting
|
||||
|
||||
### 4. Same-host comparison noise and interpretation discipline
|
||||
|
||||
Why it still matters:
|
||||
|
||||
- the local comparison report is now useful and much less misleading than it
|
||||
used to be
|
||||
- but it is still a whole-process host-local comparison, not a precision
|
||||
microbenchmark
|
||||
|
||||
Current evidence:
|
||||
|
||||
- `local-comparison.md` now reports medians and spread after warmup
|
||||
- the driver no longer suffers from coarse accept/sleep quantization
|
||||
- the Rust rows now complete with matching payload size and SHA256
|
||||
|
||||
Interpretation:
|
||||
|
||||
- this report is good enough to act as a local regression anchor
|
||||
- it should not be overclaimed as precise proof for micro-optimizations
|
||||
|
||||
## Current Phase 6 Read
|
||||
|
||||
What is already true:
|
||||
|
||||
- benchmark evidence exists
|
||||
- size/bloat evidence exists
|
||||
- multiple real product-side wins are already landed and documented
|
||||
- the current hottest open lane is identified and ranked
|
||||
- non-HTTP RPC and BT-visibility pressure now have current deterministic and
|
||||
Criterion evidence
|
||||
- the Phase 6 shared-runtime loose-cap/cache cliff is fixed by product code,
|
||||
not by benchmark-only masking
|
||||
- current broader bench, bloat, binary-size, and LLVM-lines evidence are now
|
||||
synchronized with the latest Phase 6 tree
|
||||
|
||||
What is not yet honest to claim:
|
||||
|
||||
- that the shared-runtime live HTTP lane is fully exhausted
|
||||
- that size work is fully exhausted
|
||||
- that the current RPC pressure guard is a public-network performance
|
||||
certification
|
||||
|
||||
## References
|
||||
|
||||
- `progress.md`
|
||||
- `docs\perf\local-comparison.md`
|
||||
- `docs\perf\rpc-pressure-evidence.md`
|
||||
- `docs\perf\size-evidence.md`
|
||||
Reference in New Issue
Block a user