При таймауте запишите адрес, точное время и ошибку, затем выясните, на каком этапе закончился запрос. Страница может долго искать сервер, устанавливать соединение или ждать данные приложения. Одной фразы «каталог тормозит» недостаточно, чтобы выбрать между хостингом, CMS и базой.
Таймаут означает, что выбранный клиент не дождался результата за своё время ожидания. Иногда HTTP-ответ уже начался, иногда статус вообще не получен.
Измерьте запрос и сохраните ошибку
Для одного публичного URL разработчик может выполнить:
curl -sS --max-time 30 -o /dev/null \
-w 'DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} FIRST=%{time_starttransfer} TOTAL=%{time_total} HTTP=%{http_code}\n' \
'https://example.com/catalog/'Замените домен своим. Предел 30 секунд выбран для этого примера; это не требование к скорости сайта. Сохраните строку результата и сообщение curl, если запрос прервался. HTTP=000 означает, что инструмент не получил HTTP-статус, а не особый код ответа сервера.
Значения — секунды от начала запроса. Параметры описаны в справке curl. Для чистого разбора начинайте с прямого URL без редиректов: переходы добавляют этапы и затрудняют сравнение.
Разберите, где прошло время
| Поле | Что показывает |
|---|---|
| DNS | Когда завершился поиск адреса сервера |
| TCP | Когда установлено соединение |
| TLS | Когда завершено защищённое соединение HTTPS |
| FIRST | Когда началось получение ответа |
| TOTAL | Когда закончился весь запрос |
Например, получилось DNS=0,02, TCP=0,05, TLS=0,10, FIRST=1,80 и TOTAL=1,90. После установления HTTPS прошло около 1,70 секунды до начала ответа. Загрузка оставшейся части заняла примерно 0,10 секунды. Эти интервалы получены вычитанием соседних отметок, а не сложением всех чисел.
Долгое ожидание первого байта ещё не означает медленный SQL. Приложение может ждать очередь, внешний сервис или базу. Для причины нужны серверные записи именно этого запроса.
Сравните каталог с простой страницей
Проверьте известную простую страницу на том же домене и проблемный каталог одним клиентом. Сделайте несколько отдельных запросов с паузами; не запускайте нагрузочный тест на сайте со сбоем.
Если долго устанавливается соединение у обоих адресов, начинать стоит с подключения и инфраструктуры. Если они подключаются быстро, но только каталог ждёт ответ, передайте разработчику маршрут каталога. Он сможет посмотреть обработку страницы и её зависимости.
Укажите, повторяется ли проблема каждый раз, только после обновления или в определённые часы. Нынешний нормальный ответ не отменяет сбой в прошлую минуту. Важны время исходной ошибки и данные, сохранённые тогда.
Отправьте хостингу сообщение с измерениями
Предположим, каталог не дождался первого ответа. Сообщение можно оформить так:
https://example.com/catalog/ 4 октября в 14:32 МСК завершился таймаутом через 30 секунд, HTTP-статус не получен. Соединение HTTPS установилось за 0,10 секунды. Простая /contacts/ в ту же минуту ответила нормально. Проверьте, пожалуйста, журналы приложения, очередь запросов и ограничения ресурсов для каталога в это время.
Если есть идентификатор запроса, добавьте его. Пришлите текст ошибки и результаты, не требуя заранее «починить SQL». Хостинг должен назвать найденный участок задержки; для базы или внешнего API разработчику понадобятся их собственные измерения.
Повторите проверку после исправления
Запросите тот же адрес тем же способом и сравните ранее медленный этап. Увеличенный таймаут позволяет ждать дольше, но сам по себе не ускоряет страницу. Сохраните причину из ответа поддержки и результат повторной проверки.
Для следующего технического отчёта используйте аудит сайта. Объяснение ответов сервера есть в справочнике HTTP, а серверные настройки — в руководстве по Nginx.