[Home](https://hmbastion.com/) [Blog](https://hmbastion.com/blog/) Planning Planning 5 min read # Build a VPS capacity test that answers a real planning question A capacity test is useful when it explains which workload a service can sustain under stated conditions. Sending requests until something fails produces a number, but that number can describe an unrealistic cache path or a saturated load generator. Begin with the decision the test needs to support, then design the workload and measurements around it. HM Bastion Editorial Published 2026-10-26 ## In this guide - [Write the decision before building the test](https://hmbastion.com/blog/vps-capacity-load-testing-plan/#write-the-planning-question) - [Model application work rather than an attractive headline](https://hmbastion.com/blog/vps-capacity-load-testing-plan/#model-useful-requests) - [Measure completed operations and define when to stop the test](https://hmbastion.com/blog/vps-capacity-load-testing-plan/#define-measures-and-stops) - [Turn the result into a controlled next step](https://hmbastion.com/blog/vps-capacity-load-testing-plan/#interpret-and-repeat) [All hosting guides](https://hmbastion.com/blog/) ## The practical takeaway Test representative work in an authorised environment, measure successful responses and latency distributions together, identify the constrained layer, and keep the conditions with the result. ## Write the decision before building the test State what is changing and what the application needs to keep doing. A forthcoming campaign may increase browsing, while an import job may compete with normal API traffic. A resource change may aim to reduce response times during an existing peak. Name the important journey and its acceptable behaviour. Avoid beginning with an arbitrary request count that has no relationship to how people or background workers use the service. Record the current application version, database size, region, hosting resources and relevant configuration. Include caching, worker limits and external dependencies. This turns the result into something another maintainer can repeat. If a later run changes several of these at once, label it as a different scenario instead of presenting it as proof that one extra CPU solved everything. Keep test credentials separate from real customer accounts. Use a staging or otherwise controlled environment with explicit permission and a suitable window. Coordinate with the team when the test could affect shared infrastructure or service limits. Replace external payment, email and other third-party actions with appropriate test integrations unless participation is arranged. A capacity exercise should not create real purchases, send a large batch of messages or become an unannounced traffic flood against another service. ## Model application work rather than an attractive headline Choose a realistic mix of requests and visitor states. Public cached pages, authenticated APIs, uploads and expensive searches can have very different costs. Include suitable pauses or an arrival pattern that matches the planning question. A test that repeatedly requests the same tiny cached response may help check that path, but it does not establish the capacity of account pages or database writes. Explain that limitation alongside the result. | Scenario | What it answers | What it does not establish | | --- | --- | --- | | Warm public page | Behaviour of a reusable response path | Personalised application capacity | | Signed-in API journey | The selected application and database work | Every possible endpoint or customer pattern | | Scheduled job plus normal requests | Contention during that known overlap | Future jobs with different data | | Gradually increasing arrivals | Where latency and errors begin to rise | A universal maximum for the hosting range | Populate the test with representative data distributions. A product list containing a handful of rows can exercise different query behaviour from one containing a long history. Use synthetic or properly protected data, and confirm that reset and cleanup procedures work before the main run. Watch the load generator’s CPU, network and scheduling as well as the application. Otherwise, a generator bottleneck can make a server look stable simply because the intended work never arrived. ## Measure completed operations and define when to stop the test Track the rate of successfully completed operations, failures and latency distributions together. An average can hide unusually slow responses, while a high request rate may include responses that fail the user journey. Check response content or application outcomes where relevant rather than treating every HTTP response as success. Separate time spent connecting from application waiting and transfer time when the tooling allows it. Compare these observations with server and database measurements from the same period. Define stop conditions before running the test. They can include sustained errors, unacceptable latency, excessive resource pressure or a signal that another system is being affected. Choose values appropriate to the actual application and environment; there is no universal threshold that proves every service is healthy. Automated thresholds can help evaluate a run, but someone still needs ownership of the test, its effects and the decision to stop. Increase work in stages so you can observe the change rather than jumping immediately to an extreme. Keep a stable period long enough to see the behaviour relevant to the workload, including any known queue or cache effects. Record when the test starts and each stage changes. If latency rises while CPU remains low, investigate waiting, contention and dependencies before concluding that the plan needs more cores. ## Turn the result into a controlled next step - Save the workload definition, data assumptions and software versions. - Report the number of successful operations per second, error rate and latency percentiles together. - Identify the likely constrained layer and the evidence supporting it. - Change one relevant setting or resource and repeat the same scenario. - Document the remaining headroom and the limits of the conclusion. For example, an API may hold up under ordinary reads but develop a long queue when a scheduled export overlaps them. The useful response may be to reschedule or redesign the export, reduce transaction duration, or adjust the appropriate resource. A larger hosting configuration is one possible intervention, not the only outcome. Check the full application journey again after a change so faster responses do not conceal incorrect or missing work. Keep results tied to their conditions when choosing a VPS. A virtual core, memory allocation and network port describe resources; they do not guarantee a fixed number of visitors or requests for every application. Revisit the test after meaningful changes in code, data or traffic mix. Capacity planning becomes more reliable when it is a repeated comparison with recorded assumptions, rather than a single impressive number detached from the system that produced it. Product examples use the published HM Bastion catalogue. Availability, prices and selectable options are shown when you configure an order. ## Choose your next foundation. [Compare Cloud VPS configurations](https://hmbastion.com/hosting/?category=cloud) [Read server specifications in context](https://hmbastion.com/blog/understand-server-resources/) [Discuss a planned capacity test](https://hmbastion.com/support/) ## Sources and further reading - [Grafana k6 documentation: metrics and request timing](https://grafana.com/docs/k6/latest/using-k6/metrics/) - [Grafana k6 documentation: thresholds](https://grafana.com/docs/k6/latest/using-k6/thresholds/) - [Prometheus documentation: instrumentation principles](https://prometheus.io/docs/practices/instrumentation/) ## Keep exploring [ Security 6 min read ## Hosting incident: coordinate recovery and write a useful support request Coordinate a hosting incident with a clear owner, a factual timeline, protected evidence, reversible changes and a concise support request. ](https://hmbastion.com/blog/incident-response-useful-support-brief/) [ Security 5 min read ## Secure SSH access to your VPS and preserve a recovery route Build a practical SSH access policy with verified host keys, individual accounts, tested authentication and a recovery path. ](https://hmbastion.com/blog/secure-ssh-access-vps/)