Миф: чем выше частота процессора, тем быстрее сайт

MAATRIX

При выборе тарифа взгляд почти всегда цепляется за одну цифру в характеристиках CPU — тактовую частоту. 4.8 ГГц выглядит однозначно лучше, чем 3.2 ГГц, и логика кажется простой: чем выше частота, тем быстрее «думает» процессор, тем быстрее откликается сайт. На практике сервер с более высокой частотой сплошь и рядом не даёт заметного прироста, а иногда даже проигрывает более «медленному» по паспорту. Разбираемся, что частота измеряет на самом деле и почему это далеко не главный параметр для веб-нагрузки.

Откуда берётся миф про мегагерцы

Привычка судить о производительности по частоте родом из девяностых и нулевых, когда Intel и AMD буквально соревновались в гигагерцах, а покупатели десктопов сравнивали процессоры по одной цифре на коробке — тогда это было почти оправдано, потому что архитектуры внутри одного поколения отличались не так сильно, и частота действительно коррелировала со скоростью.

Хостинг-панели и прайс-листы эту привычку только закрепляют: в карточке тарифа частота часто идёт крупным шрифтом рядом с числом ядер, а вот про архитектуру процессора, IPC или тип нагрузки — ни слова. Маркетингово «4.5 ГГц» продаётся проще, чем «современная микроархитектура с высоким числом инструкций за такт» — хотя для реального отклика сайта второе может значить больше.

Есть и рациональное зерно: при прочих равных, на одной и той же архитектуре, более высокая частота действительно ускоряет однопоточные вычисления. Проблема мифа не в том, что частота бесполезна, а в том, что читатели превращают её в единственный и главный критерий, забывая про архитектуру и, что важнее, про характер самой нагрузки.

Что физически измеряет частота

Тактовая частота (ГГц) — это количество тактов процессора в секунду, то есть как часто ядро способно выполнять шаг вычислений. Но такт — не то же самое, что полезная работа: за один такт современный процессор может выполнить одну инструкцию, несколько инструкций параллельно (за счёт суперскалярной архитектуры) или вообще простаивать, ожидая данные из памяти.

Реальную скорость выполнения кода на одном ядре определяет произведение двух величин:

Инструкций в секунду ≈ Частота (тактов/сек) × IPC (инструкций за такт)

Отсюда следует то, что миф игнорирует: два процессора с одинаковой частотой, но разной архитектурой, будут выполнять один и тот же код с разной скоростью — потому что у них разный IPC. И наоборот: процессор с более низкой частотой, но более новой архитектурой и выше IPC, вполне может обходить по факту более «частотный», но старый чип. Подробное сравнение конкретных архитектур — в статье про AMD EPYC против Intel Xeon.

Второй момент — тактовая частота говорит только о скорости вычислений, то есть о времени, которое CPU тратит непосредственно на исполнение инструкций. Но в типичном запросе к сайту вычисления — далеко не единственный и часто не главный этап.

Большинство веб-нагрузок упираются не в CPU

Возьмём типичный запрос к динамическому сайту — открытие страницы каталога интернет-магазина на PHP + MySQL. Цепочка обработки выглядит примерно так:

1. Nginx принимает TCP-соединение          — сеть
2. Передаёт запрос PHP-FPM                  — вычисления (мало)
3. PHP делает запрос к MySQL                — сеть + ожидание ответа БД
4. MySQL читает данные с диска (если не в кэше) — диск
5. PHP собирает шаблон из полученных данных  — вычисления
6. Nginx отдаёт HTML клиенту                — сеть

Из шести шагов реальные CPU-вычисления занимают два — сборку шаблона и разбор запроса, и обычно это доли миллисекунды. Основное же время уходит на ожидание: ответа от диска, ответа от сети, ответа от базы данных. Такая нагрузка называется I/O-bound (упирающейся в ввод-вывод) в противоположность CPU-bound (упирающейся в вычисления), и подавляющее большинство веб-приложений — именно первое.

Пока процесс ждёт ответа диска или сети, ядро процессора физически простаивает — оно не выполняет вычисления быстрее или медленнее, оно вообще ничего не делает по этому запросу. И в этот момент абсолютно неважно, 3 у вас ГГц или 5 — время ожидания одно и то же, оно определяется скоростью диска, задержкой сети или тем, сколько работает сама база данных, а не тактовой частотой CPU. Диагностировать, где реально уходит время, помогает разбивка загрузки на user/system/iowait — подробно она разобрана в статье про то, куда уходит процессор между user, system и iowait.

Практически увидеть это можно так:

# Разбивка нагрузки CPU по типам — если iowait высокий, узкое место не в CPU
top -bn1 | head -5

# Ожидание диска отдельно от вычислительной нагрузки
iostat -x 1 5

# Сколько времени запрос реально проводит в ожидании MySQL
mysqladmin status
mysqldumpslow -s t /var/log/mysql/slow.log | head -20

Если iowait заметно выше нуля во время нагрузки — часть времени CPU буквально бездействует, ожидая диск. В этой ситуации апгрейд частоты процессора не ускорит ни один запрос — деньги стоило бы вложить в NVMe вместо HDD/сетевого диска или в оптимизацию запросов к базе.

Ядра и параллельная обработка запросов

Есть ещё один параметр, который для веб-сервера обычно важнее голой частоты одного ядра — число ядер, точнее способность обслуживать много запросов одновременно. Частота решает, насколько быстро выполнится один конкретный запрос от начала до конца. Число ядер решает, сколько таких запросов от разных пользователей могут выполняться параллельно, не дожидаясь друг друга в очереди.

Если на сайт одновременно заходят сотни посетителей, каждый запрос — это отдельный процесс или поток (PHP-FPM воркер, Node.js-обработчик, поток приложения), и операционная система раскидывает их по разным ядрам. В такой ситуации сервер с 4 ядрами на 4.8 ГГц может захлёбываться в очереди раньше, чем сервер с 8 ядрами на 3.4 ГГц — потому что вторых физических исполнителей просто больше, и очередь короче. Подробный разбор именно этого аспекта — число ядер против частоты для отклика — в статье «Миф: больше ядер — быстрее сайт», она разбирает обратную сторону той же путаницы.

Итого у вас на практике два разных параметра, отвечающих на два разных вопроса:

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

Архитектура и IPC: почему голая частота обманчива

Даже если ограничиться только вычислительной частью запроса (без учёта I/O), сравнивать процессоры по одной частоте всё равно некорректно — потому что архитектуры сильно отличаются по IPC.

Ключевые факторы, влияющие на IPC помимо самой частоты:

• Размер и организация кэша. Чем чаще нужным данным приходится ждать поездки в оперативную память вместо кэша L1/L2/L3, тем больше простаивает исполнительный конвейер процессора — независимо от частоты.
• Ширина конвейера и число исполнительных блоков. Современные архитектуры способны выполнять несколько независимых инструкций за такт (суперскалярность), старые или упрощённые (например, некоторые энергоэффективные ядра в гибридных чипах) — меньше.
• Предсказание переходов. Ветвления в коде (if, циклы) требуют предсказывать, куда пойдёт исполнение дальше. Ошибка предсказания стоит десятков впустую потраченных тактов — и это никак не отражено в частоте.
• Поколение техпроцесса и микроархитектуры. Процессор на новой архитектуре с частотой 3.2 ГГц во многих реальных задачах обгоняет процессор на архитектуре пятилетней давности с частотой 3.8 ГГц — именно из-за IPC, а не из-за тактов.

Практический вывод: сравнивать процессоры имеет смысл по семейству и поколению (например, конкретное поколение Intel Xeon Scalable против конкретного поколения AMD EPYC), а не по одной цифре ГГц из разных линеек. Точных цифр прироста IPC между поколениями здесь сознательно не приводим — они сильно зависят от конкретной пары моделей и типа кода, и стоит смотреть независимые тесты под свою нагрузку, а не ориентироваться на общие проценты.

Ещё один нюанс, который путает картину: заявленная частота — не то, что процессор держит постоянно. Многие серверные CPU работают в режиме турбо-буста, поднимая частоту на короткое время при низкой загрузке нескольких ядер, но снижая её при полной загрузке всех ядер сразу, чтобы уложиться в тепловой пакет. То есть «максимальная частота в характеристиках» и «частота под реальной нагрузкой всех ядер» — часто разные числа.

Как реально оценивать сервер под свою задачу

Вместо погони за одной цифрой в характеристиках имеет смысл пройти короткую последовательность вопросов.

Шаг 1. Определите профиль нагрузки. У вас много параллельных запросов от разных пользователей (высокая посещаемость, API с множеством клиентов) — или в основном последовательные, тяжёлые по вычислениям операции в рамках одного запроса (генерация отчётов, обработка изображений, шаблонизация больших страниц)? От ответа зависит, что важнее: число ядер или частота/IPC одного ядра.

Шаг 2. Найдите реальное узкое место на текущем сервере, если он уже есть, вместо того чтобы гадать по спецификациям нового:

# Общая картина: сколько CPU занято вычислениями, сколько — ожиданием I/O
vmstat 1 5

# Загрузка каждого ядра отдельно — важно для многопоточных приложений
mpstat -P ALL 1 5

# Что конкретно ест CPU прямо сейчас
htop

# Задержки диска — если высокие await, дело в диске, не в CPU
iostat -x 1 5

Если под пиковой нагрузкой CPU почти не загружен, а страницы всё равно открываются медленно — узкое место не в процессоре вообще, и любой апгрейд частоты будет потраченными деньгами. Если же все ядра загружены под 100% одновременно — вот тогда стоит разбираться, чего не хватает: частоты (обновить архитектуру) или числа ядер (параллелить сильнее).

Шаг 3. Проверьте архитектуру, а не только частоту в характеристиках тарифа. Спросите у хостинга (или посмотрите в описании тарифа) конкретную модель процессора и загляните в её независимые обзоры, если решение критично — сравнение конкретных моделей информативнее одной цифры ГГц. Внутри сервера это же можно посмотреть командой:

lscpu
cat /proc/cpuinfo | grep "model name" | head -1

Шаг 4. Прогоните собственную нагрузку, а не абстрактный тест. Синтетические бенчмарки CPU (sysbench cpu, stress-ng --cpu) показывают только сырую вычислительную мощность, но не учитывают вашу реальную цепочку запросов. Полезнее нагрузочный тест конкретно вашего приложения — например, ab или wrk по реальному URL под ожидаемым числом параллельных клиентов:

# Нагрузочный тест конкретной страницы: 200 запросов, 20 параллельно
ab -n 200 -c 20 https://ваш-сайт.ru/catalog/

# То же через wrk с более гибкими настройками
wrk -t4 -c50 -d30s https://ваш-сайт.ru/catalog/

Смотрите не только на среднее время ответа, но и на распределение (перцентили p95/p99) — они честнее показывают, что почувствует реальный пользователь, чем среднее. Если по итогам теста выясняется, что при добавлении ядер отклик растёт, а частота почти не влияет — это подтверждение, что у вас параллельная, а не последовательная нагрузка, и наоборот. Общая методика расчёта конфигурации под конкретную нагрузку разобрана в статье как рассчитать конфигурацию сервера под нагрузку.

Шаг 5. Не забывайте про диск и сеть при сравнении тарифов. Если профилирование показало, что узкое место — диск, важнее NVMe и его IOPS, чем что-либо в CPU. Для баз данных, где частота тоже играет роль, но далеко не единственную, действует та же логика: сначала профиль нагрузки, потом конкретный параметр железа.

Частые вопросы