You took the average score from Phronnix openbenchmarking website then multiplied by a ratio of base freq/ to turbo and call that the estimated real case score? Seriously? And we should base buying decisions on that? Well duh faster cores are faster but you didn't show there is any real-world difference in TTFB between say a Sliver 4108 and 9900k.
First - you can tackle TTFB on 2 fronts: hardware and software.
This discussion is mostly for hardware as software brings up a lot more to the table (but will reply to that in a separate post). The assumption is that
@Jaguaras will keep their shop on Wordpress/WooCommerce and changing the platform is not an option.
Second - serving fully cached blog pages (FPC) as static responses compared to Webshop tasks are two totally different beasts. Apache bench results for one Wordpress site we host:
- With FPC: 1.200 reqs/sec (TTFB < 20ms without moving the CPU usage much)
- No-FPC: 11-12 reqs/sec (TTFB > 1.15sec on a i9-9900K pretty much maxing the available cores when PHP workers tuned right).
FPC storage was not even on Redis, but on a Samsung EVO 970+ NVMe. For FPC you do not need a lot of CPU muscles. When you see truly low TTFB (instant loads) it's 99% fully cached or even an amp page.
I compare this task (FPC vs. non-FPC) to 2 math questions:
1. What is "5 x 7"?
2. What is "23.5 x 7845 - 50.58"?
One is a pre-prepared answer that can be answered by a child and is returned almost as a "picture" from memory (the fastest, but also most limited storage like RAM) while the other needs processing. How much time is needed for getting the result? That depends on the "CPU".
Disqussing tradeoffs of FPC and what WooCommerce requires is even more off topic. What is without doubt is that any webshop needs solid non-FPC performance.
My analysis was focused on "
What CPU will process the same PHP code for Non-Cached pages faster" and "all other things equal, what should I get". As you have to run your site on some CPU, it's a good practice to try to pick the best tool for the job.
Chart and table can serve as a framework for PHP processing power as they (imho) show a lot of usefull info:
- Chart puts PHP[CPU] landscape of hundreds of SKUs into some perspective. Going up improves TTFB, going right will add user/requests concurrency. (I decided to size up the bubbles based on cores rather than $$$ as prices of CPUs can vary a lot over time).
- It also puts SKUs into some relative position to each other.
- Nobody should have an issue to say up until sept. 2020 that i9-9900k and its close relatives are the fastest CPUs for PHP. I find it usefull saying to customer "This is the fastest this site can run. Is it good enough or you gonna remove some plugins or open other options?".
- But saying i9-9900K is the single best solution is not entirely correct as there are cases with lots of paralel requests where a high-core count could provide a better AVERAGE TTFB than a single 8/16 CPU. This is not visible from PHPBench scoreboard, but it is from this chart. Finding those break even points on TTFB vs. Paralel reqs. charts will be the next step for some.
-
@amalurk said "You took the average score from Phronnix openbenchmarking website then multiplied by a ratio of base freq/ to turbo and call that the estimated real case score? Seriously?"
Real score will depend on a lot more than just a CPU. But it's an estimate of "processing time required in relative terms among CPUs".
We have been using 3x dual E5-2640, dual E5-2690, E5-1650v4 and i9-9900k for couple of years. PHPBench and Passmark single thread scores were reflected on multiple PHP sites, frameworks, internal benchmarks... PHPBench has its real-life value. But I think this score is only part of the real case story.
I'd be curious if you think it'd better to just take the official PHPBench score and multiply it with core count? Or maybe with a thread count? Maybe with an all-core turbo speed would be better than base, but that number is something Intel started hiding and I am not sure CPU gets to those speeds with short-lasting bursts that PHP requests require. But it is clear that opening freq. is CPUs base freq. That is why WS CPUs feel snappier for PHP websites.
- The table is potentially detecting "trap CPUs" with calculated "Estimated single core PHPBench perf." as some CPUs can look good in synthetic PHPBench benchmark with idle computer running a single core at turbo freq. But its low base clocks can be devastating for TTFB on heavy PHP sites. Xeon Silver 4108 has +56% PHPbench relative to E5-2640, but an estimate single core in "real case" is that it would have only 12% better performance on a busy server. It could be even less than that @1.8GHz. So if you ask should I take Xeon Silver 4108 or 9900K the answer for PHP is to take i9. Even more - never take a Silver or let alone Bronze Xeon for PHP. There are many better and cheaper options for this task.
I do not have the option to test all CPUs. I just tried to make some conclusions how PHP workload operates and how this might affect sites based on the hosting environment.
- It also reveals a bit more what to expect with shared, cheap packages by Webhosting providers. Their interest is more in line with "the most cores for the least electricity (read low freq.)" than "let's provide great TTFB". Partly understandable as one site with unoptimized code and tons of plugins might jam those 4-6 cores for 30sec (difined limited time by server settings) before returning Err message while all other clients will be waiting in queue for the unfit neighbour to finish his turn.
- You can also expect this - once it gets to your turn, it will be closer to 2.5Ghz than 4Ghz. That is significant.
My rules of thumb for a purchase:
- small 4c/8t workstation CPU will very likely perform better that a mid-range 6-10c/12-20t CPU.
- 1 socket, high-end workstation CPU will likely perform better that a dual socketed mid-range server and in ~80%+ cases better than some dual socketed 2x 64/128 low-freq behemoth.
- if you need more than 1 high-end WS CPU, you are probably already thinking about horizontal load-balancing (but this brings developers along as app must be set for it).
- if your SLA and UX goals are based on TTFB, freq. is your base input. If you have lots of paralel cores AND want to provide great TTFB/UX levels, go with load-balancing multiple small & fast servers.
These alone are some low-hanging fruits and money saved.