Страница иногда отвечает с таймаутом, и её сразу называют медленным SQL. Пока не разделены DNS, соединение, TLS, ожидание первого байта и получение тела, это только гипотеза. Соберите данные, по которым хостинг сможет сопоставить запрос с реальным серверным событием.
Зафиксируйте время и этап отказа
Диагностируйте этап задержки и её повторяемость. Высокое ожидание ответа может иметь несколько причин: приложение, очередь, внешняя зависимость, база или прокси. Назвать конкретную причину позволяют соответствующие логи и профиль, а не один общий замер.
curl предоставляет отдельные временные показатели запроса, которые помогают разделить этапы соединения и получения ответа. Официальная документация.
Запишите точный URL, время с часовым поясом, тип клиента и текст ошибки. «Иногда тормозит» трудно сопоставить с серверным событием. Отметьте, получен ли HTTP-статусили соединение завершилось раньше. Таймаут браузера, прокси и приложения может возникать на разных границах ожидания. Если есть request ID, сохраните его безопасное значение. Для повторного теста выберите несколько обычных запросов с разумной частотой; не создавайте дополнительную нагрузку на проблемную систему. Сначала нужно понять этап и повторяемость, затем проверять предполагаемую базу.
DNS, соединение, первый байт и тело
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| DNS | Разрешение имени | Измерить отдельно | Не SQL по умолчанию |
| TCP и TLS | Подключение | Сравнить этапы | Проверить инфраструктуру |
| Первый байт | Ожидание ответа | Сверить логи | Несколько гипотез |
| SQL или external call | Серверная работа | Нужен профиль | Подтвердить причину |
Разрешение DNS, TCP соединение, TLS рукопожатие, ожидание ответа и получение тела — разные части запроса. Долгая DNS операция не объясняется автоматически медленным SQL. Высокое ожидание первого байта может включать очередь, приложение, внешние вызовы и работу базы. Медленное получение большого тела также отличается от задержки его начала. Сохраняйте временные этапы отдельно и учитывайте повторное использование соединения. Один суммарный показатель не позволяет назвать виновника. Для каждого подозрения укажите, какие дополнительные данные способны подтвердить или опровергнуть его.
Как читать временные показатели curl
Сохраните URL, точное время с часовым поясом, клиент, статус или ошибку и временные этапы запроса. Передайте request id, если он есть. Сопоставьте доступные серверные логи, нагрузку и длительность конкретных запросов CMS.
curl позволяет вывести time_namelookup, time_connect, time_appconnect, time_starttransfer и time_total через write-out. Эти значения описывают временные отметки этапов и не всегда являются независимыми длительностями: для интервалов сравнивают соответствующие разницы. Учитывайте переадресации и режим запроса. Сохраните также http_code и url_effective. Полная HTTP загрузка с переходами может отличаться от одного прямого соединения. Команды и их параметры сверяйте с официальной справкой curl, а результат объясняйте в контексте конкретного запроса. Не выдавайте time_starttransfer за точное время SQL: он охватывает более широкую работу.
Учебное сравнение статического и CMS маршрута
Учебная серия сравнивает быструю статическую страницу и страницу каталога. У обеих одинаково долгое DNS указывает на общий этап; долгий первый байт только каталога требует проверки его серверной работы, но ещё не доказывает медленный SQL.
Учебная серия сравнивает /static.html и /catalog/ на одном хосте. Если DNS долго у обеих, это общий этап. Если соединение быстро, а каталог ждёт первый байт, локализуйте серверную работу его маршрута. Повторите несколько сопоставимых запросов и сохраните время. Разница помогает выбрать логи, но не доказывает конкретный SQL. Каталог может ждать внешний API или очередь приложения. Для теста используйте известные публичные страницы и одинаковый клиент, сохраняя разумную частоту. Не сравнивайте локальную статическую копию с production-каталогом как эквивалентные условия.
Что передать хостингу для сопоставления
Проверяйте найденную гипотезу ограниченным опытом: одинаковый запрос, известный маршрут и сопоставимые условия. Исправление SQL, пула или внешнего вызова выбирают после подтверждения. Затем повторяют исходный сценарий.
Сформируйте короткий запрос хостингу: адрес, время, ошибка, request ID, этапы и частота. Попросите проверить соответствующие access/error логи, очередь приложения, ограничение ресурсов и длительные зависимости. Если доступен профиль CMS, приложите безопасное описание маршрута и наблюдения. Не отправляйте дамп базы, cookies илиключи. Для временного всплеска полезно сопоставление с нагрузкой в ту же минуту, а не текущий спокойный экран панели. Укажите, какой результат требуется: подтверждённая причина и рекомендация на конкретном слое, а не общий совет увеличить тариф.
Когда гипотеза о базе получает подтверждение
Увеличение таймаута может скрыть симптом и увеличить занятые ресурсы. Это отдельная политика ожидания, а не доказанное устранение причины медленного ответа.
Гипотеза о базе подтверждается соответствующим длительным запросом, ожиданием блокировки или другим серверным наблюдением, связанным с проблемным HTTP запросом. Высокий CPU иличисло открытых соединений само по себе не показывает, какой SQL вызывает задержку. Если найден конкретный запрос, сравните план и данные в разрешённом диагностическом режиме, не экспериментируя разрушительными операциями на production. Для внешней зависимости подтвердите её длительность отдельно. Исправление выбирают после связи доказательств: индекс, алгоритм, пул, очередь или политика внешнего вызова. Название предполагаемой причины без такой связи остаётся гипотезой.
Приёмка причины без маскировки таймаута
После правки повторите исходные маршруты и серию в сопоставимых условиях. Запишите успешность, временные этапы и серверное подтверждение изменения. Увеличенный timeout может позволить дождаться ответа, но не устраняет занятость ресурсов и не доказывает ускорение. Отделите это решение от исправления причины. Если нагрузка во время приёмки ниже исходной, укажите ограничение и предусмотренное дальнейшее наблюдение. Итог должен показать, какой этап улучшен, какой механизм подтверждён и что осталось непроверенным. Это помогает хостингу и разработчику продолжать диагностику без ложного диагноза базы.
Критерии завершения проверки
Запросы в контрольной серии завершаются по принятому ожиданию, этап задержки и подтверждённая причина описаны. В отчёте нет диагноза базы без соответствующих серверных доказательств.
- DNS: Не SQL по умолчанию. Зафиксируйте фактический результат и адрес проверенного сценария.
- TCP и TLS: Проверить инфраструктуру. Зафиксируйте фактический результат и адрес проверенного сценария.
- Первый байт: Несколько гипотез. Зафиксируйте фактический результат и адрес проверенного сценария.
- SQL или external call: Подтвердить причину. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: HTTP статус-коды: полный справочник (200, 301, 404, 500...) и Оптимизация Nginx для высоконагруженных сайтов. Отдельные проверки сайта собраны на странице технического аудита reChecker.