Миф: бенчмарки провайдера отражают вашу нагрузку

MAATRIX

На странице тарифа — красивая цифра: столько-то очков sysbench, столько-то IOPS, результат geekbench для CPU. Выглядит убедительно, особенно когда нужно быстро выбрать между несколькими провайдерами и нет времени разбираться глубже. Проблема в том, что эта цифра почти ничего не говорит о том, как именно этот сервер поведёт себя под вашим приложением — она измеряет не вашу нагрузку, а лабораторные условия, в которых ваша нагрузка никогда не работает.

Что на самом деле измеряет синтетический тест

Sysbench, geekbench, различные вариации CPU- и IO-бенчмарков на странице тарифа почти всегда запускаются в одном режиме: одна изолированная метрика, короткий прогон, минимум фонового шума. CPU-тест гоняет чистые вычисления — например, разложение простых чисел или криптографические операции — без единого дискового обращения и без сетевого трафика. Дисковый тест пишет и читает блоки заданного размера в один или несколько потоков, но не одновременно с нагрузкой на CPU и не одновременно с сетевым вводом-выводом. Это разумный способ получить сравнимое число: изолированная метрика воспроизводима, её можно поставить в таблицу и сравнить с другим тарифом. Но реальный сервер никогда не работает в режиме «только CPU» или «только диск» — он одновременно принимает соединения, парсит запросы, читает из базы, пишет логи и отдаёт ответ. Синтетический тест по конструкции исключает именно то взаимодействие подсистем, которое и определяет, как быстро отработает ваш код.

Второе искажение — идеальные условия запуска. Тест на странице тарифа почти всегда выполняется на свежей виртуалке сразу после разворачивания, без прогретого кэша приложения, без параллельных процессов пользователя, часто — в конкретный момент, который провайдер выбрал сам (и не обязательно в час пиковой нагрузки на гипервизоре). Результат honest в узком смысле: цифра действительно была получена. Но она — снимок одного благоприятного момента, а не гарантия поведения сервера в произвольный вторник в 19:00, когда параллельно нагружены и соседние виртуалки на том же хосте.

Смешанная нагрузка — это не сумма изолированных метрик

Реальное приложение почти никогда не упирается в одну подсистему. Веб-сервер принимает соединение (сеть) → парсит запрос (CPU) → делает выборку из базы (диск + CPU на стороне СУБД) → сериализует ответ (CPU) → отправляет клиенту (сеть). Каждый шаг конкурирует за общие ресурсы: планировщик CPU распределяет тайм-слоты между процессом веб-сервера, процессом базы и системными демонами; дисковая очередь обслуживает одновременно и чтение данных, и запись WAL, и ротацию логов; сетевой стек тратит CPU на обработку прерываний и TCP-стек параллельно с полезной работой.

Синтетический тест провайдера не воспроизводит эту конкуренцию, потому что специально её исключает — иначе результат перестанет быть сравнимым между тарифами. А значит хороший результат sysbench для CPU ничего не говорит о том, что случится, когда у вас одновременно идёт пиковая выборка из PostgreSQL, фоновая индексация и отдача статики через тот же процесс. На практике узкое место почти всегда возникает на стыке подсистем: диск сам по себе быстрый, но под конкурентной нагрузкой с CPU очередь растёт быстрее, чем показывает изолированный fio-прогон. Как правильно замерить диск честно, отдельно от маркетинговых цифр, — тема статьи про честный замер диска через fio: там же видно, насколько сильно параметры теста (глубина очереди, размер блока, доля записи) меняют итоговое число, и как легко получить «удобный» результат, если тестировать не так, как работает ваше приложение.

Специфика вашего кода и запросов, которую тест не видит

Даже если бы провайдер тестировал смешанную нагрузку, он всё равно тестировал бы не вашу. У каждого приложения — свой профиль:

• Паттерн доступа к данным. Одно приложение делает много мелких случайных чтений (OLTP-нагрузка, точечные выборки по индексу), другое — редкие, но большие последовательные сканирования (аналитика, экспорт отчётов). Разница в характере IO кардинально меняет то, какая метрика диска вообще имеет значение: для первого критична задержка на операцию (latency), для второго — пропускная способность (throughput). Универсального «хорошего IOPS» не существует вне контекста паттерна.
• Соотношение чтения и записи. База с преобладанием записи (очереди, логирование событий, счётчики) упирается в подсистему совсем иначе, чем read-heavy кэш или статический сайт.
• Размер и форма запросов к CPU. JSON-сериализация тысяч мелких объектов, регулярные выражения, шифрование TLS-хендшейков, рендеринг шаблонов — это разные профили нагрузки на процессор, с разной чувствительностью к размеру кэша L2/L3, частоте и числу ядер. Synthetic benchmark вроде geekbench гоняет свой фиксированный набор подтестов, который может вообще не пересекаться по характеру с вашим кодом.
• Конкурентность. Число одновременных соединений, воркеров, потоков — то, что реально определяет, упрётесь вы в CPU, в диск или в лимиты сети раньше. Тест провайдера обычно однопоточный или с фиксированным числом потоков, никак не связанным с реальным числом ваших воркеров nginx/PHP-FPM/приложения.

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

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

Виртуальный сервер почти всегда делит физический хост с другими арендаторами. Даже при честном учёте (cgroups, лимиты CPU-квоты) есть ресурсы, которые сложно изолировать полностью: пропускная способность общей шины к диску, кэш процессора, сетевой аплинк хоста. Когда сосед по хосту внезапно даёт пиковую нагрузку — на вашей виртуалке это может проявиться как рост CPU steal time (время, которое гипервизор не выделил вашей vCPU, потому что отдавал такт другому арендатору) или как просадка дисковой задержки без видимой причины на вашей стороне. Диагностике этого эффекта посвящена статья про steal time как признак того, что сосед ест ваш CPU, а более широкий разбор механики — в материале про шумного соседа на гипервизоре.

Бенчмарк на странице тарифа снимается в конкретный момент на конкретной физической машине с конкретным набором соседей на тот момент. Через месяц состав соседей на хосте, где физически окажется ваша виртуалка (даже у того же провайдера, даже на том же тарифе), может быть совершенно другим. Это не претензия к честности провайдера — это фундаментальное ограничение однократного измерения на разделяемой инфраструктуре: оно говорит о моменте снятия замера, а не о гарантии на будущее. Если вашему приложению критична стабильность задержки (а не только средняя цифра), единственный надёжный способ узнать, что происходит именно на вашей виртуалке, — мониторить steal time и дисковую задержку уже после аренды, на реальном инстансе, под реальной нагрузкой.

Сетевая латентность до ваших пользователей — метрика, которой нет в тесте тарифа

CPU- и IO-бенчмарки на странице тарифа вообще не касаются сети до конечного пользователя — а для многих приложений именно она определяет ощущаемую скорость сильнее, чем производительность процессора. Задержка складывается из физического расстояния до дата-центра, маршрута провайдера до магистральных сетей в регионе пользователей, качества пиринга именно в том городе или стране, откуда приходит ваш трафик. Два сервера с одинаковым результатом CPU-теста могут давать разницу в десятки миллисекунд round-trip time до одной и той же аудитории — просто потому что физически находятся в разных локациях или у провайдеров разное качество маршрутизации до конкретного региона.

Если у вас распределённая аудитория или чувствительное к задержке приложение (API с высокой частотой запросов, real-time сервисы), локация сервера и реальные замеры пинга до нужных регионов важнее любого CPU-бенчмарка. Ориентировочные цифры задержки между популярными локациями и странами пользователей собраны для справки в статье «latency между локациями: таблица ориентиров» — но и это именно ориентиры: точная цифра для вашего маршрута зависит от текущей загрузки магистральных каналов и меняется со временем, поэтому финальную проверку стоит делать самостоятельно, замером с реальных точек, откуда приходят ваши пользователи.

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

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

1. Разверните staging-копию реального стека, а не тестовый «hello world». Тот же веб-сервер, та же СУБД, тот же набор фоновых процессов (очереди, кэш, крон-задачи), что и в проде — иначе тест снова измеряет что-то другое.
2. Соберите реальный профиль запросов, а не произвольный синтетический трафик. Лучший источник — логи прод-сервера: реальное распределение по эндпоинтам, реальное соотношение чтения и записи, реальные размеры payload. Инструменты вроде wrk, k6, ab, hey для HTTP-нагрузки и pgbench/sysbench с кастомным Lua-скриптом для баз данных позволяют воспроизвести не абстрактный, а конкретно ваш паттерн — если задать им реальные параметры, а не значения по умолчанию.
3. Нагружайте параллельно, а не по одной метрике. Гоняйте HTTP-нагрузку и одновременно смотрите на диск и сеть, а не тестируйте CPU, диск и сеть по очереди в разное время — именно совместная (конкурентная) нагрузка на подсистемы и выявляет реальное узкое место.
4. Тестируйте не с ноутбука разработчика и не из офисной сети. Задержка и пропускная способность канала до генератора нагрузки искажают результат — если инструмент нагрузки стоит в той же сети/локации, что и целевой сервер (или в облаке рядом), измерение будет честнее. Частая ошибка нагрузочного тестирования и её последствия разобраны в статье про нагрузочный тест на ноутбуке разработчика — там же видно, как легко получить недостоверные цифры, даже действуя из лучших побуждений.
5. Замеряйте не только среднее, но и хвосты (p95/p99). Средняя задержка может выглядеть отлично, пока 5% запросов не начинают проваливаться в разы медленнее — именно эти хвосты пользователи ощущают как «сайт иногда тормозит».
6. Держите тест достаточно долгим, чтобы поймать колебания. Пятиминутный прогон не покажет эффект шумного соседа, который проявляется раз в час на пике чужой нагрузки. Более длительный прогон (часы, а в идеале — сутки с повтором в разное время) даёт представление не о моменте, а о диапазоне.

Это не значит, что каждому нужен многодневный нагрузочный стенд перед арендой любого VPS — для небольшого проекта разумный компромисс: арендовать сервер, прогнать свой реальный трафик (или его реплику) в течение нескольких дней, посмотреть на метрики CPU/disk/network под реальной нагрузкой, и уже по факту решить, хватает ли ресурсов или нужен апгрейд. Синтетический бенчмарк на странице тарифа в этой схеме — не финальный аргумент, а в лучшем случае повод для первичного сравнения порядка величин между провайдерами, не более того.

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