Add database persistence benchmarks#915
Conversation
|
👋 Hi! I see this is a draft PR. |
5f75dd9 to
bc97c3a
Compare
|
Feel free to rebase on top of #919 and let me know if you see any differences in the benchmarks. |
|
codex summary: Benchmark ResultsPayment Benchmarks
Lower is better. Delta compares the async-branch rerun against the previous saved Criterion results.
Takeaways
|
|
It would have been nice if async persistence would show a clear performance win here. The store-level smoke tests are useful, but the closest thing to real node load seems to be the payment benchmark, and that does not show a meaningful improvement, putting aside that it is marked as not reliable yet. Does this tell us much about high-load node performance in practice? If not, what would be the next useful benchmark? |
Hmm, note that 'async persistence' means pre and post #919 AFAIU? I.e., it does not refer to LDK's async persistence itself, which we switched to pre-#919. |
Added a few more with start up time, forwarding payments, and channel opens. But working on making these more robust |
Use a temporary rust-lightning fork revision that exposes async migratable KV-store support. This lets ldk-node migrate filesystem stores without reimplementing LDK's migration logic locally. Co-Authored-By: HAL 9000
Read and write BDK wallet state through async KVStore helpers while keeping the current WalletPersister entry points bridged through the node runtime. This reduces the wallet persistence surface that still depends on KVStoreSync. Co-Authored-By: HAL 9000
Static invoice persistence already runs from async handlers, so use KVStore directly instead of routing those reads and writes through the blocking KVStoreSync trait. Co-Authored-By: HAL 9000
Persist peer store updates through async KVStore operations. The synchronous node APIs keep bridging at their runtime boundary while async event handling awaits peer persistence directly. Co-Authored-By: HAL 9000
Co-Authored-By: HAL 9000
Persist DataStore mutations through async KVStore operations while keeping the existing synchronous APIs bridged through the node runtime. Async event handling now awaits payment store writes directly. Co-Authored-By: HAL 9000
Persist node metric updates through async KVStore writes and await them from the chain, gossip, and scoring tasks. This removes the remaining blocking metrics writer while keeping the helper name stable. Co-Authored-By: HAL 9000
Avoid introducing a temporary macro when moving node metrics persistence onto async KV storage. Co-Authored-By: HAL 9000
Co-Authored-By: HAL 9000
Persist the on-chain wallet through BDK's AsyncWalletPersister so wallet state writes use the async KVStore path. Existing synchronous wallet APIs keep bridging through the node runtime until their callers are made async. Co-Authored-By: HAL 9000
Open filesystem stores through the async LDK migration helper so v1-to-v2 store migration no longer depends on the blocking KVStoreSync migration path. Co-Authored-By: HAL 9000
Move the existing in-memory test store into a shared module without changing its behavior. This lets integration tests reuse it while keeping the later async TestSyncStore change separate. Co-Authored-By: HAL 9000
Keep the shared test store move as a pure code move by restoring the original comments and spacing. Co-Authored-By: HAL 9000
Exercise async KVStore operations in TestSyncStore and filesystem migration tests while keeping the temporary sync comparison path until the final KVStoreSync removal. Also route pathfinding score export through async KVStore reads. Co-Authored-By: HAL 9000
Drop the remaining synchronous KV store trait bounds and implementations. After the preceding migrations, custom stores only need to provide async KVStore persistence. Co-Authored-By: HAL 9000
Compile the VSS persistence tests after the shared KV store helper moved to async persistence. Co-Authored-By: HAL 9000
Add a crate-local runtime wrapper for store backends that need to keep their I/O isolated while shutting down safely from async contexts. Co-Authored-By: HAL 9000
Co-Authored-By: HAL 9000
Co-Authored-By: HAL 9000
Enable Tokio's eager driver handoff when building with tokio_unstable so node-owned runtimes can use the dedicated driver handoff path where available. Build binding artifacts and selected CI coverage with tokio_unstable so the cfg-gated runtime path remains exercised. Co-Authored-By: HAL 9000
AI-Assisted-By: OpenAI Codex
Benchmark realistic payment and pending-payment persistence workloads across filesystem, SQLite, and optional PostgreSQL stores. Use the async KV-store APIs so the measured paths match the database interfaces used by async persistence. AI-Assisted: Codex
Run the existing payments benchmark once per configured store backend so filesystem, SQLite, and optional PostgreSQL results are reported under the same payment flow. AI-assisted-by: OpenAI Codex
Wait for the cleanup payment to settle before starting the next payment benchmark sample. This keeps the measured forward-payment duration intact while avoiding HTLC state leaking into later samples. AI tools: Created with assistance from OpenAI Codex.
Add an operations bench target with a forwarding benchmark that compares sqlite, filesystem, and postgres stores over a settled multi-hop payment. AI-assisted-by: OpenAI Codex
Add a channel-open benchmark that measures the open_channel call while leaving chain confirmation cleanup outside the timed section. AI-assisted-by: OpenAI Codex
Add migratable key listing for SQLite and PostgreSQL stores so benchmark fixtures can copy persisted node state between database backends. AI-assisted-by: OpenAI Codex
Add a startup benchmark that restarts a node whose store already contains channel and payment data, so startup cost reflects persisted node state. AI-assisted-by: OpenAI Codex
built on top of #919
Closes #908
Benchmark realistic payment and pending-payment persistence workloads
across filesystem, SQLite, and optional PostgreSQL stores. Use the async
KV-store APIs so the measured paths match the database interfaces used by
async persistence.
Also adds support for different db backends to the current payment benchmark.
Benchmark Results
Results on my computer with a Ryzen 7 5800XT 8-Core, 16-Thread CPU
Operations
channel_openforwardingchannel_open_closepaymentsStartup
channels_1_payments_2channels_10_payments_2channels_100_payments_2channels_100_payments_1000Database Hot Path
channel_open_likeforwarding_25_like