Антипаттерн: выбирать хостинг по тесту скорости из панели

MAATRIX

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

В чём суть антипаттерна

Встречается в двух вариантах, и оба ведут к одному и тому же решению «на глаз, но с цифрами».

Первый — тест на посадочной странице до покупки: провайдер предлагает «проверить скорость до вас» прямо с сайта, показывает график или число, и это число становится главным (а иногда единственным) аргументом в пользу заказа. Второй — тест уже внутри личного кабинета после оплаты: кнопка «Тест диска» или «Диагностика сервера» выдаёт разовый бенчмарк, и клиент воспринимает его как официальное подтверждение качества — «раз панель показывает 900 МБ/с, значит, всё в порядке, можно строить на этом боевую нагрузку».

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

Конфликт интересов: почему тест «от продавца» не может быть объективным

Встроенный тест скорости — не инструмент контроля качества, а инструмент продаж и удержания. Никто в компании, которая зарабатывает на аренде серверов, не ставит инженеру задачу «сделай бенчмарк, который иногда будет показывать нас хуже конкурентов». Такая задача противоречит цели существования этого виджета.

Практический пример: если тест диска в кабинете покажет реальные 150 МБ/с на случайной записи вместо заявленных «до 1 ГБ/с», у провайдера сразу вырастет поток тикетов в поддержку, запросов на возврат и негативных отзывов — по факту того же самого сервера, который вчера ещё «работал нормально», просто пока клиент не смотрел на цифры. Ни один продукт-менеджер не выкатит фичу, которая создаёт себе такую проблему на ровном месте.

Здесь работает тот же принцип, что при любой самопроверке заинтересованной стороны: весы в руках продавца, который сам взвешивает то, что вам продаёт, инспекция, которую заказывает и оплачивает проверяемый, а не независимый контролёр. Формально измерение может быть даже честным — но у вас нет способа это проверить, потому что:

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

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

Что обычно скрыто в методологии таких тестов

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

• Кеш вместо реального I/O. Тест диска часто пишет и читает небольшой файл, который целиком попадает в кеш операционной системы или контроллера — без флага O_DIRECT цифры показывают скорость RAM, а не накопителя. Реальная база данных так не работает: она делает fsync на каждую транзакцию и упирается именно в честную задержку диска.
• Одна точка сети вместо пути до пользователя. Сетевой тест обычно меряет скорость до ближайшего узла самого провайдера или до его CDN-edge — это никак не отражает маршрут до ваших реальных посетителей, у которых может быть третий провайдер, третья страна и третий пиринг.
• Короткое окно измерения. Тест длится несколько секунд — этого достаточно, чтобы показать пиковую производительность burst-кредитов CPU или NVMe-кеша записи, но недостаточно, чтобы увидеть троттлинг под устойчивой нагрузкой, который проявляется через минуты, а не секунды.
• «Тихий» момент измерения. Ничто не мешает тесту фактически идти к отдельному, не разделяемому с боевыми клиентами стенду, либо срабатывать в момент, когда сосед по гипервизору не создаёт I/O-контеншн — вы этого не увидите и не проверите.
• Только средние и пиковые значения. Публикуется одно число «до X МБ/с» или «средняя скорость Y», но не percentile-латентность (p95, p99) и не разброс (jitter) — а именно хвосты распределения обычно и определяют, будет ли приложение «тормозить иногда» под реальными пользователями.

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

Ваша нагрузка — не синтетический тест провайдера

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

Если вы поднимаете сервер под PostgreSQL с интенсивной записью, вас должна интересовать latency fsync на реальном размере транзакции, а не мегабайты в секунду на последовательном чтении. Если это сервер для стриминга видео — важна устойчивая исходящая полоса при сотнях одновременных соединений, а не пиковая скорость до соседнего узла того же дата-центра. Если это API с чувствительностью к задержке (например, WebSocket-бэкенд для реального времени) — критичен p99 отклика под конкурентной нагрузкой, а не средний пинг в спокойный момент.

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

Как тестировать самостоятельно после аренды

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

Диск: случайная запись с обходом кеша.

fio --name=randwrite --ioengine=libaio --rw=randwrite \
    --bs=4k --numjobs=4 --iodepth=32 --size=1G \
    --runtime=60 --time_based --direct=1 --group_reporting

Флаг --direct=1 заставляет обходить страничный кеш ОС — иначе вы измерите скорость оперативной памяти, а не накопителя. Для баз данных дополнительно интересен --rw=randrw со смешанным чтением/записью — это ближе к реальному профилю OLTP-нагрузки, чем чистая последовательная запись.

Сеть: пропускная способность и задержка от вашей точки, а не от узла провайдера.

iperf3 -c ваш-сервер -t 30 -P 4
mtr -rwzbc 100 ваш-сервер

iperf3 с -P 4 гоняет несколько параллельных потоков — так честнее оценивать реальную полосу под конкурентными соединениями. mtr вместо разового ping показывает маршрут и потери на каждом хопе за сотню пакетов, а не одно усреднённое число.

CPU и устойчивая нагрузка.

sysbench cpu --threads=4 --time=120 run

120 секунд, а не 5 — специально, чтобы увидеть эффект исчерпания burst-кредитов, если тариф построен на них, а не на гарантированных ядрах.

База данных — тест на реальном движке и версии.

pgbench -i -s 50 mydb
pgbench -c 20 -j 4 -T 300 mydb

Пять минут теста под конкурентной нагрузкой на той же версии СУБД, что пойдёт в прод, — это гораздо честнее любого универсального диск-теста из панели, потому что учитывает и диск, и CPU, и особенности конкретной базы одновременно.

Приложение целиком: HTTP-нагрузка на реальные эндпоинты.

wrk -t4 -c100 -d60s --latency https://staging.example.com/api/orders

Флаг --latency выводит именно percentile-распределение задержек, а не только среднее — это и есть цифры, которые реально предсказывают поведение под нагрузкой пользователей, а не поведение синтетического файла на пустом диске.

Если возможности расчехлить staging под реальный трафик пока нет, минимальный уровень — прогнать те же fio/iperf3/sysbench на арендованном сервере и на паре альтернативных вариантов у других провайдеров в одинаковых условиях, чтобы сравнивать сопоставимые цифры, а не маркетинговые числа с разных методологий.

Пробный период, реальный трафик и независимые отзывы

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

• Пробный период с частью реального трафика. Если провайдер даёт короткий тестовый доступ или гибкую помесячную оплату без долгого контракта — разверните туда copy проекта и направьте небольшую долю живого трафика (через weighted DNS или балансировщик) на несколько дней, захватив хотя бы один пик нагрузки, а не только тихие часы.
• Смотрите не на пиковые, а на худшие минуты. Устойчивость сервиса определяется тем, что происходит в 95-м и 99-м перцентиле нагрузки, а не в среднем часе. Собственный мониторинг за несколько дней покажет это честнее любого разового теста.
• Отзывы — независимые, а не с сайта провайдера. Отзывы, размещённые в самом кабинете или на посадочной странице провайдера, — тот же конфликт интересов, что и встроенный тест скорости: их отбирают и публикуют те же люди, которые продают услугу. Ищите обсуждения на профильных форумах и в сообществах администраторов, где у автора нет финансовой связи с провайдером. Держите в уме, что заказные отзывы бывают и вне официального сайта — поэтому ценность имеет не один яркий пост, а совпадение независимых мнений из разных источников за разный период времени.
• Читайте договор, а не только маркетинг. Условия возврата, SLA с конкретными компенсациями (а не обещание «99,9% аптайма» без последствий за его нарушение), реальные ограничения тарифа — это тоже часть due diligence, и про подход к сравнению тарифов в целом, а не только по одной цифре, у нас есть отдельный разбор методики сравнения цен на хостинг. Смежная тема — миф о том, что платный хостинг автоматически лучше: дороже не значит объективно проверено, здесь работает та же логика, что и с красивыми цифрами из встроенного теста.

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