Prijava / Registracija
US / USD
For the last decade it was common to hear that light virtualization environments (like Docker and Linux containers) reduce performance by 1-3% compared to a standalone (bare-metal) server (Proxmox installation screenshot). More nuanced statements have that impact at 1-5% for CPU-bound workloads and 5-10% in disk performance.
Though this might be true for some workloads, we've noticed that raw PHP perfomance can drop significantly more (app. -25%) even though we were using the "lightest" form of virtualization - Linux containers.
In the following you can see how we conducted these benchmarks and the results we got on 2 CPUs - Intel XEON E5-1650 v4 and AMD Ryzen 5800X.
This is a leaderboard of the best CPUs in PHP Bench test by Phoronix for a better perception of presented scored and performance hit. Scores around 500.000 are very solid scores and good hosting options. Scores between 700.000-850.000 are elite levels.
Results
Higher is better
Those are 12-25% reductions in PHP processing performance
And that is with most Intel CPU mitigations (Meltdown, Spectre) set to off, privileged LXC container, performance/power mode on server enabled, CPU C-states set to off, great cooling etc. Basically the best case of virtualized scenario.
We started paying more attention to this when our bare metal Xeon E5-1650 v4 server "felt" similarly fast as a LXC container on the fastest single-core Intel CPU at that moment i9-9900K. For comparison: i9-9900K is
- 38% faster in Passmark single thread test and
- 36% faster in PHP Bench on our own tests.
Benchmark on Intel E5-1650 v4
Bare metal result
~/Test/Phoronix# phoronix-test-suite benchmark pts/phpbench System Information PROCESSOR: Intel Xeon E5-1650 v4 @ 3.60GHz Core Count: 6 Thread Count: 12 Extensions: SSE 4.2 + AVX2 + AVX + RDRAND + FSGSBASE Cache Size: 15 MB Microcode: 0xb00002e Core Family: Broadwell Scaling Driver: acpi-cpufreq performance (Boost: Enabled) GRAPHICS: ASPEED Screen: 1024x768 MOTHERBOARD: Supermicro X10SRL-F BIOS Version: 3.1 Chipset: Intel Xeon E7 v4/Xeon Network: 4 x Intel X710 for 10GbE SFP+ + 2 x Intel I210 MEMORY: 4 x 16384 MB DDR4-2400MT/s HMA42GR7AFR4N-UH DISK: Samsung SSD 960 EVO 500GB + 480GB INTEL SSDPED1D480GA + 240GB SAMSUNG MZ7KM240 + 4 x 3001GB HGST HUS724030AL File-System: ext4 Mount Options: errors=remount-ro relatime rw Disk Scheduler: NONE Disk Details: Block Size: 4096 OPERATING SYSTEM: Debian GNU/Linux 10 Kernel: 5.4.78-2-pve (x86_64) Compiler: GCC 8.3.0 Security: itlb_multihit: KVM: Mitigation of Split huge pages + l1tf: Mitigation of PTE Inversion; VMX: conditional cache flushes SMT vulnerable + mds: Vulnerable: Clear buffers attempted no microcode; SMT vulnerable + meltdown: Vulnerable + spec_store_bypass: Mitigation of SSB disabled via prctl and seccomp + spectre_v1: Mitigation of usercopy/swapgs barriers and __user pointer sanitization + spectre_v2: Vulnerable IBPB: disabled STIBP: disabled + srbds: Not affected + tsx_async_abort: Vulnerable: Clear buffers attempted no microcode; SMT vulnerable PHPBench 0.8.1: pts/phpbench-1.1.6 Test 1 of 1 Estimated Trial Run Count: 3 Estimated Time To Completion: 4 Minutes [03:59 CET] Started Run 1 @ 03:55:52 Started Run 2 @ 03:56:29 Started Run 3 @ 03:57:05 PHP Benchmark Suite: 620102 622420 621443 Average: 621322 Score Deviation: 0.19%
LXC Ubuntu 20.04 container on Proxmox result (Intel XEON E5-1650 v4)
PHP Benchmark Suite:
547273
547451
539353
Average: 544692 Score
Deviation: 0.85%
Benchmark on AMD Ryzen 7 5800X
Bare metal result
System Information PROCESSOR: AMD Ryzen 7 5800X 8-Core @ 3.80GHz Core Count: 8 Thread Count: 16 Extensions: SSE 4.2 + AVX2 + AVX + RDRAND + FSGSBASE Cache Size: 32 MB Microcode: 0xa201009 Core Family: Zen 3 Scaling Driver: acpi-cpufreq performance (Boost: Enabled) MOTHERBOARD: Gigabyte B550 AORUS MASTER BIOS Version: F11 Chipset: AMD Starship/Matisse Audio: AMD Cedar HDMI Audio Network: 2 x Intel 82599ES 10-Gigabit SFI/SFP+ + Realtek Device 8125 + Intel Device 2723 MEMORY: 2 x 16384 MB DDR4-3200MT/s CMK64GX4M4B3200C16 DISK: Samsung SSD 960 EVO 500GB + 240GB SAMSUNG MZ7KM240 File-System: ext4 Mount Options: errors=remount-ro relatime rw Disk Scheduler: NONE Disk Details: Block Size: 4096 OPERATING SYSTEM: Debian GNU/Linux 10 Kernel: 5.4.78-2-pve (x86_64) Security: itlb_multihit: Not affected + l1tf: Not affected + mds: Not affected + meltdown: Not affected + spec_store_bypass: Mitigation of SSB disabled via prctl and seccomp + spectre_v1: Mitigation of usercopy/swapgs barriers and __user pointer sanitization + spectre_v2: Mitigation of Full AMD retpoline IBPB: conditional IBRS_FW STIBP: always-on RSB filling + srbds: Not affected + tsx_async_abort: Not affected AMD Ryzen 5800X, Gigabyte B550 AORUS MASTER (F11 BIOS, xmp, pbo) on Proxmox 6.3, Debian 10 PHPBench 0.8.1: pts/phpbench-1.1.6 Test 1 of 1 Estimated Trial Run Count: 3 Estimated Time To Completion: 2 Minutes [17:54 CET] Started Run 1 @ 17:53:44 Started Run 2 @ 17:54:12 Started Run 3 @ 17:54:39 PHP Benchmark Suite: 851360 855004 847252 Average: 851205 Score Deviation: 0.46%
LXC Ubuntu 20.04 container on Proxmox result (AMD Ryzen 7 5800X)
PHP Benchmark Suite:
640924
637823
638814
Average: 639187 Score
Deviation: 0.25%
These results can vary between installations as there are multiple settings on server that can create a significant difference (power states, performance mode, cooling, CPU mitigations,...). But we've measured a 5%+ hit in our own tests with Intel Xeon E5-2640 v1, E5-2690 v1, E5-1650 v4, Intel Core i9-9900K and also in our last test with AMD Ryzen 5800X. So this goes over most Intel architectures from Sandy bridge (2011) to Coffe Lake (2019) and on the newest AMD ZEN 3 (2020).
How is this reflected in real life
Full-page-cache will mitigate slow CPUs and can provide a partial solution for many Wordpress pages with static content. But non-cache-able content like webshop, admin and editing area, stock status, payment processing... requires not just CPU/PHP processing in real-time, but also for it to be finished in 2-3 seconds at most. From our tests with Wordpress and Magento sites we've seen significant improvements by having a different CPU alone.
Thing like these are basically impossible to mitigite from a level of website owner, developer or with a SEO/speed optimization guide. In most cases going for a non-virtualized hosting will not be a viable option if you do not have a server administration in place. But we've seen merchants strongly consider bare-metal installations as these might be a smaller challenge than changing the codebase of a Magento or WooCommerce webshop. Website speed matters dearly in 2020+.
Also consider that:
- Common shared & cheap hosting providers use low-clock CPUs as they sell cores and care about power consumption first. These can easily be 40-50% slower in PHP performance than workstation-like CPUs which are more suitable for PHP workload.
- Pretty much all shared hostings are virtualized so there is this additional 0-25% perfomance hit described above.
So if your "PHP processing power" by a hosting provider was relatively low from the beginning, this additional hit by virtualization will add up to causes of why a webpage (on cheap-as-possible hostings) might be too slow for even a solid user experience.
If you do not have huge ammounts of traffic and lots of concurrent visitors having your website hosted on a common shared hosting basically means you have a ~60-70% "slower processor" compared to one on a specialized hosting or a small dedicated server with a fast CPU (like E3-1270v5, E-2264G etc.). It might result in a server response time of 1sec instead of 2 or 2sec instead of 4. That is a huge difference in UX (user experience), SEO performance,...
by:
Vladimir Mijatović
