Что лучше для веб-приложения Java: больше ядер ЦП или более высокая тактовая частота?

tldr; Настоящий ответ, вероятно, - «больше ОЗУ», но, поскольку вы задали свой вопрос, ответ, конечно, зависит от обстоятельств. С другой стороны, 32 ядра с частотой 2,5 ГГц почти наверняка превзойдут 8 ядер с частотой 3,8 ГГц - это в 4 раза больше ядер по сравнению с частотой в 1,5 раза выше. Не очень честный бой.

Следует учитывать несколько факторов: время отклика транзакции, количество одновременных пользователей и архитектура приложения.

Время отклика транзакции Если ваше приложение Java отвечает на большинство запросов за несколько миллисекунд, то, вероятно, лучшим вариантом будет наличие большего количества ядер для обработки большего количества одновременных запросов. Но если ваше приложение в основном обрабатывает более длительные и сложные транзакции, оно может выиграть от более быстрых ядер. (а может и нет - см. ниже)

Одновременные пользователи и запросы Если ваше приложение Java получает большое количество одновременных запросов, вероятно, поможет большее количество ядер. Если у вас не так много одновременных запросов, вы можете просто заплатить за кучу дополнительных простаивающих ядер.

Архитектура приложения Эти долго выполняющиеся запросы, о которых я упоминал, не выиграют от более быстрых ядер, если сервер приложений проводит большую часть времени транзакции в ожидании ответов от веб-сервисов, баз данных, kafaka / mq / и т. Д. Я видел множество приложений с 20-30-секундными транзакциями, которые тратят лишь небольшую часть своего времени отклика на обработку в самом приложении, а остальное время ожидают ответов от баз данных и веб-сервисов.

Вы также должны убедиться, что разные части вашего приложения хорошо сочетаются друг с другом. Нет ничего хорошего в том, чтобы иметь 32 или 64 потока, каждый из которых обрабатывает запрос, все выстраиваются в очередь в ожидании одного из 10 соединений в пуле JDBC, также известного как свинья в проблеме Python. Немного планирования и проектирования сейчас сэкономит вам много времени на устранение неполадок производительности позже.

И последнее - какие процессоры вы могли бы сравнивать? Самый дешевый 32-ядерный процессор 2,5 ГГц, который я могу найти, стоит как минимум в 3 или 4 раза больше, чем любой 8-ядерный процессор 3,8 ГГц.

Предполагая, что ваш веб-сервер Java настроен надлежащим образом, вам следует выбрать больше ядер.

По-прежнему существуют зависимости, такие как семафоры, одновременные доступы, которые все еще будут иметь ожидающие потоки, независимо от количества ядер или скорости. Но лучше, когда им управляет ЦП (ядра), чем ОС (многопоточность).

В любом случае, 32 ядра с частотой 2,5 ГГц будут обрабатывать больше потоков и лучше, чем 8 ядер с частотой 3,8 ГГц.

Кроме того, количество тепла, производимого процессором, зависит от частоты (помимо прочего), и это не является линейным. Это означает, что 3,8 ГГц будет выделять больше тепла, чем 3,8 / 2,5 x (необходимо подтвердить на основе ваших точных типов / брендов процессоров ... многие сайты предлагают подробную информацию).

Вы говорите нам, что на выполнение запроса требуется около 100-200 мс, и что это в основном время обработки (хотя трудно отделить то, что является фактическим выполнением процессора от того, что в действительности является доступом к памяти), очень мало операций ввода-вывода, ждет базы данных и др.

Вам нужно будет измерить, сколько времени на самом деле требуется для каждого из двух процессоров, но предположим, что это занимает 150 мс на более медленном процессоре (с 32 ядрами) и 100 мс на более быстром (всего с 8 ядрами).

Тогда первый ЦП сможет обрабатывать до 32 / 0,15 = 213 запросов в секунду.

Второй ЦП сможет обрабатывать до 8 / 0,1 = 80 запросов в секунду.

Итак, большой вопрос: сколько запросов в секунду вы ожидаете? Если у вас нет десятков запросов в секунду, тогда вам не нужен первый процессор, а второй обеспечит более быстрое выполнение каждого запроса. Если вам действительно нужно более 100 запросов в секунду, то первый имеет смысл (или, вероятно, имеет смысл иметь более одного сервера).

Обратите внимание, что это очень скромные оценки. Единственный способ узнать наверняка - протестировать каждый из серверов с реальной нагрузкой. Как указано выше, быстрые процессоры или процессоры с большим количеством ядер могут быстро потерять доступ к памяти. Здесь очень важен размер различных кешей ЦП, а также «рабочий набор» каждого запроса. И это с учетом работы, действительно связанной с процессором, без системных вызовов, без общих ресурсов, без ввода-вывода ...

Как правило, более быстрые ядра лучше, чем большее количество ядер. IE, если два процессора имеют одинаковую цену, пропускную способность памяти и результаты многопоточных тестов, отдайте предпочтение тому, у которого меньше быстрых ядер.

Больше ядер помогает, только если у вас достаточно одновременных запросов.

Более быстрые ядра улучшают общую пропускную способность и улучшить время ответа на каждый запрос.

Предварительное примечание
Я хотел бы второй @PossibleUsefulProbablyNotс определенно полезный ответ.

tldr; Настоящий ответ, вероятно, «больше оперативной памяти».

Особенно этот момент.

Предостережение
Не так уж много админа как такового.
Возможно, больше с точки зрения разработки программного обеспечения.

Нет альтернативы измерению

Что мы знаем
Итак, машина

• собирается запустить (Enterprise?) серверное приложение на основе Java
• публично (в любом случае, в некотором значительном контексте) выставлять HTTP API, обрабатывающий запросы клиентов
• предположительно с какой-либо прикрепленной базой данных
• иначе описывается как не очень сильно привязанный к вводу-выводу
• не полагается на доступность, задержку или пропускную способность сторонних сервисов

Не все то расплывчатое изображение, рисует ОП. Но в то же время далеко не достаточно данных, чтобы дать ответ относящиеся к индивидуальной ситуации ОП.
Конечно, 32 ядра на 2/3 тактовой частоты - это скорее всего работать лучше, чем 1/4 ядер при сравнительно небольшом выигрыше в скорости. Конечно, выделяемое тепло плохо масштабируется при тактовых частотах выше порогового значения 4 ГГц. И конечно, если бы мне пришлось вслепую класть яйца в одну корзину, я бы выбрал 32 ядра в любой день недели.

Что мы не знаем
Все же слишком много.

Тем не мение, Помимо этих простых истин, я бы очень скептически отнесся к гипотетической попытке дать более конкретный и объективный ответ.. Iff это возможно (и у вас есть веские причины оставаться уверенными в том, что количество операций в единицу времени является серьезной проблемой), заполучите оборудование, на котором вы собираетесь запускать систему, измерить и протестировать, от начала до конца.
An обоснованное решение включает соответствующие и правдоподобные данные.

ОП написал: Оперативная память не важна

В подавляющем большинстве случаев память является узкое место.

Конечно, ОП в первую очередь спрашивает о Количество ядер ЦП в зависимости от тактовой частоты и таким образом память оказывается на грани того, чтобы быть не по теме.

Хотя я так не думаю. Мне кажется, что вопрос основан на ложной предпосылке. Не поймите меня неправильно, @OP, ваш вопрос по теме, хорошо сформулирован, и ваше беспокойство очевидно реально. Я просто не уверен, что ответ на вопрос, какой процессор будет работать «лучше» в вашем варианте использования, вообще актуален (для вас).

Почему память важна (для ЦП)

Основная память мучительно медленно.
Исторически сложилось так, что по сравнению с жестким диском мы склонны рассматривать оперативную память как «быстрый тип хранилища». В контексте этого сравнения это все еще верно. Однако в течение последних десятилетий скорости процессоров постоянно росли значительно быстрее, чем производительность DRAM. Это развитие со временем привело к тому, что широко известно как "Процессор-Память-Разрыв".

Разрыв между процессором и скоростью памяти (источник: Карлос Карвалью, Departamento de Informática, Universidade do Minho)

Получение строки кеша из основной памяти в регистр процессора занимает примерно ~ 100 тактовых циклов времени. В это время ваша операционная система будет сообщать об одном из двух аппаратных потоков в одном из 4 (?) Ядер вашей архитектуры x86 как занятый.
Что касается доступность этого аппаратного потока беспокоит, ваша ОС не врет, это занят ожиданием. Однако сам процессор, не обращая внимания на продвигающуюся к нему строку кэша, де-факто простаивает.
Никаких инструкций / операций / расчетов за это время не производилось.

+----------+---------------+---------------------------------------------------------------------------------------------------+
|  Type of |    size of    |                                Latency due to fetching a cache line                               |
| mem / op |     cache     +--------+--------+------------+--------------------------------------------------------------------+
|          |   (register)  |  clock |  real  | normalized |                            now I feel it                           |
|          |               | cycles |  time  |            |                                                                    |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|   tick   |      16KB     |    1   | 0.25ns |     1s     |             Dinner is already served. Sit down, enjoy.             |
|          | *the* 64 Bits |        |        |            |                                                                    |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|    L1    |      64KB     |    4   |   1ns  |     4s     |               Preparations are done, food's cooking.               |
|          |               |        |        |            |                 Want a cold one to bridge the gap?                 |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|    L2    |     2048KB    |   11   |  ~3ns  |     12s    |        Would you be so kind as to help me dice the broccoli?       |
|          |               |        |        |            |    If you want a beer, you will have to go to the corner store.    |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|    L3    |     8192KB    |   39   |  ~10ns |     40s    |    The car is in the shop, you'll have to get groceries by bike.   |
|          |               |        |        |            |             Also, food ain't gonna cook itself, buddy.             |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|   DRAM   |     ~20GB     |   107  |  ~30ns |    2min    |      First year of college. First day of the holiday weekend.      |
|          |               |        |        |            |         Snow storm. The roommate's are with their families.        |
|          |               |        |        |            | You have a piece of toast, two cigarettes and 3 days ahead of you. |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+

Показатели задержки Core-i7-9XX чипы серии (Источник: Скотт Мейерс, 2010 г.)

Нижняя граница Если правильное измерение невозможно, вместо того, чтобы обсуждать соотношение ядер и тактовой частоты, самое безопасное вложение в случае избыточного бюджета на оборудование - это размер кеш-памяти ЦП.

Итак, если память регулярно оставляет отдельные аппаратные потоки простаивающими, то, безусловно, решение - больше ядер?

Теоретически, если программное обеспечение было готово, многопоточность / многопоточность мог быть быстрым

Предположим, вы просматриваете свои налоговые декларации (например) за последние несколько лет, скажем, всего за 8 лет. У вас есть 12 ежемесячных значений (столбцов) в год (строка).

Теперь байт может содержать 256 отдельных значений (поскольку его 8 отдельных двоичных цифр могут принимать 2 состояния каждое, что приводит к 8^2 = 256 перестановки отдельного состояния. Независимо от валюты, 256 кажется немного более низким, чтобы быть в состоянии представлять верхнюю границу цифр заработной платы. Далее, в целях аргументации, давайте предположим, что наименьший номинал («центы») не имеет значения (каждый получает целые целые значения основного достоинства). Наконец, предположим, что работодатель осведомлен о разнице в заработной плате между высшим руководством и штатным персоналом и, следовательно, держит тех немногих избранных в совершенно другой системе бухгалтерского учета.

Итак, в этом упрощенном сценарии предположим, что удвоение вышеупомянутого объема памяти, т. Е. 2 ​​байта (или «полуслова»), при использовании в unsigned форма, т.е. представляющая диапазон от [0, 2^16 = 65536), достаточно, чтобы выразить значения ежемесячной заработной платы всех сотрудников.

Итак, на выбранном вами языке / RDBS / OS вы теперь храните матрицу (некоторая двумерная структура данных, «список списков») со значениями одинакового размера данных (2 байта / 16 бит).
Скажем, на C ++ это было бы std::vector<std::vector<uint16_t>>. Я полагаю, вы бы использовали vector из vector из short в Java тоже.

Теперь вот вопрос о призах:
Допустим, вы хотите скорректировать значения за эти 8 лет с учетом инфляции (или какой-либо другой произвольной причины для записи в адресное пространство). Мы смотрим на равномерное распределение 16-битных значений. Вам нужно будет посетить каждое значение в матрице один раз, прочитать его, изменить, а затем записать в адресное пространство.
Имеет ли значение, как вы собираетесь просматривать данные?

Ответ: да, очень даже. Если вы сначала перебираете строки (внутреннюю структуру данных), вы получите почти идеальную масштабируемость в среде параллельного выполнения. Здесь дополнительный поток и, следовательно, половина данных в одном, а другая половина в другом, будут выполнять вашу работу в два раза быстрее. 4 потока? Прирост производительности в 4 раза.
Однако если вы решите сначала сделать столбцы, два потока будут выполнять вашу задачу значительно медленнее. Вам понадобится около 10 параллельных потоков выполнения только для того, чтобы смягчить (!) Негативный эффект, который только что имел выбор основного направления обхода. И пока ваш код выполняется в одном потоке выполнения, вы не сможете измерить разницу.

+------+------+------+------+------+------+------+
| Year |  Jan |  Feb | Mar  | Apr  | ...  | Dec  |
+------+------+------+------+------+------+------+
| 2019 | 8500 | 9000 | 9000 | 9000 | 9000 | 9000 | <--- contiguous in memory
+------+------+------+------+------+------+------+
| 2018 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 12 * 16Bit (2Byte)
+------+------+------+------+------+------+------+
| 2017 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 3 * (4 * 16Bit = 64Bit (8Byte) 
+------+------+------+------+------+------+------+
| ...  | 8500 | 7500 | 7500 | 7500 | 7500 | 7500 | <--- 3 cache lines
+------+------+------+------+------+------+------+
| 2011 | 7500 | 7200 | 7200 | 7200 | 7200 | 7200 | <--- 3 lines, likely from the same
+------+------+------+------+------+------+------+      virtual memory page, described by 
                                                        the same page block.

ОП написала: а) ЦП с 32 ядрами и тактовой частотой 2,5 ГГц
или
б) ЦП с 8 ядрами, но с тактовой частотой 3,8 ГГц

При прочих равных:

-> Примите во внимание размер кеша, размер памяти, предполагаемые возможности предварительной выборки оборудования и работающее программное обеспечение, которое может фактически использовать распараллеливание, - все это важнее тактовой частоты.

-> Даже без использования сторонних распределенных систем, убедитесь, что вы действительно не связаны вводом-выводом в производственных условиях. Если у вас должно быть собственное оборудование, и вы не можете позволить AWS / GCloud / Azure / Heroku / Whatever-XaaS-IsHipNow справиться с этой болью, потратитесь на твердотельные накопители, на которые вы устанавливаете свою БД. Пока ты делаешь не Если вы хотите, чтобы база данных размещалась на том же физическом компьютере, что и ваше приложение, убедитесь, что расстояние в сети (измерьте задержку здесь) как можно меньше.

-> Выбор известной, проверенной, первоклассной библиотеки HTTP-сервера корпоративного уровня, не вызывающей никаких сомнений и созданной для параллелизма, недостаточен. Убедитесь, что все сторонние библиотеки, которые вы запускаете в своих маршрутах, имеют. Убедитесь, что ваш внутренний код тоже.

Виртуальные машины или облачные решения в этом случае не подходят

Я понял.
Существуют разные уважительные причины.

должно быть а физическая машина [...]
[...] ЦП с 32 ядрами и тактовой частотой 2,5 ГГц

Но это не так уж и много.
Ни AWS, ни Azure не изобрели распределенных систем, микрокластеров или балансировки нагрузки. Более болезненно настроить на голом железе и без ресурсов в стиле MegaCorp, но вы жестяная банка запускайте распределенную сетку кластеров K8 прямо у себя в гостиной. И инструменты для периодических проверок работоспособности и автоматической подготовки при пиковой нагрузке существуют и для проектов с собственным хостингом.

ОП написал: Оперативная память не важна

Вот ~ гипотетический ~ воспроизводимый сценарий: включите zram в качестве пространства подкачки, потому что оперативная память дешевая и не важна, и все такое. Теперь запустите устойчивую задачу с интенсивным использованием памяти, которая точно не приводит к частой подкачке страниц. Когда вы достигли точки серьезной инверсии LRU, ваш вентилятор станет громким, а ядра вашего процессора будут горячими - потому что он занят управлением памятью (перемещением дерьма в своп и обратно).

ОП написал: Оперативная память не важна

Если я недостаточно четко выразился: думаю, вам стоит пересмотреть это мнение.

TL; DR?
32 ядра.
Больше является лучше.