test_runner/performance: add logical message ingest benchmark

[erikgrinaker]

Adds a benchmark for logical message WAL ingestion throughput end-to-end. Logical messages are essentially noops, and thus ignored by the Pageserver.

Example results from my MacBook, with fsync enabled:

postgres_ingest: 14.445 s
safekeeper_ingest: 29.948 s
pageserver_ingest: 30.013 s
pageserver_recover_ingest: 8.633 s
wal_written: 10,340 MB
message_count: 1310720 messages
postgres_throughput: 715 MB/s
safekeeper_throughput: 345 MB/s
pageserver_throughput: 344 MB/s
pageserver_recover_throughput: 1197 MB/s

See #9642 (comment) for running analysis.

Touches #9642.

[skyzh]

actually, pageservers need to ingest some logical messages as part of aux file implementation ->

neon/pageserver/src/walingest.rs

Lines 242 to 245 in 10aaa36

	Some(MetadataRecord::LogicalMessage(rec)) => match rec {
	LogicalMessageRecord::Put(put) => {
	self.ingest_logical_message_put(put, modification, ctx)
	.await?;

but the ones created in the test case will likely be dropped by the pageserver in the end

[skyzh]

...aux file logical messages begin with neon-file:

[github-actions]

5490 tests run: 5247 passed, 0 failed, 243 skipped (full report)

---

Code coverage* (full report)

• functions: 31.5% (7928 of 25166 functions)
• lines: 49.6% (62835 of 126578 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
9a82514 at 2024-11-18T11:48:29.354Z :recycle:}

[jcsp]

Would you mind noting the results you currently get in the PR description? I find this useful when looking back at history of benchmarks (even though we also have some history in a database)

[erikgrinaker]

Would you mind noting the results you currently get in the PR description? I find this useful when looking back at history of benchmarks (even though we also have some history in a database)

Sure, added a result from my MacBook, but I don't think it's particularly useful without more context and representative hardware.

For running analysis, see #9642 (comment).