The short answer.
Measure CPU, RAM and input/output separately under a representative load, then add a margin for peaks and scheduled tasks. Then compare these needs with the available configurations, without inferring a universal hosting capacity from the number of vCPU alone.
- A vCPU is a virtual compute resource, not a guarantee of application throughput.
- The available RAM and the signs of memory pressure matter more than an isolated percentage.
- NVMe capacity, disk throughput and I/O latency are distinct criteria.
01First describe a representative workload
Note the operations actually used: page views, API calls, database queries, file conversion or scheduled processing. Identify peak periods and overlapping tasks. A daily average can mask a heavy import or a backup run at the wrong time.
To compare two setups, use the same data, versions and settings. Record response time and errors, then resource consumption during that test. A performance figure only makes sense if the scenario and the conditions that produced it are known.
02When do you need more vCPU?
KVM presents virtual processors to the guest system. Their number describes a setup, but does not by itself summarize the behavior of your application. A program that mainly executes one task at a time will not necessarily spread that work across all available vCPU.
Observe the processes consuming the CPU, the task queues and the moments when responses slow down. If the processor is waiting on storage or a remote service, adding compute may leave the cause intact. Start by identifying the resource that is blocking processing.
03Interpret memory along with its symptoms
The system may use part of the RAM for useful caches. Memory shown as used is therefore not, by itself, proof of a shortage. Examine available memory, processes, swap activity and out-of-memory events.
Under Linux, tools such as top, vmstat or your system's monitoring dashboards help observe these changes. Their availability depends on your installation. Compare a normal period and a peak, then check whether the slowdown coincides with real memory pressure.
04Plan for storage space and activity
Count the system, the application, the data and temporary files. Add the space needed for updates, exports and expected growth. Keeping a working copy on the same disk can also increase the required space without providing independent protection.
The capacity stated in GB does not measure the speed of your accesses. Observe the volume and duration of reads and writes with the appropriate tools, especially iostat when it is installed. The term NVMe does not provide a guaranteed result for your database or application.
05Read the five WispHost configurations
The range lets you compare compute, memory and storage together. The table below describes the resources in the catalog; it does not turn each setup into a guaranteed number of sites, connections or requests per second.
| Configuration | vCPU | RAM | NVMe storage |
|---|---|---|---|
| Wisp Spark | 2 | 4 GB | 60 GB |
| Wisp Core | 3 | 8 GB | 120 GB |
| Wisp Flow | 4 | 16 GB | 240 GB |
| Wisp Scale | 6 | 32 GB | 480 GB |
| Wisp Prime | 8 | 64 GB | 800 GB |
06Set a starting point and review criteria
Choose the setup that covers your measured scenario with a reasonable margin, then record your re-evaluation thresholds: insufficient available memory, storage soon to be full, or responses exceeding your target under a known load. There is no margin percentage suitable for every project.
Before an upgrade, rerun the same test and check the options for changing range with the team. A well-organized application, database and backup strategy make this decision easier. The server should follow the measured need rather than compensate for an estimate that has remained unchanged.
Sources & references
To explore the technical points further and find the information at its source.