Сайт медленно работает: как отличить нехватку ресурсов от проблемы приложения
Если сайт тормозит, переход на более дорогой сервер кажется быстрым решением. Иногда он нужен. Но тяжёлый запрос, огромная фотография и зависшее внешнее API требуют разных действий. Начните с конкретной медленной операции, времени её выполнения и сравнения с тем, как она работала раньше.
Сначала определите, что именно тормозит
Запишите адрес и действие: открытие главной, поиск товара, сохранение страницы, оплата или импорт. Проверьте, повторяется ли проблема у другого пользователя, в другой сети и без входа в аккаунт. Учитывайте, что авторизованные страницы часто выполняют другую работу и могут иначе использовать кеш.
Уточните время: всегда, только вечером, во время выгрузки или после определённого обновления. Сопоставьте его с изменением кода, каталога, рекламы, фоновых задач и настроек. Совпадение по времени ещё не доказывает причину, но даёт проверяемую гипотезу.
Сделайте несколько одинаковых измерений с сохранением времени и условий. Единственный медленный запрос на нестабильном мобильном соединении недостаточен для вывода о хостинге. И наоборот: быстрая главная у разработчика не опровергает задержку оформления заказа у покупателей.
Если сайт полностью недоступен, сначала восстановите доступность. Для этого есть порядок проверки недоступного сайта. Здесь разбираем работающий проект, у которого теряется время.
Где теряется время загрузки
В инструментах разработчика браузера откройте вкладку Network, повторите действие и найдите медленный запрос. Смотрите не только документ: ожидание может приходиться на поиск, внешний виджет, картинку или запрос личного кабинета. Для сравнения сохраните одинаковые условия кеша и сети.
-
Шаг 1
Соединение
DNS, сеть и защищённое соединение.
-
Шаг 2
Ожидание ответа
Приложение, база, очереди и внешние вызовы.
-
Шаг 3
Отображение
Файлы, JavaScript и работа браузера.
Измеряйте конкретный запрос. Схема показывает порядок, а не доли времени и не гарантированную причину задержки.
Time to First Byte показывает время до первого байта ответа. В него входят разные этапы, в том числе соединение и ожидание ответа. Это не чистое время выполнения PHP и не полное время готовности страницы. Разбирать показатель нужно вместе с деталями запроса и серверными журналами.
Если ответ документа приходит быстро, но содержимое появляется поздно, проверьте изображения, стили, шрифты и JavaScript. Увеличение RAM сервера не уменьшит уже передаваемую фотографию. Если долго ожидается сам ответ, проверяйте приложение, базу, внешние вызовы и очередь запросов.
Для отправки сведений разработчику можно сохранить сетевой журнал, но сначала удалить из него cookies, токены, личные данные и содержимое чувствительных запросов. Полный HAR-файл не стоит прикладывать в публичный чат поддержки.
Отдельно сравните загрузку через внешний кеш или CDN и непосредственное выполнение приложения, если такая проверка доступна специалисту. Быстрый ответ из кеша может скрывать медленную генерацию страницы. Пользовательские операции всё равно нужно измерять отдельно.
Как читать показатели сервера
Смотрите графики за период проблемы, а не только текущие цифры после её окончания. На виртуальном хостинге попросите показатели и сработавшие лимиты у провайдера. На VPS сопоставьте ОС, процессы и приложение. Нужен интервал с началом и концом медленной операции.
Таблицу можно прокрутить вправо.
| Что видно | Что проверить | Чего пока нельзя заключить |
|---|---|---|
| CPU занят во время операции | Какой процесс работает, есть ли параллельные задачи | Что обязательно нужен сервер с большим числом ядер |
| Процессы завершаются, память на пределе | Сообщения о нехватке памяти, пики и утечки | Что вся занятая память бесполезна: часть может быть кешем |
| Растут задержки диска | Очередь операций, базу, копирование, ограничения площадки | Что надпись NVMe сама по себе устранит причину |
| Много ожидающих запросов | Лимит обработчиков и длительность одного запроса | Что нужно просто запустить больше процессов |
| Сервер свободен, ответ долгий | Внешний API, блокировки, сеть, ожидание очереди | Что проблему решит удвоение RAM |
Свободная и доступная память означают разные вещи: ОС может использовать память для кеша и освобождать её при необходимости. Наличие swap тоже не доказывает постоянную перегрузку. Важны активный обмен, задержки, сообщения об ошибках и связь с поведением приложения.
Проверьте свободное место и число файлов. Рост журналов, временных загрузок или локальных архивов способен исчерпать лимит. Не удаляйте неизвестные каталоги базы и журналы ради быстрого освобождения места. Сначала определяют назначение данных и безопасный способ очистки.
Смысл vCPU, RAM, диска и резерва подробнее разобран в руководстве по ресурсам VPS.
База, кеш и фоновые задачи
Попросите разработчика найти длительные и часто повторяемые запросы. Ошибка может проявляться только на выросшем каталоге или при нескольких одновременных действиях. Полезно сравнить число обращений к базе на одной операции и проверить, нет ли ожидания блокировок.
Изменение индексов и структуры базы проверяют на копии с характерным объёмом данных. Диагностические команды тоже имеют последствия: некоторые режимы анализа действительно исполняют запрос. Запускать незнакомый тяжёлый запрос на рабочей базе ради любопытства не нужно.
Составьте расписание импорта, резервного копирования, пересчётов и массовых отправок. Если они пересекаются, выясните, можно ли изменить график или обработку. Не отключайте копирование без замены только ради красивого графика нагрузки.
Посмотрите состав входящих обращений. Бот, ошибка интеграции или повторяющийся неудачный запрос может создавать больше работы, чем обычные пользователи. Ограничения вводят по наблюдаемому поведению, проверяя, что не заблокированы нужные роботы, оплаты и API.
Кеширование применяют к подходящим данным с понятным сроком актуальности и сбросом. Корзину, права и личную информацию нельзя бездумно отдавать из общего кеша. Проверяйте результат несколькими сессиями и после изменения данных.
Три ситуации с разными причинами
Документ приходит быстро, но первый экран ждёт большие изображения и сторонний скрипт. Проверяют размеры и загрузку ресурсов, выполнение JavaScript и соединение пользователя. Более мощный VPS не исправит все эти задержки.
Главная быстрая, а поиск по определённым условиям долго ждёт базу. Разработчик воспроизводит запрос на копии, проверяет план, объём выборки и блокировки. Тариф меняют, если после исправлений подтверждено ограничение ресурса.
В часы активных заказов одновременно запускается тяжёлый пересчёт. На графике видны очередь и расход памяти. После согласованного изменения графика сравнивают те же операции. Если нагрузка покупателей сама исчерпывает доступные ресурсы, проверяют расширение конфигурации.
В каждом примере важен повторный замер после одного понятного изменения. Одновременная смена тарифа, кеша, версии PHP и плагинов затруднит оценку, что помогло и что сломало другую функцию.
Что отправить разработчику или поддержке
- Адрес, действие и шаги воспроизведения без паролей.
- Время проблемы с часовым поясом, длительность и повторяемость.
- Разницу между обычным и медленным результатом.
- Затронутые сети, устройства и типы пользователей.
- Недавние изменения и пересекающиеся задания.
- Графики и обезличенные фрагменты журналов за нужный интервал.
Сформулируйте вопрос: какой лимит или компонент задержал конкретную операцию? Попросите подтверждение по тому же времени. Так ответ «нагрузка в пределах нормы» можно проверить, а разговор о покупке нового тарифа привязать к наблюдаемому ограничению.
Когда действительно нужен другой тариф
Переход оправдан, когда определён требуемый ресурс или режим работы, нынешняя услуга его не даёт, а выбранная конфигурация проходит проверку. Заложите рост и обслуживание, проверьте возможность изменения ресурсов и возврата. Не выбирайте выделенный сервер только по факту одного медленного вечера.
Для сравнения доступны хостинг для сайтов и VPS. Перенос действующего проекта выполняйте по плану с копией и синхронизацией.