Skip to content

Comments

fix(throughput): use fractional lookback divisor#78

Merged
shikhar merged 1 commit intomainfrom
fix-throughput-fractional-lookback-72
Feb 19, 2026
Merged

fix(throughput): use fractional lookback divisor#78
shikhar merged 1 commit intomainfrom
fix-throughput-fractional-lookback-72

Conversation

@shikhar
Copy link
Member

@shikhar shikhar commented Feb 19, 2026

Summary

  • compute SlidingThroughput::bps using lookback.as_secs_f64().max(1.0) for the divisor to preserve fractional lookback precision
  • keep bucket selection logic unchanged by continuing to use whole-second bucket counts
  • add a regression test for a 1.5s lookback to prevent throughput overestimation regressions

Testing

  • cargo +nightly fmt
  • cargo clippy --all-features --all-targets -- -D warnings --allow deprecated
  • cargo nextest run

Closes #72

@shikhar shikhar merged commit d5c8398 into main Feb 19, 2026
5 checks passed
@shikhar shikhar deleted the fix-throughput-fractional-lookback-72 branch February 19, 2026 05:03
@github-actions github-actions bot mentioned this pull request Feb 19, 2026
shikhar pushed a commit that referenced this pull request Feb 19, 2026
## 🤖 New release

* `cachey`: 0.10.0 -> 0.10.1

<details><summary><i><b>Changelog</b></i></summary><p>

<blockquote>

##
[0.10.1](0.10.0...0.10.1)
- 2026-02-19

### Fixed

- *(throughput)* use fractional lookback divisor
([#78](#78))
- *(object_store)* prioritize client-ordered buckets and correct decay
([#76](#76))
</blockquote>


</p></details>

---
This PR was generated with
[release-plz](https://github.com/release-plz/release-plz/).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@greptile-apps
Copy link

greptile-apps bot commented Feb 19, 2026

Greptile Summary

Fixes throughput overestimation by using fractional seconds for the divisor in SlidingThroughput::bps calculations while preserving integer bucket counting logic.

  • Changed divisor from whole seconds to fractional seconds (as_secs_f64) to accurately compute bytes per second for non-integer lookback durations
  • Bucket selection logic remains unchanged, continuing to use whole-second counts for determining which buckets to include in the sum
  • Added regression test fractional_lookback_uses_fractional_divisor to verify 1.5s lookback produces correct result (1000.0 / 1.5 bytes/sec)

The fix prevents scenarios where a 1.5-second lookback would incorrectly divide by 1.0 instead of 1.5, causing 50% throughput overestimation.

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk
  • The fix is surgical and correct: it changes only the divisor calculation while preserving bucket selection logic. The new test provides regression coverage, and the change aligns with the documented behavior of using fractional precision for throughput calculation
  • No files require special attention

Important Files Changed

Filename Overview
src/service/throughput.rs Fixes throughput calculation for fractional lookbacks by using f64 divisor while preserving integer bucket selection logic, includes regression test

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[bps called with lookback Duration] --> B{lookback == 0 or NUM_BUCKETS == 0?}
    B -->|Yes| C[Return 0.0]
    B -->|No| D[Calculate lookback_seconds_f64 = max lookback.as_secs_f64, 1.0]
    D --> E[Calculate lookback_secs = max lookback.as_secs, 1]
    E --> F[Advance to current tick]
    F --> G[Calculate window_secs = min lookback_secs, NUM_BUCKETS]
    G --> H{window_secs == 0?}
    H -->|Yes| C
    H -->|No| I[Sum bytes from window_secs completed buckets]
    I --> J[Return sum / lookback_seconds_f64]
    
    style D fill:#90EE90
    style J fill:#90EE90
Loading

Last reviewed commit: be4eeb7

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.

[Detail Bug] SlidingThroughput bps truncates fractional lookback, overestimating throughput

1 participant