Cost Per Request: A Budget VPS Capacity Model Using Real Metrics

Monthly price tells you almost nothing about whether a VPS is good value for your workload. Cost per request does. This guide builds a simple capacity model from metrics you can collect on any cheap instance, so you can predict the real monthly bill of a workload before you commit to a plan.

The model takes about an hour to build and will save you far more than that across a year of billing surprises.

Step 1: Measure Sustainable RPS

Load test your candidate plan at increasing concurrency and record the point where p95 latency doubles. That knee in the curve is your sustainable requests per second. Do not use the peak burst throughput number, because it only holds for a few seconds before throttling or queueing takes over.

• Use a short, fixed workload such as a static page plus one database query.
• Record p50, p95, and p99 latency at 10, 50, 100, and 250 concurrent connections.
• Find the concurrency at which p95 crosses twice its baseline value.
• Convert that concurrency to completed requests per second, which is your sustainable RPS.

Step 2: Convert RPS to Monthly Capacity

Multiply sustainable RPS by the number of seconds in a month (about 2,592,000) to get a theoretical ceiling. Then apply a safety factor of 0.4 to account for traffic peaks and maintenance windows, which keeps the instance comfortably below the knee during real-world spikes.

Step 3: Divide Price by Planned Requests

A $3 plan sustaining 40 RPS yields roughly 41.5M planned requests per month, or about $0.072 per million requests. A $7 plan sustaining 120 RPS yields about 124M planned requests, or roughly $0.056 per million. The seemingly more expensive plan is over 20% cheaper per unit of actual work delivered.

This single calculation frequently reverses the ranking of plans that look cheapest on the marketing page, which is exactly why it is worth doing before you buy.

Step 4: Include the Real Cost Drivers

• Bandwidth overage: add roughly $0.01 per GB over the allowance at typical rates.
• Backup storage: add $0.10-0.30 per GB per month when snapshots are not included.
• Extra IP addresses: add $1-2 each if you run multiple TLS sites.
• Engineering time: the largest hidden cost; a plan needing nightly manual babysitting is not cheap at any price.

Step 5: Stress the Model With a Peak Scenario

Real traffic is never uniform. Model a peak day at five times the average. If the plan’s burst credits or shared CPU throttle at that level, cost per request rises sharply during exactly the window you cannot afford downtime. Choose a plan whose fair-share CPU covers the peak, not merely the average.

Using the Model

Build this model for every candidate plan and compare cost per million planned requests rather than headline price. The winner is frequently the mid-tier plan, not the cheapest one, because economies of scale reward the slightly larger instance.

A Worked Example

Suppose your application serves 20 million requests per month at peak-five-times average. A $3 plan sustaining 15 RPS gives 15.6M planned requests, which is short of your peak and will throttle. A $7 plan sustaining 45 RPS gives 46.6M planned requests, comfortably covering the peak with headroom for growth. The $7 plan is not an expense; it is the minimum viable purchase for that workload.

Our affordable VPS comparison lists entry and mid-tier plans so you can plug their specs into this model and see which one actually lands lowest on cost per request.

Choosing the Right Metric to Optimise

Cost per request only makes sense when you connect it to the value of a request. A site monetised by display ads has a very different tolerance for expensive requests than an API serving paying customers. Use the model to find the crossover point: the request volume at which a larger plan becomes cheaper per request than the smaller plan you started on.

• Ads or affiliate revenue: value per request is low, so minimise cost per request and favour the cheapest plan that meets the peak.
• Paying API customers: value per request is high, so prioritise headroom and latency over the last few dollars of monthly cost.
• Internal tooling: availability usually matters more than unit cost, so build in failover even if it raises cost per request.

Common Modelling Mistakes

• Using peak throughput instead of sustainable throughput: this overstates capacity by 2-5x and leads to chronic throttling under real load.
• Ignoring the safety factor: a plan running at its theoretical ceiling has no room for a spike, a cron job, or a backup window.
• Forgetting the addon line items: bandwidth, backups, and extra IPs can add 30-50% to the effective monthly cost.
• Assuming traffic is uniform: peaks are where capacity models fail, so always stress the plan against a five-times-average day.

A model that survives each of these mistakes will rank plans the way your invoice eventually will, which is the whole purpose of building it.

Related Articles：

Provider Durability Audit: Six Signals You Can Check Before Prepaying a Year Best Budget VPS Providers with Free Migration: Save Time and Money Switching Hosts How to Reduce VPS Hosting Costs Without Sacrificing Performance: 9 Tactics Ranked by Effort and Savings How to Forecast Your True 12-Month VPS Cost Before You Buy