Choose memory for the operating system, persistent services and realistic concurrency with headroom. Choose CPU after measuring which tasks are busy, whether they run in parallel and what delays users actually experience.
Describe normal work and busy work separately
Visitor count alone is a weak sizing input. One request may serve a cached file while another generates a report or queries many tables. List the web workers, database, cache, queue consumers and maintenance tasks that will share the VPS. Describe normal concurrency and the busiest expected operation. Include scheduled exports, package updates and deployments rather than treating them as invisible background activity.
For an existing project, collect a representative period that includes a busy window. Record response times and errors alongside resource usage. For a new project, create a small test with realistic request shapes and data sizes. Your initial estimate will be imperfect; the useful goal is a documented starting point that you can compare with measured behaviour after delivery.
Build the memory budget before adding processes
Memory demand comes from the system, persistent application services, per-worker usage and temporary operations. Multiplying a worker's footprint by a planned concurrency is a rough planning tool, not a guarantee, because shared memory and caches complicate the total. Observe the actual processes under load. Leave enough room that a maintenance task does not force the application to compete for every remaining page.
Database settings can multiply memory use unexpectedly. PostgreSQL documents that work_mem applies to query operations, and several operations or sessions can run concurrently. A setting that looks modest in isolation can therefore have a larger system effect. Read your database's own guidance, test realistic concurrency and avoid assigning every advertised gigabyte to a single cache.
Distinguish CPU utilisation from useful parallelism
A processor count tells you how many execution resources are presented to the guest, not how efficiently your software can use them. One busy thread may limit an application while other cores remain quiet. Adding workers can help independent requests, but it can also increase database contention and memory demand. Check the application's concurrency model before assuming that twice the core count produces twice the throughput.
KVM provides virtual machines with their own virtual hardware. It does not turn every vCPU label into an identical benchmark across hosts and processor generations. Compare the listed CPU model and allocation terms where available, then evaluate the service with your own workload. Avoid drawing a purchasing conclusion from a short synthetic score that does not resemble the application.
Look for pressure and waiting, not just averages
A system can feel slow without maintaining a high average CPU percentage. Processes may wait on storage, memory reclamation or another service. The Linux kernel's Pressure Stall Information exposes CPU, memory and I/O stall information on supported systems. These signals can help identify resource contention alongside normal utilisation metrics and application timings.
Read metrics together. Sustained memory pressure, swapping, failed allocations and slow requests point toward a different intervention from a single busy compute worker. Storage waits may justify query changes or a different disk profile. An external API delay will not be repaired by adding local RAM. Explain the observed constraint before choosing which resource to increase.
| Observed behaviour | Question to investigate | Possible next step |
|---|---|---|
| One thread busy, spare cores quiet | Can this work run in parallel? | Improve the task or change worker design |
| Memory pressure during a report | How many operations overlap? | Bound concurrency or add tested headroom |
| Slow requests with I/O waits | Which reads or writes are delayed? | Inspect queries and storage behaviour |
| CPU and memory low, requests slow | Is a dependency delaying responses? | Measure downstream calls |
A planning example with explicit assumptions
Imagine a small application with two web workers, a database and one queue consumer. The team measures those services during ordinary requests and a report-generation task. It discovers that allowing four reports at once raises memory demand sharply while delaying normal traffic. Instead of immediately buying the largest plan, it limits report concurrency and measures the result again.
If the adjusted workload still needs more memory, the upgrade now answers an observed requirement. If the queue remains CPU-bound and independent jobs can run concurrently, more execution resources may be appropriate. These are example decisions, not performance figures for SwissOctet plans. Keep your own measurements and constraints with the chosen configuration.
Leave a clear path for the next measurement
Define the signs that will trigger a review: response-time deterioration, repeated memory pressure, growing queues or a changed workload. Keep monitoring lightweight enough that it does not become a new bottleneck. Reassess after adding a feature or a major dataset, and avoid repeated upgrades when the real problem is an unbounded process or a slow query.
SwissOctet's VPS families expose CPU and memory specifications and selected resource options. Read the final configuration after adding extras, including the billing period and total. Confirm upgrade arrangements with the live operator before relying on them. A useful VPS size is one that runs the measured workload with sensible headroom and an understandable next step.
Your practical checklist.
- Inventory services and maintenance work.
- Measure normal and busy-period concurrency.
- Budget persistent and temporary memory.
- Check whether CPU work can run in parallel.
- Compare pressure, utilisation and application timings.
- Define when to review the configuration.
The details that matter.
Should I size a VPS by monthly visitors?+
Use visitor count as context, then measure request complexity, concurrency, data size and background work. Equal visitor counts can create different loads.
Does more RAM always make a service faster?+
No. It helps when memory is a constraint or enables useful caching, but does not resolve every CPU, storage or external dependency delay.
Does twice the vCPU count double performance?+
No. Parallelism, processor characteristics, contention and the application's design determine how much extra capacity is useful.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- Linux kernel: Pressure Stall Information docs.kernel.org
- PostgreSQL: Resource Consumption www.postgresql.org
- KVM project: Kernel Virtual Machine www.linux-kvm.org
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.