# Capacity Testing > Source-anchored research for Capacity Testing. Run status: COMPLETED. Parent: [MongoDB Capacity Planning](https://llms-explorer.com/tree/mongodb-capacity-planning/) · 2 facets · 11 facts · page: https://llms-explorer.com/tree/capacity-testing/ ## How it works - Test realistic data volume and working-set size: MongoDB's benchmark study found that disk performance became a major throughput and tail-latency constraint when the working set exceeded available caches, while database benchmark research identifies fixed record lengths as a realism gap for growing values. (high confidence) — [source](https://www.mongodb.com/company/blog/through-the-looking-glass-analyzing-the-interplay-between-memory-disk-and-read-performance) - Increase concurrency in controlled steps and record throughput and operation latency while monitoring deployment resources. A throughput plateau with rising latency marks diminishing returns; check load-generator and network limits too, because the generator can plateau before the database is saturated. (medium confidence) — [source](https://www.percona.com/blog/the-importance-of-realistic-benchmark-workloads/) - Match benchmark data volume and value-size behavior to the target workload, and warm the expected working set before measuring steady-state reads. MongoDB recommends priming with representative queries and reports that working-set size relative to cache and disk changes measured performance; recent benchmark research identifies fixed-length values as a gap when records grow over time. (high confidence) — [source](https://www.mongodb.com/company/blog/performance-best-practices-benchmarking) ## Facts and statements - Capacity testing measures whether an application and its database remain responsive and stable as demand rises, using throughput, latency, errors, and resource use to identify the sustainable operating boundary. (high confidence) — [source](https://www.mongodb.com/resources/basics/load-testing) - Model tests on application-derived document shapes, queries, and deployment conditions, and warm the working set before timing; generic data and unrepresentative test setup can produce misleading capacity results. (high confidence) — [source](https://www.mongodb.com/company/blog/performance-best-practices-benchmarking) - Increase offered work in controlled steps and record throughput and latency at each step; a throughput plateau with rising latency marks diminishing returns, so a peak operations-per-second number alone can overstate useful capacity. (high confidence) — [source](https://www.percona.com/blog/the-importance-of-realistic-benchmark-workloads/) - Correlate application latency and errors with database-side telemetry. Atlas documentation currently lists CPU, cache, disk IOPS, disk latency and queue depth, operation rates, and query execution metrics that can help locate resource constraints. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics/) - Treat YCSB or sysbench scores as controlled results for their configured workload, not as portable production capacity promises; use application-derived workloads or traces to validate a target deployment. (high confidence) — [source](https://docs.fptcloud.com/docs/fpt-database-engine/fpt-database-engine-mongodb/reference/benchmark-sysbench/) - Keep benchmark setup repeatable and preserve clean runs as baselines; MongoDB's automated system performance testing work emphasizes reproducible end-to-end tests, while load-testing guidance treats clean results as the comparison baseline for later runs. (high confidence) — [source](https://arxiv.org/abs/2004.08425) - Estimate MongoDB capacity with a workload that matches the application's document structures and sizes, query patterns, and target deployment. MongoDB recommends representative data, queries, and deployment conditions; Percona warns that generic tools may measure raw throughput without predicting application-specific logic. (high confidence) — [source](https://www.mongodb.com/company/blog/performance-best-practices-benchmarking) - Treat YCSB and other synthetic profiles as controlled baselines, not production-capacity guarantees. MongoDB Research argues that standard benchmark scores rarely establish predictive performance for an intended application and that closed-loop clients do not model independently arriving overload; Percona likewise says generic profiles can miss custom application logic, and recent research identifies changing value lengths as another workload gap. (medium confidence) — [source](https://www.mongodb.com/company/research/distributed-systems-research-group/lets-not-waste-time-on-excessive-benchmarking)