New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
High Core, Low Frequency VS Low Core, High Frequency
Lets use these cpus as examples :
E3-1270 v6 (4 core, 8 threads, 3.8 GHz, turbo 4.2 GHz) - passmark 11374
E5-2620 v4 (8 core, 16 threads, 2.1 GHz , turbo 3.0 GHz) - passmark 11373
Ignoring power consumption and price, what is the advantage of each processor vs the other. If you had to choose one of them for web hosting which one would you pick, and why?
Comments
For web hosting, more cores is almost always better. I'm too busy to describe or Google, maybe someone else can.
This is exactly what I don't understand. I am not talking about cloudlinux user core limitations here. Why would the e5 be better for web hosting, if both cpu's end up having the same multi-core performance, and the single-core performance is in favor of the e3.
Web servers run on threads, so can easily scale and use 100% of your CPU. I think the multicore low clock are cheaper at scale so thats why they exist.
Webhosting as in taking on paying clients ? Or just for your site ? Passmark isn't 100% indicative of performance especially for linux/web hosting.
You have to look at shared hosting/vps hosting in terms of concurrent user loads and tasks/processes. In most cases, the more cpu threads the better for such as technically you can host more clients and still give them more share of cpu time and straight web/db serving isn't the only task a web hosting server should be concerned about i.e. email/dns and backups/restoration of data etc i.e. compression/decompression tasks and utilising multi-threaded compression algorithms https://community.centminmod.com/threads/compression-comparison-benchmarks-zstd-vs-brotli-vs-pigz-vs-bzip2-vs-xz-etc.12764/
Then there's max supported memory differences between E3 and E5.
But I'd probably bump it up one model from E5-2620v4 to E5-2630v4
These CPUs have the same scores
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E5-2620+v4+@+2.10GHz&id=2766
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E3-1270+v6+@+3.80GHz&id=3014
But with E5 you can get more memory on your server. And more cores better for hosting and VPS.
@GTHost
CPUBENCH is not to be trusted and is extremely unreliable. take what it says as a pinch of salt.
While I'm less critical of bench numbers than some, I'm pretty sure that passmark is not some I'd be much interested in other than to get a vague ballpark figure.
But @Vovler 's question is a good one, albeit one not easy to answer, and it has much in common with benchmark questions.
The "holy ruler" against which to measure is ... tada ... the workload, obviously. After all, we run those servers with a purpose. A server (sw) heavily based on asynchronous IO will run better on lower core count higher clock (lcchc) while most databases and many web servers will run better on hcclc - but: usually it's not the web server itself that needs many cycles but it's rather e.g. the interpreters, VMs (as in e.g. jvm).
Some have brought up max memory, and they are right. Another factor that is quite important in hosting (as it's of a massive nature) is "scenario power" (likely to be close to TDP on a busy server) which is a quite significant part of costs (people colocating know what I mean).
I personally tend to look for mid range frequencies, something around 2.5 GHz. Beyond, say 2.8 GHz processors enter an unattractive range (power consumption is closely related to frequency) and below, say, 2.2 GHz processors tend to get weak, which can be offset by more cores but that doesn't come free (lots of cpu housekeeping, lower bandwidth, etc).
And again: software well designed and built for its purpose is usually by far more relevant for performance than core count and frequency.
With shared you can run into a case where you have:
And now you're stuck with almost no CPU left for anyone else.
While those cores are a bit slower, if someone has some nasty while(true) loop chewing along, you wouldn't want them burning up a 3Ghz+ thread anyway.
You also have things like the E5's will have a lot more cache, on average 2 - 3x more, and way more than that once you get into the 2660+ range.
E3's have their place, shared isn't one of them.
Francisco
The solution is simple, go for E5-2687W v4 - high frequency (3Ghz base) and 12 cores/24 threads :-)
It's pricy, but I know of a few providers that use them heavily in their shared hosting setups :-D
@Zerpy
Oh sure, paying 6x the price of the other 2 processors for about a 2x performance increase is obviously worth it......................................
CPU isn't the only cost in a server, but I guess you're aware of that :-)
I can tell you that much that choosing that specific CPU, when also taking the costs of other parts in a box, the colo costs, power costs, and from a scalability footprint - the numbers actually made sense and over the lifetime of the systems it would save plenty of money.
We're talking deployments for 300k shared-hosting customers - you can also actually do the calculations yourself if you have the actual prices that decent sized datacenters or providers would pay for hardware - then you can see why it actually isn't that expensive after all.
I think for web hosting, Using more cores would makes your server able to handle more requests simultaneously; That means , that more people can access your site at the same time without being slowed down.
The question is if you can spread the workload over the different cores. If you can then more cores are better.
Yes, the cpu is not the only cost of the server. My question was regarding high core count vs low core count, while having the same multi-core performance.
And here you come, suggesting a processor 6x as expensive, while not actually answering the question. That's not the point!
I was talking personal hosting for my websites, but even if I wanted to create some hosting "company", I would never go with a huge server, i'd rather split into smaller ones. Yes, a big one would save money, but splitting into smaller ones would save a lot of headaches.
Doesn't matter how much I think about it 300k shared customers on the same server sounds really bad.
Your $7 = 125GB ssd plan is most confusing mate I ran couple of calculations and figured that is very hard to match with any reputable provider (if you don't have own hardware)
can you share how many people buy $2 vs $4 vs $7. I mean % of each.
They own the hardware but you are asking some really internal data which I don't think anyone would be willing to share.
Actually it does answer the question, you could opt for high core count and high frequency - it has a cost, but it can be very beneficial in so many cases, specially since PHP is single threaded so the faster you process data, the faster you can serve requests of a single core.
At same time a lot of things in MySQL is very single threaded, so high frequency actually makes sense for database servers.
query-caching is single threaded, so having a high concurrency might just end up bottleneck your single threaded query cache - as a result people often tend to disable query caching in certain environments, however this results in MySQL having to do a whole lot more calculations, thus increasing the requirement for a high clock again.
performance (both web but also any other application), it really really depends on your workload, which kind of applications you host, how they interact with MySQL, how all the parts of the systems talk together.
There's simply not a "high core count, low clock" or "high clock, low core count" is the option to go - even for web-hosting.
I've seen providers that would benefit mostly from something like E5-2640 v4 (10 cores, 20 threads at 2.4 Ghz), but also other hosting providers benefitting mostly from E5-1650 v4 (6 cores, 12 threads at 3.6 Ghz)
Generally due to their customer base and the type of applications they hosted - and depending on how many sites you run a server as well.
Some providers need both, so might opt for the more expensive high core count, high clock CPU - because it made sense in their environments.
There's even applications such as Prestashop that can be 1/3 of the loading time on high frequency CPUs compared to load frequency CPUs, and then suddenly you can actually do with 40-50% of the cores as an example, and still have faster loading sites overall.
If I were to design a platform, I'd look at the applications, and select hardware based on what fits the case best.
Splitting into smaller ones would also generate more (different) headaches, both setups come with pros and cons, probably doesn't matter for people that sit with 2-3 servers.
Never said 300k shared customers on the same server :-) Lol
In that case much easier as you have full control and knowledge or your own sites' historic usage requirements, traffic patterns and anticipated future plans. You should be able use that info to decide which is specifically better for your situation and requirements. Shared hosting is slightly different as you do not have the full control or knowledge of your clients usage requirements and past traffic patterns.
There's also some dangers in knowing your own sites' requirements too well. I for one have so many VPS servers these days as I know exactly the hardware requirements I need for a specific web app or site I want to host i.e. many cores vs high clocked cores vs many high clocked cores vs high ram vs high disk i/o performance vs fast network 250Mbps to 1Gbps to 10Gbps vs geographical requirements vs budget and other criterias. Monitoring, data analysis and benchmarking your site and servers is key
Figure out your requirements and benchmark and test
A few examples of some of criterias I may have:
When it's your own sites with full control, it's much easier to know this stuff through testing and past experience and benchmarking
@eva2000 Those requirements are heavily based on how fast you can run some of the commands as well...?
Yeah some of those are task based so whether it's via commands or script automation etc.