Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


High Core, Low Frequency VS Low Core, High Frequency
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.

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

  • MikeAMikeA Member, Patron Provider

    For web hosting, more cores is almost always better. I'm too busy to describe or Google, maybe someone else can.

  • WSSWSS Member

    Thanked by 2ehab perryoo11
  • @MikeA said:
    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.

  • pbgbenpbgben Member, Host Rep

    @vovler said:

    @MikeA said:
    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.

  • vovler said: 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.

    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

  • GTHostGTHost Member, Patron Provider

    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.

  • FranciscoFrancisco Top Host, Host Rep, Veteran
    edited October 2017

    With shared you can run into a case where you have:

    • MySQL eating a whole thread or two
    • Some bad PHP/SQL queries causing a couple users to burn through their CPU
    • awstats plowing along

    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

    Thanked by 1vimalware
  • 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......................................

  • @vovler said:
    @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.

  • XiNiXXiNiX Member, Host Rep

    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.

  • @Francisco said:
    With shared you can run into a case where you have:

    • MySQL eating a whole thread or two
    • Some bad PHP/SQL queries causing a couple users to burn through their CPU
    • awstats plowing along

    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

    Your $7 = 125GB ssd plan is most confusing mate :p 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.

  • @BecomeWebHost said:

    @Francisco said:
    With shared you can run into a case where you have:

    • MySQL eating a whole thread or two
    • Some bad PHP/SQL queries causing a couple users to burn through their CPU
    • awstats plowing along

    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

    Your $7 = 125GB ssd plan is most confusing mate :p 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.

  • @vovler said:

    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!

    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.

    @vovler said:
    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.

    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.

    @vovler said:
    Doesn't matter how much I think about it 300k shared customers on the same server sounds really bad.

    Never said 300k shared customers on the same server :-) Lol

  • vovler said: I was talking personal hosting for my websites

    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:

    • be able to source compile nginx within 20 seconds
    • be able to source compile clang 4 and clang 5 within 30 minutes if needed
    • be able to backup and compress 30GB of data in less than 2 minutes
    • be able to uncompress and restore 30GB of data in less than 5-10 minutes
    • be able to transfer backup data to remote server at minimum 50-80MB/s
    • for nginx to be able to handle at least 5k concurrent users over HTTP/2 HTTPS at XX cpu utilisation + at XXX memory usage etc
    • for php-fpm to be able to handle at least 300 non-cached requests/s at XX cpu utilisation + at XXX memory usage etc
    • or any combination of the above at certain criteria levels of cpu and memory utilisation.
    • be able to install my Centmin Mod LEMP stack fully within 10-15 mins
    • be able to restore entire server stack, config and site data within 10-30 mins across a cluster of web servers
    • be able to replace a single server within a cluster with newly spun up server, lemp stack and restored site data within 10-30 mins

    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.

Sign In or Register to comment.