Deutsch
Affordable web hosting should keep your application responsive at a cost you can sustain. A low monthly fee is useful only if the plan handles the workload and leaves room in the budget for maintenance and recovery.
Compare candidates with the same test: representative data, realistic traffic, a response-time target and a restore procedure. The results tell you more than the number of CPU cores or a provider's performance headline.
Describe what the server needs to run
Start with the application and its busiest periods. Record:
- Application and runtime versions.
- Normal and peak requests, background jobs or crawl volume.
- Database size, query patterns and expected growth.
- Active users and their locations.
- Uploads, generated files, logs and backup storage.
- External services used by the application.
- Maintenance windows and acceptable recovery time.
Build a repeatable dataset or request mix from these details. For example, an online shop test should include product browsing and checkout, rather than only repeated requests for a cached home page.
Set a performance target before testing
For a website or API, measure successful requests per second, errors and response times. Include both the median and a slower percentile, such as the 95th percentile, so an acceptable average does not hide long waits for some users.
Collect CPU usage, memory pressure, disk latency, database query time and network transfer over the same period. For a batch job, measure completion time, queue delay and peak resource use. Check whether it slows down the site's interactive requests.
Decide what counts as a pass before running the test. Repeat it at the expected peak, with spare capacity for normal variation and growth. A single fast result on an otherwise empty server is weak evidence for a purchase.
Read the resource allocation carefully
A VPS gives you a defined allocation, but CPU-sharing arrangements vary. Check what the plan specifies. Virtarix Cloud VDS explicitly offers Dedicated CPU; do not assume that label applies to its Cloud VPS plans.
Virtarix VPS S is one configuration you can compare:
| Item | VPS S allocation |
|---|---|
| Standard price | $5.50 per month |
| CPU | 3 cores |
| Memory | 6 GB RAM |
| Storage | 50 GB NVMe |
| Bandwidth | Unlimited, subject to service terms |
| Access | Full root |
| Network | IPv4 + IPv6 |
| Included snapshot | One snapshot |
Bandwidth remains subject to fair use, acceptable-use requirements, network integrity and service limits. Confirm pricing at checkout.
Test whether the allocation meets your requirements. Watch sustained CPU usage, memory pressure, storage latency and disk growth. If it falls short, identify the resource under pressure before selecting a larger plan.
Find application delays before buying capacity
Slow queries, oversized images, memory leaks, unbounded queues and synchronous API calls can make a well-resourced server feel slow. Measure how much time each request spends in application code, the database, external services and server waits.
Make one controlled change and repeat the test. If adding an index resolves the delay, you have avoided an unnecessary resize. If an efficient workload still exhausts a resource, the measurements help you choose the next allocation.
Test the network from your users' locations
Compare latency, packet loss and application response from the networks your users rely on. Test normal and busy periods, and include the VPS's connections to databases, object storage, identity providers and payment services.
The nearest data centre is a useful starting point, but network routes can make another location faster. Hosting in one city also gives you one deployment location; geographic failover requires a separate design.
Cache content that can safely be reused
Choose the appropriate cache layer: browser, CDN, reverse proxy, application or database. Define the cache key, expiry and invalidation rules. Keep authenticated or personalised responses out of shared caches unless you have explicitly designed safe cache behaviour.
A CDN can reduce repeated delivery of images and other cacheable assets. Measure the origin separately, because a fast cached page can hide slow dynamic requests or an overloaded background worker.
