Articles of the VPS column:
- VPS: the cores trick
- VPS (second part): the SSD trick
- VPS (third part): evaluating performances
- VPS (fourth part): basic troubleshooting in Linux
This is the third part of our guide to the choice of a VPS. In the previous issues, we have talked about how to choose RAM, CPU and disk of a virtual server on which run your applications. Today we’ll dig deeper on how to actually evaluate performances
Before starting to run benchmarks on the VPS you manage, I’d like to remember that in order to have a significant value, the test must be reproducible in different hours and situations. If you have bought a VPS or have requested the provider for a testing VPS and have measured some great performances, don’t ever think that it’s enough to give a definitive evaluation.
Location and obsolescence: cloud grows old
Keep in mind also the geographic position of the VPS: if you have performed a test on the datacenter in Amsterdam, you might get different results if you run it again on a datacenter in Rome. Perhaps the machines used for trials are different from the ones used in production.
Moreover, there is a specific problem that regards the progressive obsolescence of the infrastructures. If, for instance, you have bought a VPS in 2013 from you favorite provider, you might be in one of these two situations: either the VPS has been migrated in those 2 years on a new infrastructure, or, probably, it will suffer from all the problems of an infrastructure that is obsolete and completely saturated. Cloud Providers, indeed, tend to fill the infrastructure they create one after another: if you are so lucky to be among the firsts on a new infrastructure that is still “empty” you will experience good results, especially if the provider is less sophisticated and doesn’t implement specific technologies to limit the performances of each VPS.
As the resources of that infrastructure are saturated, the performances will diminish: if the cloud providers guarantees certain pnumbers, then this limit won’t affect significantly your VPS, however if the cloud provider has an overselling policy the situation will get radically worse once the infrastructure is almost filled. Obsolescence will sum to this problem: inevitably the older infrastructures should be replaced every 3, 4 or 5 years with a better and faster one. When buying a VPS for instance you’ll end up on a newer and less-filled infrastructure, however if you keep your older one, that one will remain on an obsolete and overloaded hardware.
Keeping that in mind, you should favour the solutions that allow an easy migration between different datacenters or the backup of the virtual disk as an image and the creation of a VM from this very same image.
It’s up to you, before purchasing, what to decide to do.
For evaluating disk performances, you can use the tips in this article. As a rule of thumb you should choose specific benchmark softwares and not simple tests based, for example, on dd on Linux. Some data can misbehave because of the cache of the operative system or of the storage devices.
Every test you’ll perform must be repeated at different hours and in different days because it is strictly related to the overall workload of the whole infrastructure of your cloud provider.
If you run the same test on an on-premises infrastructure, then you’ll know exactly what is going on and what can invalidate your tests. You don’t have a clue of what the situation is on a multitenant infrastructure. If you are implementing an on-line shop it could be very bad if, for instance, performances are heavily impacted at a certain hour of the day: you may even lose some sales! Therefore use Cron in Linux or Task Scheduler in Windows to run benchmarks at every hour of the day, in different days too, to see how your VPS behaves.
Another important performance parameter is the connectivity. Perhaps not everybody is aware that the famous SpeedTest.net that is used to evaluate the connection quality from a browser can be easily used from the command line: the instructions are availabe at this link (https://github.com/sivel/speedtest-cli), you can download and perform the script with these commands:
wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest_cli.py
chmod +x speedtest-cli
You can then evaluate the actual connection speed of the VPS and have a valid reference apart from what the provider declares.
There are some all-embracing interesting tests that can be performed on the VPS to obtain an array of data in a single panel. The most famous is Serverbear.com: this website collects data from tests run by users and compares them using some handy tables and filters. Data must be interpreted cum grano salis: it is provided by third party users and it may not be always accurate. Serverbear.com includes several tests on CPU, I/O (including the excellent FIO) and network connectivity with a list of servers placed everywhere in the world. The execution is very simple and you may not publish the results by using the dedicated function in the panel.
Tests may require some hours depending on the speed of the VPS and connectivity: at the end you will receive a detailed report by email.
Another important test is about the overall reliability of the infrastructure and of the service. You can monitor up to 50 different service with a delay of up to 5 minutes with a service like Uptime Robot (www.uptimerobot.com). All you need is that the VPS hosts whatever Web server service: after the configuration is complete you will receive an email every time the service is not responding or is sending an error (i.e. if the database is down).
Another reliability index is CloudSquare by CloudHarmony (https://cloudharmony.com/status). It offers a lot of stats about the biggest worldwide providers including data on availability and total downtime minutes for every service. Unfortunately is doesn’t include all the service providers, only the bigger ones, nonetheless it’s a great point of reference, at least for them.
If you happen to make some interesting discovery thanks to our advices please let us know using our social channels!