Сколько ресурсов реально нужно сайту с 10 000 посетителей в день

MAATRIX

«Сколько нужно сервера под 10 000 посетителей в день» — вопрос, на который честный ответ звучит неудобно: «зависит». Не потому что кто-то увиливает, а потому что цифра посещаемости в сутки почти ничего не говорит о нагрузке в моменте, а именно момент кладёт сервер. Ниже — методика, как из дневной цифры получить пиковую нагрузку в запросах в секунду и прикинуть под неё конфигурацию, вместо того чтобы гадать или бездумно копировать чужой тариф.

Почему «10 000 в день» — это не характеристика нагрузки

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

• Равномерный трафик (SEO-блог с читателями из разных часовых поясов, RSS-агрегаторы, международная аудитория) — посетители размазаны по 24 часам, пиковая нагрузка отличается от средней не сильно.
• Пиковый трафик (b2b-сайт с посетителями из одного часового пояса и рабочих часов, email-рассылка, пост в соцсети, реклама с ограниченным временем показа) — 60-80% суточного трафика может прийти за 3-4 часа, а внутри этого окна ещё и не равномерно, а всплесками.

Второй сценарий обычно недооценивают: считают "10000 / 86400 секунд = 0.12 запроса в секунду, ерунда", сервер держит и 0.5 vCPU — а потом рассылка утром сажает сайт, потому что реальный пик был не 0.12, а условно 5-8 запросов в секунду в течение часа. Дальше — как это оценить правильно.

Шаг 1: из посещаемости в сутки — в пиковый RPS

Требования к серверу определяет не среднее число посетителей, а пиковое число запросов в секунду (RPS, requests per second) — и не путайте посетителей (уникальных людей) с запросами (каждая загрузка страницы — это HTML + CSS + JS + картинки + шрифты, то есть один визит легко даёт 20-60 HTTP-запросов).

Грубая формула для оценки пикового RPS по визитам в сутки:

Пиковый RPS ≈ (визитов в сутки × коэффициент неравномерности × запросов на визит) / (пиковое окно в секундах)

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

• Коэффициент неравномерности — какая доля суточного трафика приходится на пиковый час. Для равномерного международного трафика — условно 1.5-2x от среднечасового значения. Для трафика с выраженным пиком (одна аудитория, один часовой пояс, реклама/рассылка) — 4-8x, иногда больше при взрывном всплеске (вирусный пост, распродажа).
• Запросов на визит — для лёгкого статического сайта с оптимизированными картинками это может быть 10-20 запросов (HTML + несколько JS/CSS-файлов + шрифты, картинки лениво подгружаются). Для тяжёлой страницы с десятками неоптимизированных изображений — 60-100+.
• Пиковое окно — сколько длится "час пик". Для оценки часто берут именно час (3600 секунд), но внутри часа нагрузка тоже неравномерна, поэтому пиковую минуту или пиковые 10 секунд разумно оценивать с дополнительным запасом (ещё +30-50% к среднему по часу).

Прикидка (это ОЦЕНКА, не измерение) для сайта с равномерным трафиком, 10 000 визитов/сутки, 25 запросов на визит:

Средний RPS по суткам = 10000 × 25 / 86400 ≈ 2.9 запросов/сек
Пиковый RPS (коэффициент ~2x) ≈ 5-6 запросов/сек

Тот же сайт, но с выраженным пиком (коэффициент неравномерности ~6x):

Пиковый RPS ≈ 2.9 × 6 ≈ 17-18 запросов/сек

Разница в 3 раза при одинаковой суточной цифре — вот почему "10 000 в день" само по себе не методика.

Шаг 2: RPS запросов на статику vs RPS запросов к бэкенду

Дальше важно разделить запросы на два типа, потому что сервер обрабатывает их принципиально разными путями:

• Статика (CSS, JS, изображения, шрифты, отданные напрямую nginx без обращения к PHP/Node/базе) — обрабатывается очень дёшево, современный nginx на скромном VPS способен отдавать тысячи таких запросов в секунду, это почти никогда не узкое место.
• Динамика (запрос доходит до PHP-FPM/Node/Python-процесса, часто с обращением к базе данных) — вот здесь и тратится реальный CPU и RAM, и здесь начинаются проблемы.

Практическое следствие: из общего RPS для расчёта ресурсов сервера имеет смысл выделить именно динамический RPS — то есть сколько запросов в пике реально долетает до PHP/приложения/базы, а не долю статики, которую и так раздаёт nginx почти бесплатно (особенно если настроено кеширование в nginx или отдача статики через CDN).

Грубая доля динамических запросов от общего числа HTTP-запросов на страницу:

Шаг 3: тип сайта определяет цену одного динамического запроса

Дальше вопрос не "сколько запросов", а "сколько CPU-времени стоит один динамический запрос" — и здесь разброс между стеками огромный, и это тоже нельзя выдавать за измеренный факт без нагрузочного теста конкретного приложения. Но порядок величины прикинуть можно:

• Статика за nginx (готовый HTML, без бэкенда) — доли миллисекунды CPU на запрос, узким местом почти никогда не становится на любом VPS с 1+ vCPU.
• WordPress с полностраничным кешем (плагин кеширования отдаёт готовый HTML, PHP почти не запускается) — по стоимости близко к статике, PHP-FPM просыпается только на некешируемых запросах.
• WordPress без кеша, каждый запрос через PHP + MySQL — заметно тяжелее: рендеринг шаблона, десятки SQL-запросов, при недостатке OPcache — ещё и компиляция PHP-кода заново. Это тот случай, где медленная админка WordPress и белый экран смерти при нагрузке — типичные симптомы нехватки ресурсов, а не только "плохой хостинг".
• Интернет-магазин (расчёт корзины, проверка остатков, часто внешние API оплаты/доставки) — стабильно самый тяжёлый динамический запрос: обращений к БД больше, транзакции, блокировки строк при одновременных заказах.

Практическое правило, которое подтверждается на практике чаще, чем нет: правильно настроенный nginx+статика на порядок легче, чем неоптимизированный WordPress без кеширования, при одинаковом количестве посетителей. Речь именно про порядок — то есть в разы, а не на проценты. Отсюда и разброс конфигураций ниже.

Шаг 4: от пикового RPS — к vCPU и RAM

Здесь важна оговорка на весь раздел: конкретные числа vCPU/RAM ниже — это ориентировочная методика прикидки, а не результат замера конкретного приложения. Точную цифру для вашего конкретного сайта с вашим кодом, темой/плагинами и запросами дают только реальное нагрузочное тестирование (например, wrk или ab по продовому окружению) — методику измерения без нагрузочного теста подменять нельзя.

Грубые ориентиры на 1 динамический запрос в секунду устойчивой нагрузки (порядок величины, у конкретного стека может отличаться в 2-3 раза в любую сторону):

Ориентировочные конфигурации VPS под 10 000 визитов/сутки в зависимости от сценария (снова: ориентир, не гарантия — берите с запасом и проверяйте реальной нагрузкой после переезда):

• Статический сайт / Hugo / Jekyll, даже с пиковым трафиком — 1 vCPU, 1-2 ГБ RAM обычно с большим запасом. Упереться в лимиты на таком объёме посещаемости почти невозможно, если сайт действительно статический.
• WordPress с настроенным кешем страниц, равномерный трафик — 1-2 vCPU, 2 ГБ RAM. Подробный разбор именно под WordPress — в статье сколько RAM нужно для WordPress.
• WordPress без кеша или с выраженным пиком трафика — 2 vCPU, 2-4 ГБ RAM, и отдельный акцент на настройку кеширования (это обычно даёт больше эффекта, чем добавление ресурсов) — см. ускорение WordPress на слабом VPS.
• Интернет-магазин на 10 000 визитов/сутки — 2-4 vCPU, 4 ГБ RAM как стартовая точка, с готовностью масштабировать при подтверждённом росте нагрузки. Более подробная раскладка ресурсов под магазин — в статье сколько ресурсов нужно VPS для интернет-магазина.

Если сравнивать с похожей методикой для другого типа нагрузки — в материале сколько ресурсов нужно VPS для арбитража трафика разобран тот же подход "от посещаемости к железу", но с другим профилем запросов (много коротких редиректов вместо рендеринга страниц).

Шаг 5: диск и сеть — не забытые, но обычно вторичные факторы

На фоне CPU и RAM диск и сеть на 10 000 визитов/сутки почти никогда не становятся узким местом первыми, но пара нюансов всё же важна:

• Диск: важнее не объём, а тип — SSD/NVMe обязателен, если в связке есть MySQL/PostgreSQL под ощутимой нагрузкой (магазин, WordPress без кеша). На чистой статике диск почти не нагружается после первого чтения — файлы уходят в файловый кеш ОС.
• Сеть: 10 000 визитов/сутки с обычными по весу страницами укладываются в трафик, который есть практически на любом тарифе VPS. Отдельно считать полосу нужно только для тяжёлого медиаконтента (видео, большие галереи) — там объём трафика может стать реальным ограничением тарифа раньше, чем CPU.
• Резерв на пики выше расчётных: любая методика прикидки закладывает "типичный" пик, но реальность иногда даёт всплеск в разы больше (вирусный репост, DDoS-подобная активность ботов, распродажа). Разумный запас — брать конфигурацию на 30-50% выше расчётной, а не впритык.

Как не переплатить и не недооценить: практический алгоритм

Собранная воедино последовательность действий:

1. Оцените коэффициент неравномерности своего трафика — равномерный он (международная SEO-аудитория) или пиковый (одна аудитория, рассылки, реклама). Если есть счётчик аналитики — посмотрите почасовое распределение визитов за последний месяц, это надёжнее любой формулы.
2. Прикиньте пиковый RPS по формуле выше, отдельно выделив динамическую долю запросов (не статику).
3. Определите тип сайта и стек — статика, кешированный WordPress, некешированный WordPress, интернет-магазин — это определяет "цену" одного динамического запроса на порядок точнее, чем сама цифра посещаемости.
4. Возьмите ориентировочную конфигурацию из таблиц выше как стартовую точку, с запасом 30-50%.
5. После переезда/запуска — снимите нагрузку реальным инструментом (wrk, ab, siege) на копии продового окружения, а не на "голом" сервере без базы и плагинов — иначе цифры бессмысленны.
6. Настройте мониторинг (загрузка CPU, память, время ответа PHP-FPM) и корректируйте план по факту, а не по изначальной прикидке — это единственный способ получить не оценочную, а измеренную картину именно для вашего сайта.

Отдельно стоит подчеркнуть: этот алгоритм — методика прикидки для выбора стартового тарифа, а не замена нагрузочному тестированию. Любые конкретные цифры RPS-на-vCPU для вашего кода могут отличаться от ориентиров выше в несколько раз — слишком много переменных (версия PHP, качество кода темы/плагинов, индексы в БД, настройки OPcache и много другого).

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