Concurrent editor capacity: build a realistic load test

A capacity result should be readable as an experiment definition. Include the product version and topology, test duration, document corpus, session behavior, arrival pattern, background work, and pass criteria. This makes the result reproducible when a later upgrade or workload change raises a sizing question.

arrival: planning meeting opens over 5 minutes
sessions: viewers and active editors recorded separately
corpus: reports plus shared calculation workbooks
background: normal conversion jobs continue
pass: agreed open latency and durable save completion

These are illustrative report fields, not measured limits. Replace the descriptions with the actual test data and thresholds. Record percentile latency or another approved summary alongside failures; an average can conceal a small group of users repeatedly waiting too long.

Observe what the harness truly does. Keeping sockets open is not equivalent to recalculating a workbook or importing a presentation. Conversely, an artificial script that submits edits much faster than humans may test a useful stress boundary without representing ordinary capacity. Label those cases separately. Use the business workload to decide the supported operating envelope and the stress test to understand saturation behavior, admission controls, and recovery after pressure subsides.

Suppose 120 staff join a planning meeting within five minutes, with most opening reports and 25 editing shared workbooks. Create a harmless corpus and reproduce that arrival pattern in an approved test environment. Add a normal background conversion workload instead of testing sessions in isolation. Observe opening latency, queue depth, save completion, and database or storage delay. Repeat at a modestly higher load to identify which limit approaches first. The figures are scenario inputs, not a sizing promise. Their value comes from resembling a real business event that the proposed service must handle.