03-07-2021, 06:00 AM
This post is about my thoughts on the CPU performance as experienced with VirMach's VPS-9, relying on the published data (see Post#5 for a summary.) VPS-9_Dallas and VPS-9_Chicago are skipped given that there is no review on them; VPS-9_Dallas will still be mentioned given the existence of some data posted on it.
The first thing I should mention is that all VPS-9 hosts are using Intel® Xeon® CPU E5-2670 v2 @ 2.50GHz as CPU -that is Buffalo-, Seattle-, L.A.-, Atlanta-, Dallas-based VPS-9 hosts-, except the Phoenix-based VPS-9 host that's instead running an Intel® Xeon® CPU E5-2620 v3 @ 2.40GHz.
All VPS-9 VMs are using the same number of vCPUs, ie TWO. Thus, theoretically, they should all perform the same with a slight edge to Phoenix-based VPS given that E5-2620 v3 is more recent than E5-2670 v2 and has the AVX2 extension available to it!!... But that's not the story that the benchmarks tell, nor is it my own experience as to Phoenix VS. Buffalo's VPS-9 vCPUs. Thus the question becomes: How come ?!...
1- The Elusive Concept of vCPU
Folks tend to think of a vCPU as if it's equal to 1 (physical) core which is obviously FALSE! There is generally no one to one assignment here -except in the case of dedicated cores-, as a SysOperator can squeeze as much as 8 vCPUs per core, if not more. That 's why CPU contention happens when there is too much VMs competing for CPU time or during CPU bursts happening at the same time in those hosted VMs.
In that case the user experience degrades as the VM/VPS will continue to experience stealness for as long as that issue persists. This is the case that I did face when I was using Phoenix-based VPS-9 and this is why, despite having a better host CPU, Phoenix VPS-9 performed on-par or slightly sub-par to Buffalo's.
This issue should also explain the slight disparity between the results of Buffalo- and Seattle-based VPS-9. They both have the same host CPU and both are created through the Host passthrough way (see Post#5), thus should have same flags (see next section to know why that's important.)
Now for the vCPU concept. The right way to think about a vCPU is as a representation of time spent on the host's physical CPU(/pCPU). The Linux scheduler is responsible for dividing that time evenly (unless told otherwise) between all the running VMs. Thus with 2 vCPUs, you can theoretically spend twice as much time as with 1, with the major benefit of concurrency this time.
2- Not all the Extensions/Flags supported by the Host CPU are available to your vCPU
This is the aspect that's least appreciated by our folks in this community despite its importance!..
First of all, there are flags that only make sense inside a physical machine (like acpi) while there are also flags that only exists inside a virtual one (like the 'hypervisor' flag which signals that the machine is running on a hypervisor.)
Besides the above point, the vCPU features allotment (ie the number of flags/extensions that it will contain) is decided early when it's first configured during the VPS creation step. As explained in Post#5, it will depend on the libvirtd CPU Model used to create it; the 'host passthrough' model will be the optimal option to faithfully enable most of the host flags while the 'Named CPU models' will be the worst, especially the basic ones among them, ie qemu64 and cpu64-rhel6 for example.
Given that I now have the flags list of the Atlanta-based VPS-9 which has the cpu64-rhel6 CPU model (thanks to @sohamb03) and the flags list of my Buffalo-based VPS-9 which has its host's CPU model (via host passthrough), the following will be a brief discussion of the consequences of these 2 CPU flag-filtering methods on the resulting vCPU's performance. My only assumption here is that the Atlanta-based VPS-9 host has also the same processor as Buffalo's host -which is almost certain.
Out of the bat, Atlanta's vCPU has 29 flags enabled while Buffalo's has 57 flags/extension enabled. This difference of 28 flags shows the aggressiveness of libvirtd/QEMU in disabling the host's CPU flags in the cpu64-rhel6 named model, given that it's used to offer the least common denominator among widely different real-world CPU models, which is beneficial for Cloud engineers to perform VPSs live migration tasks flawlessly.
But!... from the standpoint of the VPS with cpu64-rhel6 CPU model the performance is quite modest and the reason is quite obvious: there is a list of extremely important flags that are simply absent, as noteworthy examples:
> No aes flag!.. which means no hardware-acceleration for cryptographic tasks (AES encryption/decryption are run in software mode only). Thus all SSL/TLS operations are slow!
The proof here is reported in the geekbench score for AES-XTS (40 with 70.3 MB/sec vs 460 with 803.0 MB/sec in Buffalo's vCPU.)
> No rdrand flag!... which means poor entropy thus poor random number generation capability, which is also important in Crypto task!
> No ssse3, sse4_1, sse4_2, xsave and avx... which are critical in number crunching !
> in addition to other highly important flags critical for security!.. and I will deliberately not list them.
In summary, the point of this post is simply to raise the awareness of our falks here to the need to be more attentive not only to the number of their VPS's vCPUs but also to the stealness they experience during operation (how much it is and how regular..) and, above all, to the featured flags exposed to them by the hypervisor!... It's those enabled flags that ultimately dictate their vCPUs performance.
Okay!.. We're done CPU-wise; next post we'll talk a bit about setting up our VM's storage with libvirtd.
The first thing I should mention is that all VPS-9 hosts are using Intel® Xeon® CPU E5-2670 v2 @ 2.50GHz as CPU -that is Buffalo-, Seattle-, L.A.-, Atlanta-, Dallas-based VPS-9 hosts-, except the Phoenix-based VPS-9 host that's instead running an Intel® Xeon® CPU E5-2620 v3 @ 2.40GHz.
All VPS-9 VMs are using the same number of vCPUs, ie TWO. Thus, theoretically, they should all perform the same with a slight edge to Phoenix-based VPS given that E5-2620 v3 is more recent than E5-2670 v2 and has the AVX2 extension available to it!!... But that's not the story that the benchmarks tell, nor is it my own experience as to Phoenix VS. Buffalo's VPS-9 vCPUs. Thus the question becomes: How come ?!...
1- The Elusive Concept of vCPU
Folks tend to think of a vCPU as if it's equal to 1 (physical) core which is obviously FALSE! There is generally no one to one assignment here -except in the case of dedicated cores-, as a SysOperator can squeeze as much as 8 vCPUs per core, if not more. That 's why CPU contention happens when there is too much VMs competing for CPU time or during CPU bursts happening at the same time in those hosted VMs.
In that case the user experience degrades as the VM/VPS will continue to experience stealness for as long as that issue persists. This is the case that I did face when I was using Phoenix-based VPS-9 and this is why, despite having a better host CPU, Phoenix VPS-9 performed on-par or slightly sub-par to Buffalo's.
This issue should also explain the slight disparity between the results of Buffalo- and Seattle-based VPS-9. They both have the same host CPU and both are created through the Host passthrough way (see Post#5), thus should have same flags (see next section to know why that's important.)
Now for the vCPU concept. The right way to think about a vCPU is as a representation of time spent on the host's physical CPU(/pCPU). The Linux scheduler is responsible for dividing that time evenly (unless told otherwise) between all the running VMs. Thus with 2 vCPUs, you can theoretically spend twice as much time as with 1, with the major benefit of concurrency this time.
2- Not all the Extensions/Flags supported by the Host CPU are available to your vCPU
This is the aspect that's least appreciated by our folks in this community despite its importance!..
First of all, there are flags that only make sense inside a physical machine (like acpi) while there are also flags that only exists inside a virtual one (like the 'hypervisor' flag which signals that the machine is running on a hypervisor.)
Besides the above point, the vCPU features allotment (ie the number of flags/extensions that it will contain) is decided early when it's first configured during the VPS creation step. As explained in Post#5, it will depend on the libvirtd CPU Model used to create it; the 'host passthrough' model will be the optimal option to faithfully enable most of the host flags while the 'Named CPU models' will be the worst, especially the basic ones among them, ie qemu64 and cpu64-rhel6 for example.
Given that I now have the flags list of the Atlanta-based VPS-9 which has the cpu64-rhel6 CPU model (thanks to @sohamb03) and the flags list of my Buffalo-based VPS-9 which has its host's CPU model (via host passthrough), the following will be a brief discussion of the consequences of these 2 CPU flag-filtering methods on the resulting vCPU's performance. My only assumption here is that the Atlanta-based VPS-9 host has also the same processor as Buffalo's host -which is almost certain.
Out of the bat, Atlanta's vCPU has 29 flags enabled while Buffalo's has 57 flags/extension enabled. This difference of 28 flags shows the aggressiveness of libvirtd/QEMU in disabling the host's CPU flags in the cpu64-rhel6 named model, given that it's used to offer the least common denominator among widely different real-world CPU models, which is beneficial for Cloud engineers to perform VPSs live migration tasks flawlessly.
But!... from the standpoint of the VPS with cpu64-rhel6 CPU model the performance is quite modest and the reason is quite obvious: there is a list of extremely important flags that are simply absent, as noteworthy examples:
> No aes flag!.. which means no hardware-acceleration for cryptographic tasks (AES encryption/decryption are run in software mode only). Thus all SSL/TLS operations are slow!
The proof here is reported in the geekbench score for AES-XTS (40 with 70.3 MB/sec vs 460 with 803.0 MB/sec in Buffalo's vCPU.)
> No rdrand flag!... which means poor entropy thus poor random number generation capability, which is also important in Crypto task!
> No ssse3, sse4_1, sse4_2, xsave and avx... which are critical in number crunching !
> in addition to other highly important flags critical for security!.. and I will deliberately not list them.
In summary, the point of this post is simply to raise the awareness of our falks here to the need to be more attentive not only to the number of their VPS's vCPUs but also to the stealness they experience during operation (how much it is and how regular..) and, above all, to the featured flags exposed to them by the hypervisor!... It's those enabled flags that ultimately dictate their vCPUs performance.
Okay!.. We're done CPU-wise; next post we'll talk a bit about setting up our VM's storage with libvirtd.