This is re-doing / extending the ‣ but

• with multiple runtimes instead of one runtime
  • NB in theory we can extend this benchmark to test multiple vs one runtime, the code tested is on top of already merged https://github.com/neondatabase/neon/pull/7331
• runtime configurable sync vs async
• walredo timeout implemented again for async

Setup

Code tested: problame/async-walredo/benchmarking-2024-04-08--1 commit aad5a672f06c0b0db4400650b815a118880bf7a1 (later commits are not covered here)

Goal: compare system behavior under max CPU , async vs sync walredo

Strategy:

• pick a load that fits into PS / kernel page cache
• ensure all requests need to do walredo work ⇒ 100% walredo miss

More setup details

• pagebench client on separate instance
• same setup as in 2024-03-23 oneruntime change benchmarking
  • see 82e7e4d84a22dd26c63a72c6941a179d23e12e04 for setup. tl;dr:
    • pgbench with many layers so walredo has something to do
    • make Pageserver CPU-efficient
      • lower log level to warn
      • larger PS PageCache to avoid memcpy’ing indirect blocks (wasn’t super diligent in checking that we weren’t thrashing, though)

Common Setup Instructions