WIP: page_service: higher-resolution timer for batching

[problame]

Problem

The page_service server-side batching does not support short batching timeouts (e.g. 10us).

The reason is that we use tokio::time::sleep , which doesn't have the required resolution. (Tokio docs state millisecond-resolution).

Solution

Use the async-timer crate for high-resolution timers. Specifically, we use the async-timer 1.0beta15 with features=["tokio1"].

On Linux, the timer is backed by a dedicated timerfd. It is registered with tokio through the usual AsyncFd machinery. This choice means each page_service connection consumes an additional (timer)filedescriptor, which is sub-optimal but tolerable.

Performance Testing

I used the benchmark to determine whether this change is moving things in the right direction. I adjusted the runtime from 60 to 5 seconds for faster iteration.

For un-batchable workloads, we examine the wall clock time and CPU time spent. The baseline is batching disabled, the configuration we measure is 10us.

For batchable workloads, we examine the wall clock time and batching factor.

Results TBD

Alternatives Explored

The Git history of this branch contains alternatives explored along with links to benchmark results

async-timer stable release 0.7.4

The stable release of async-timer is 0.7.4 at the time of writing.

It uses the signal-based POSIX timer APIs (timer_create, timer_settime, etc).

I don't have a lot of experience with signals but am generally quite wary about having signals at this incredibly high frequency.

Also, according to the man page, signal-based timer API comes with rlimit caveats, which would be something we have to keep in mind for the prod deployment.

Consequently, the number of timers is limited by the RLIMIT_SIGPENDING resource limit (see setrlimit(2)).

tokio_timerfd::Delay

On Linux, this performs identically to what is in this PR, i.e., to the async-timer 1.0 with features=["tokio1"].

However, timerfd is a Linux-only concept, so, we wouldn't be able to compile on macOS.

[problame]

Kicked off some discussion on Slack about alternatives: https://neondb.slack.com/archives/C0277TKAJCA/p1732115135666759

[github-actions[bot]]

5535 tests run: 5309 passed, 0 failed, 226 skipped (full report)

---

Flaky tests (2)

#### Postgres 17 - `test_compute_pageserver_connection_stress`: [debug-x86-64](https://neon-github-public-dev.s3.amazonaws.com/reports/pr-9822/11958604212/index.html#suites/17ce3111e92c0f109f76121e2725061b/d25d2ded4a0795ee/retries) #### Postgres 15 - `test_cli_start_stop`: [release-arm64](https://neon-github-public-dev.s3.amazonaws.com/reports/pr-9822/11958604212/index.html#suites/7c2541b6822795aacf99a72eb660b5b7/7a5cc97fb6f23a0f/retries)

Code coverage* (full report)

• functions: 31.4% (7954 of 25321 functions)
• lines: 49.4% (63098 of 127829 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
09e7485004805bd42b53a0c369170b3228136512 at 2024-11-21T18:39:30.934Z :recycle:}