Использование расширенной отладки. Часть 1: Определение проблем на сервере

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


Для этого я сделал большой хак, который добавляет в InstantCMS 2 класс, собирающий информацию времени выполнения скриптов и их частей и об основных происходящих событиях при работе системы. Плюс делающий ещё много полезных вещей. Последняя на данный момент версия находится тут "
Класс расширенной отладки для InstantCMS 2.1.2 (v.8) + оптимизация скорости". Там же можно скачать полное описание класса и его настроек.
Будущие версии для новых обновлений Двойки по возможности буду выкладывать в своём блоге.

В основной таблице отладки есть информация по которой можно косвенно судить о работе компонентов сервера. На что обращать внимание:


Суммарное время скрипта — "script time". Показывает суммарное время генерации страницы. В зависимости от компонента страницы и виджетов на ней оно на одном и том же сайте может различаться в два-три раза (по моей статистике, у вас может быть по-другому). Если разброс времени на разных страницах слишком большой (в пять и более раз), значит ваш сервер периодически слишком занят и нужно смотреть "script time" на одной и той же выбранной странице (например, на главной, как самой насыщенной виджетами), обновляя её много раз в разное время. Так можно увидеть или тормозящие отдельные страницы, или тормоза всего сайта.
Например, у меня на старом сервере тестовый сайт открывал главную меньше, чем за 200 мс. Но периодически время подскакивало до 1 и более секунд. Значит сервер в это время был под нагрузкой или на нём тормозили какие-то компоненты. Какие именно — можно выяснить по другим параметрам.

Время работы чисто PHP-части — "php time". Показывает сколько времени было затрачено на загрузку скриптов, их интерпретацию в исполняемый код и выполнение этого кода без учёта обращений к БД и кэшу. Если тут слишом высокое время или слишком большой разброс для одной и той же страницы, отрываемой в разное время — значит или не хватает скорости процессора на сервере, или он чем-то периодически нагружен, или медленная/загруженная файловая подсистема. Уточнить, что проблема именно в файловой подсистеме можно по следующему параметру:

Время на подключение и интерпретацию пхп-скриптов — "includes: — time". Если слишком большой разброс этого времени для одной и той же страницы, значит периодически тормозит доступ к файлам. Если это время достаточно стабильно, а меняется время "php time", значит файловая система работает хорошо, а тормоза связаны с нагрузкой проца.

Время обработки SQL-запросов — "sql time". Обычно на хостинге сервер баз данных вынесен на отдельный физический или виртуальный сервер. Время "sql time" как раз и показывает, как быстро обрабатываются все запросы к БД (суммарно). Если это время для одной и той же страницы в разные периоды её открытия сильно различается, значит тормозит именно сервер БД.

Нужно учесть, что если на вашем хостинге (не на сайте) используется любое кэширование, то первое открытие страницы покажет намного, может быть даже в десять раз большее время, чем все последующие обновления этой страницы. Смотреть нужно как на время первого открытия — это реальное время генерации страницы "по холодному", тут нагляднее видны постоянные проблемы сервера, так и на время после многократного обновления — можно заметить периодические проблемы.

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

Если время в описанных выше параметрах вызывает сомнения или вопросы, то можно выписать их диапазоны изменения и отправить в поддержку хостеру с описанием как вы эти цифры получили. Спецы поддержки посмотрят на своё оборудование, прикинут его производительность и загруженность и дадут свой ответ по реальности этих цифр или работоспособности/загруженности оборудования. Или посмотрят графики загрузки сервера и скажут, что причина тормозов в скриптах CMS. Также, в случае необходимости, используя эти цифры, вы сможете мотивировать хостера на перевод вашего сайта на более быстрый сервер. Вы даже можете временно отключить опцию "Показывать отладочную информацию только администраторам" в настройках отладки, чтобы дать возможность поддержке хостера наглядно увидеть описанные вами проблемы прямо на сайте в цифрах в таблице отладки.


Пример всех этих цифр/параметров на работающем сервере можно посмотреть на моём тестовом сайте
Ссылка закрыта от поисковиков обычной авторизацией.
Имя: tester
Пароль: tester
Сколько будет доступен этот сервер для просмотра — пока не знаю. Сейчас точно можно смотреть.

Это обычный шаровый хостинг с хорошими серверами и включённым кэшированием файловой системы в память. Поэтому первое открытие страницы может быть долгим, а остальные обновления быстрыми. Время открытия главной страницы 70-75 мс — очень хороший результат для навороченной CMS и кучи виджетов на странице. Если много раз обновлять страницу, то можно заметить, что иногда шаровость сервера даёт о себе знать увеличением времени в два-три раза. Но в принципе, всё во вполне допустимых пределах.
На ваших серверах время может быть другим. Например, если на сервере БД не включено кэширование запросов или сервер медленный, то "sql time" будет выше, если ваш сервер БД новый и настроен правильно, то это время может быть меньше.


Если ни на каких страницах ни в какое время не наблюдается каких-то тормозов, но при этом скрытые пхп-скрипты (такие, как сохранение статей и комментариев, загрузка картинок и т.п.) тормозят или даже возвращают ошибку 504, значит дело не в железной/программной части сервера и не в его сильной загрузке. Нужно искать причину в самих этих скриптах сайта. Скорее всего придётся это делать на локалке с влючением профилирования в xDebug или чём-то подобном. Но это уже выходит за пределы данной темы.

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