zwitschi
529ff967cc
CI / lint-test-build (push) Failing after 1m23s
- Implemented integration tests for the execution writer to ensure trade orders and PnL are persisted correctly. - Created integration tests for the metrics calculator to summarize execution data accurately. - Added integration tests for the opportunity writer to verify event persistence. - Established PostgreSQL schema validation tests to ensure all expected tables, columns, and constraints exist. - Removed outdated unit tests that relied on DuckDB and replaced them with tests using PgStore.
Performance Hardening
This folder contains latency profiling baselines and guardrail thresholds used in CI.
Scenarios
The profiler covers representative load patterns:
book_update_burst: rapid market-data deltas with moderate detection load.execution_spike: heavier detection/execution pressure.reconnect_storm: frequent reconnect/reset behavior.
Profiling Commands
Generate a fresh profile:
python scripts/profile_latency.py --iterations 600 --output ops/performance/latency_baseline.json
Check current performance against the baseline and thresholds:
python scripts/check_latency_regression.py \
--baseline ops/performance/latency_baseline.json \
--thresholds ops/performance/latency_thresholds.json \
--iterations 600
CI executes the same guardrail check.
Baseline Snapshot (2026-06-01)
Key end-to-end latency baselines from latency_baseline.json:
book_update_burst: p95 = 0.0132 ms, p99 = 0.0198 msexecution_spike: p95 = 0.0139 ms, p99 = 0.0177 msreconnect_storm: p95 = 0.0114 ms, p99 = 0.0134 ms
Optimization Note
MetricsCalculator.compute() uses PostgreSQL SQL aggregations and percentiles, reducing Python-side row scans.
Measured benchmark (scripts/benchmark_metrics_compute.py):
- Python scan baseline: 12.623 ms
- SQL aggregate implementation: 11.039 ms
- Speedup: 1.14x