Summary
Current deployment guidance keeps web replicas at 1 due to shared file-locking concerns on NFS-backed paths. This limits throughput and page-load stability under concurrency.
Proposed work
- Identify critical sections currently relying on local/NFS locking semantics
- Implement distributed locking (for example, Redis-based lock strategy) for cross-pod correctness
- Isolate mutable temp paths where possible to reduce lock contention
- Add race-condition/idempotency tests for concurrent web workers
Acceptance criteria
- Multi-replica web operation is validated under concurrent user/API load
- No data corruption, duplicate processing, or lock starvation in stress tests
- Documented operational guidance for enabling web replicas > 1 in Helm
Context
openstudio-server-helm now has HPA v2 and scheduling/resilience controls ready to use once app-level lock safety is in place.
Summary
Current deployment guidance keeps web replicas at 1 due to shared file-locking concerns on NFS-backed paths. This limits throughput and page-load stability under concurrency.
Proposed work
Acceptance criteria
Context
openstudio-server-helm now has HPA v2 and scheduling/resilience controls ready to use once app-level lock safety is in place.