PERF: compare residual ordinary HDD mutation p95 after narrow durability (#824) #855

Open
opened 2026-10-02 15:53:19 +00:00 by kayg · 0 comments
Owner

#824 round 2 restored ordinary mutation latency to the requested approximately 0.4 ms target. A small comparison still exceeds the project latency threshold, so this is a non-blocking performance follow-up.

Evidence: release probe built on the host; SQLite 3.51.3; one complete HDD run under /root/perf.lock, with load recorded inside the lock. ext4/noatime/direct-I/O loop, 8 ms read/write delay, existing HDD profile caps. 100,000 synthetic 1 KiB rows in 100-row transactions; 1,000 ordinary one-row changes and 1,000 FULL authority changes measured separately; separate 32-request bursts. All samples succeeded.

Ordinary p50 0.248825 ms, p95 0.401852 ms, max 359.712240 ms. Old NORMAL profile p95 0.363 ms: +10.70%, versus a 10% threshold (0.3993 ms). Round-1 shared FULL p95 was 103.992 ms; that regression is removed. The new ordinary mutation modifies an ingest row rather than the old synthetic authority row, and the new run alternates FULL authority commits. These workloads are not identical.

New load at start 5.42/2.54/2.62; old before load 0.08/0.73/0.66. No wait for a quiet VM and no measurement loop. Authority p95 117.234803 ms is reported separately, not treated as the ordinary-write target. Ordinary burst p95 3.974247 ms versus 4.151 ms before. Ingest p95 0.916378 ms versus 0.870 ms before (+5.33%). CPU user+system 1.35 s; peak RSS 6,772 KiB. docs/perf/baseline.json has no directly matching SQLite durability profile; comparison is the audited before profile in docs/perf/2026-10-02-wal-824.md.

This finding does not establish a code regression from a 38.852 microsecond difference under different load and mixed durability work. Future periodic profiling can compare the same mixed workload on the current baseline. No User data or financial data was used.

#824 round 2 restored ordinary mutation latency to the requested approximately 0.4 ms target. A small comparison still exceeds the project latency threshold, so this is a non-blocking performance follow-up. Evidence: release probe built on the host; SQLite 3.51.3; one complete HDD run under /root/perf.lock, with load recorded inside the lock. ext4/noatime/direct-I/O loop, 8 ms read/write delay, existing HDD profile caps. 100,000 synthetic 1 KiB rows in 100-row transactions; 1,000 ordinary one-row changes and 1,000 FULL authority changes measured separately; separate 32-request bursts. All samples succeeded. Ordinary p50 0.248825 ms, p95 0.401852 ms, max 359.712240 ms. Old NORMAL profile p95 0.363 ms: +10.70%, versus a 10% threshold (0.3993 ms). Round-1 shared FULL p95 was 103.992 ms; that regression is removed. The new ordinary mutation modifies an ingest row rather than the old synthetic authority row, and the new run alternates FULL authority commits. These workloads are not identical. New load at start 5.42/2.54/2.62; old before load 0.08/0.73/0.66. No wait for a quiet VM and no measurement loop. Authority p95 117.234803 ms is reported separately, not treated as the ordinary-write target. Ordinary burst p95 3.974247 ms versus 4.151 ms before. Ingest p95 0.916378 ms versus 0.870 ms before (+5.33%). CPU user+system 1.35 s; peak RSS 6,772 KiB. docs/perf/baseline.json has no directly matching SQLite durability profile; comparison is the audited before profile in docs/perf/2026-10-02-wal-824.md. This finding does not establish a code regression from a 38.852 microsecond difference under different load and mixed durability work. Future periodic profiling can compare the same mixed workload on the current baseline. No User data or financial data was used.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal#855
No description provided.