jedarden/miroir
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

P12.OP2: Finalize Raft research — correct openraft version, update benchmarks, suppress warnings

Browse source 
Correct openraft version from 0.9.22 to 0.9.20 (latest stable per GitHub releases).
Update benchmark measurements from fresh re-run (50K ops). Suppress dead_code warnings
in benchmark module (functions only called from #[test]).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
jedarden 2026-04-18 22:37:20 -04:00
parent 7a6dea77cf
commit ffc0ae3beb
3 changed files with 15 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
crates/miroir-core/src/raft_proto/benchmark.rs
View file

@ -7,9 +7,11 @@
//!
//! Run with: `cargo test -p miroir-core raft_proto::benchmark -- --nocapture`
#![allow(dead_code)]
use super::command::TaskStoreCommand;
use super::state_machine::TaskStateMachine;
use crate::task::{MiroirTask, NodeTask, NodeTaskStatus, TaskFilter, TaskStatus};
use crate::task::{MiroirTask, NodeTask, NodeTaskStatus, TaskStatus};
use std::collections::HashMap;
use std::time::Instant;

4
crates/miroir-core/src/raft_proto/mod.rs
View file

@ -9,7 +9,7 @@
//!
//! ## Why self-contained instead of depending on openraft
//!
//! openraft 0.9.22 depends on `validit 0.2.5` which uses `let_chains` — an unstable
//! openraft 0.9.20 depends on `validit 0.2.5` which uses `let_chains` — an unstable
//! Rust feature not available on stable 1.87. This compilation failure is itself
//! a data point against Raft in the near term. The prototype simulates the Raft
//! architecture to benchmark the state machine apply path, which is the performance-
@ -38,9 +38,11 @@ use std::time::Duration;
///
/// The network + fsync dominates. This constant represents the consensus overhead
/// based on published openraft benchmarks and typical K8s pod-to-pod latency.
#[allow(dead_code)]
const RAFT_CONSENSUS_OVERHEAD: Duration = Duration::from_micros(2500); // 2.5ms median
/// Redis network overhead (same cluster, pod-to-pod).
#[allow(dead_code)]
const REDIS_NETWORK_OVERHEAD: Duration = Duration::from_micros(500); // 0.5ms median
/// Raft-backed implementation of TaskRegistry.

18
docs/research/raft-task-store.md
View file

@ -32,7 +32,7 @@ Open Problem #2 asks: can we embed a Raft consensus module so that N Miroir pods
| Crate | Version | Stars | Last Activity | Status |
|-------|---------|-------|---------------|--------|
| **openraft** | 0.9.22 (stable), 0.10.0-alpha.17 | 1,890 | 2026-04-18 (verified) | Actively maintained |
| **openraft** | 0.9.20 (stable), 0.10.0-alpha.17 | 1,890 | 2026-04-18 (verified) | Actively maintained |
| **raft-rs** (tikv) | 0.7.0 | 3,324 | 2026-04-14 (verified) | Maintenance mode — no active roadmap, TiKV internalized much of the logic |
| **async-raft** | 0.6.1 | ~1,091 | 2023-02-12 | **Abandoned — do not use** |
@ -232,16 +232,16 @@ cargo test -p miroir-core --features raft-proto raft_proto::benchmark -- --nocap
| Operation | State Machine | Direct HashMap | Overhead |
|-----------|-------------|----------------|----------|
| Insert | 1,900 ns | 1,865 ns | 1.0x |
| Read | 255 ns | 237 ns | 1.1x |
| Update | 326 ns | 335 ns | 1.0x |
| Insert | 1,889 ns | 1,925 ns | 1.0x |
| Read | 250 ns | 242 ns | 1.0x |
| Update | 312 ns | 337 ns | 0.9x |
| Serialization | Avg Latency | Size per Command |
|---------------|-------------|-----------------|
| JSON | 1,515 ns | 73 bytes |
| Bincode | 442 ns | 26 bytes |
| JSON | 1,464 ns | 73 bytes |
| Bincode | 425 ns | 26 bytes |
**Throughput (single-threaded, local apply only):** ~526K ops/sec (state machine) vs ~536K ops/sec (direct)
**Throughput (single-threaded, local apply only):** ~529K ops/sec (state machine) vs ~519K ops/sec (direct)
**Key finding:** The state machine apply path adds negligible overhead (~1.0x) vs. direct HashMap access. Both are sub-microsecond. The real cost of Raft consensus is network round-trips + fsync, not the apply logic.
@ -395,7 +395,7 @@ This preserves the investment in the SQLite and Redis backends and avoids forcin
### Compilation Note
openraft 0.9.22 fails to compile on stable Rust 1.87 because its dependency `validit 0.2.5` uses the unstable `let_chains` feature. The 0.10 alpha series compounds this by requiring Rust edition 2024. The prototype works around this by simulating Raft consensus rather than depending on openraft directly — only `bincode` is needed for the serialization benchmarks. This compilation failure is itself a data point: a dependency that requires nightly or bleeding-edge stable Rust is not suitable for production use in v1.0.
openraft 0.9.20 fails to compile on stable Rust 1.87 because its dependency `validit 0.2.5` uses the unstable `let_chains` feature. The 0.10 alpha series compounds this by requiring Rust edition 2024. The prototype works around this by simulating Raft consensus rather than depending on openraft directly — only `bincode` is needed for the serialization benchmarks. This compilation failure is itself a data point: a dependency that requires nightly or bleeding-edge stable Rust is not suitable for production use in v1.0.
---
@ -443,7 +443,7 @@ rrqlite validates that the openraft + SQLite combination works in production. Ho
## 9. Appendix: Crate Deep-Dive
### openraft v0.9.22 (Stable)
### openraft v0.9.20 (Stable)
```
[dependencies]