Как понять, что сайту нужен VPS, и не переплачивать за сервер

Когда сайт начинает тормозить под нагрузкой, самое очевидное решение – взять тариф дороже или сразу перейти на VPS.

Я раньше тоже рассуждал примерно так. Но на практике это не всегда помогает. Сайт может тормозить из-за базы данных, неудачного плагина, фоновой задачи или настроек самой CMS. В таком случае новый сервер увеличит запас ресурсов, но причину проблемы не уберет.

Поэтому я стараюсь сначала понять, во что именно упирается сайт, и только потом решать, нужен ли VPS.

Как понять, что сайт действительно перегружен

Обычно проблема становится заметна раньше, чем владелец открывает мониторинг сервера.

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

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

В такой ситуации я сначала фиксирую простые вещи: сколько было посетителей, какие страницы тормозили, сколько продолжалась задержка и какие ошибки появились. Затем смотрю на CPU, оперативную память, диск и процессы.

Средняя нагрузка за сутки здесь мало что показывает. Сервер может 23 часа работать практически без нагрузки и не справляться с коротким пиком в один час.

Сначала проверяю TTFB

Показатель «страница загружается за две секунды» сам по себе почти ничего не говорит о причине проблемы.

TTFB показывает, сколько времени проходит до получения первого байта ответа от сервера. А полная загрузка страницы зависит еще от изображений, CSS, JavaScript и других ресурсов.

Для первичной проверки мне хватает Chrome DevTools. Открываю Network → Timing и смотрю, сколько времени занимает ожидание ответа сервера.

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

Для дополнительной проверки можно использовать PageSpeed Insights или WebPageTest. Они помогают оценить скорость страницы целиком, но по одному такому тесту нельзя определить, хватает ли проекту ресурсов VPS.

Что происходит с сервером

После браузера я смотрю на сам сервер.

В первую очередь проверяю CPU и оперативную память. Затем смотрю на swap и iowait, чтобы понять, не приходится ли системе активно обращаться к диску.

Отдельно проверяю PHP: нет ли долгих процессов и нехватки worker-ов. После этого смотрю базу данных, логи веб-сервера и ограничения текущего тарифа.

Для быстрой проверки Linux-сервера достаточно htop и vmstat.

В htop можно увидеть процессы и их потребление CPU и памяти. В vmstat я отдельно смотрю на wa – время, которое система проводит в ожидании операций ввода-вывода.

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

Потом открываю логи

Когда сайт тормозит или падает, я стараюсь смотреть логи за тот же промежуток времени.

У веб-сервера интересны ошибки 502, 503, 504 и другие ответы 5xx. В PHP – ошибки выполнения, проблемы с памятью и долгие процессы. Для MySQL и MariaDB можно включить slow_query_log, чтобы увидеть запросы, которые выполняются дольше заданного порога.

Например, long_query_time = 1 позволяет отбирать запросы дольше секунды. Но это не универсальный критерий: для одного сайта такой запрос может быть нормой, а для другого – уже проблемой.

Сам код ошибки тоже ничего не доказывает. 502 означает, что один компонент не получил корректный ответ от другого, 503 – временную недоступность сервиса, 504 – превышение времени ожидания ответа. Чтобы понять причину, эти ошибки нужно сопоставить с процессами, нагрузкой и логами.

Иногда виновата не инфраструктура, а CMS

На этом этапе я обязательно проверяю само приложение.

В WordPress одна из точек для проверки – таблица wp_options. Большой объем данных, которые загружаются автоматически, может увеличивать объем работы при каждом запросе.

Еще одна особенность WordPress – wp-cron.php. В стандартной конфигурации фоновые задачи могут запускаться через обращения посетителей к сайту. На небольшом проекте это почти незаметно, но при большом количестве посещений лишние вызовы тоже становятся нагрузкой.

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

В такой ситуации покупка VPS иногда просто маскирует проблему. Сайт действительно начинает работать быстрее, но тяжелый запрос или неудачный компонент никуда не исчезает.

Когда переход на VPS уже оправдан

После диагностики решение становится гораздо понятнее.

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

Отдельная причина – необходимость в настройках, которых нет на обычном виртуальном хостинге. Например, могут понадобиться Docker, собственные фоновые процессы, определенная версия ПО или полный контроль над окружением.

Есть и экономическая сторона. Для небольшого блога несколько минут недоступности могут вообще не иметь заметных последствий. Для интернет-магазина простой во время рекламной кампании может оказаться дороже самого VPS.

VPS дает больше возможностей, но требует больше работы

Переход на VPS меняет не только объем ресурсов.

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

Например, если диск заполнится логами или после изменения конфигурации перестанет запускаться Nginx, искать причину придется самостоятельно.

При наличии опыта с Linux это не обязательно проблема. При его отсутствии можно использовать панель управления или заказать администрирование. Но эти расходы стоит учитывать еще до переезда.

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13738 тендеров
проведено за восемь лет работы нашего сайта.

Почему четыре ядра не всегда лучше двух

В характеристиках VPS легко зацепиться за количество ядер: четыре кажутся лучше двух, восемь – лучше четырех.

Но сайт может упираться совсем в другой ресурс.

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

Поэтому я стараюсь подбирать конфигурацию не по принципу «чем больше, тем лучше», а отталкиваться от фактического узкого места.

Как я проводил тест

Рабочий сайт сразу переносить на новый сервер я бы не стал.

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

Дальше я повторяю тот сценарий, из-за которого сайт начинает тормозить. Для браузерной части использую DevTools, для сервера – htop и vmstat, для базы – slow_query_log, для нагрузочного сценария – k6.

Задача такого теста не в том, чтобы получить красивую цифру «10 000 запросов в секунду». Гораздо полезнее воспроизвести реальную нагрузку.

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

И еще важный момент: нагрузку безопаснее создавать на копии сайта или в согласованный период.

Что показал мой тест

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

Средняя посещаемость магазина составляла около 2500 человек в сутки. На хостинге в моменты нагрузки TTFB заметно увеличивался, а в логах появлялись ошибки 502 и 504.

После переноса копии сайта на VPS время ответа уменьшилось, а запас по CPU и памяти вырос.

При этом один результат оказался особенно показательным: тяжелые SQL-запросы никуда не исчезли.

На виртуальном хостинге средний TTFB составлял около 1,2–1,8 секунды, а в пик доходил до 8–12 секунд. После переноса на тестовый VPS среднее значение снизилось примерно до 180–250 миллисекунд, а пиковое составило около 650 миллисекунд.

Ошибок 502 и 504 на тестовом стенде во время того же сценария не было. Пиковая загрузка CPU составляла около 40–55% вместо значений около 100% на исходном размещении.

Но количество медленных SQL-запросов осталось прежним – 14.

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

То есть вывод оказался не таким простым, как «VPS быстрее обычного хостинга».

Сколько стоит переход

Цена VPS – это не только строка с арендой сервера.

В моем случае тестовый VPS Cloud4box стоил 1536 ₽ в месяц. Еще 200 ₽ уходило на резервные копии и 470 ₽ – на панель управления.

В итоге расходы без администрирования составляли 2206 ₽ в месяц.

Поэтому сравнивать «хостинг за 450 ₽» и «VPS за 1500 ₽» напрямую неправильно.

На VPS нужно учитывать бэкапы, панель, администрирование и собственное время. Есть еще одна статья расходов – простой. Для коммерческого проекта она иногда оказывается важнее разницы между тарифами.

Что проверить перед переключением сайта

После теста я бы не менял DNS сразу.

Сначала стоит проверить свежую резервную копию, SSL-сертификат, формы, отправку почты, фоновые задачи и интеграции.

Для интернет-магазина я обязательно прохожу весь путь покупателя: каталог, поиск, корзину, промокод, оформление заказа, оплату и отправку уведомлений.

TTL DNS лучше заранее снизить до 300–600 секунд. После переключения стоит несколько часов смотреть логи и мониторинг. Старый сервер тоже не нужно отключать в тот же день – разумнее сохранить его как резерв на несколько дней.

Чек-лист перед переключением

Перед переносом я проверяю несколько вещей.

На тестовой копии должна быть свежая резервная копия файлов и базы данных. Затем проверяю HTTPS и SSL-сертификат, отправку писем через SMTP, работу cron-задач и все основные функции сайта.

У магазина отдельно прохожу весь путь покупателя: поиск, каталог, корзину, применение промокода, оформление заказа и оплату. После этого проверяю интеграции с 1С, CRM, платежными и кассовыми сервисами.

Перед сменой DNS снижаю TTL до 300–600 секунд. После переключения несколько часов слежу за логами и ошибками. Старый сервер сохраняю как резерв на случай непредвиденной проблемы.

Когда VPS вообще не нужен

Иногда лучший результат – ничего не переносить.

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

Не вижу смысла переходить на VPS и в ситуации, когда причина тормозов уже найдена в CMS, базе или коде. Сначала лучше исправить ее и только потом снова оценить нагрузку.

Мой вывод

Теперь перед переходом на VPS я сначала задаю себе один вопрос: какой именно ресурс или компонент не справляется?

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

В моем случае VPS действительно увеличил запас по ресурсам и заметно сократил задержки во время нагрузки. Но при этом те же медленные SQL-запросы остались и потребовали отдельной оптимизации.

Поэтому я бы не покупал VPS только потому, что сайт начал тормозить. Сначала несколько замеров, потом – решение о переезде.