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

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

Иллюстрация
Для этого я сделал большой хак, который добавляет в 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 или чём-то подобном. Но это уже выходит за пределы данной темы.

Чуть позже, во второй части, опишу как понять что именно вызывает тормоза на отдельных страницах.
0
Loadырь Loadырь 7 лет назад #
Интересно. Ждём вторую часть.
0
Demet Demet 7 лет назад #
Да, отлично описали, еще бы если сделали видео с примерами и объяснениями, было бы просто супер. Спасибо за труды!!!
0
WebMan WebMan 7 лет назад #
Demet, делать видео не вижу смысла. Вроде из текста и так всё понятно.
Могу предложить две вещи:

1. Выкладывайте сюда свои скрины суммарной таблицы с информацией о странице сайта и важных характеристиках сервера. Чтобы люди видели какими бывают цифры в таблице в разных ситуациях и могли сравнить свои с чужими. Да и появится возможность сравнить хостинги и сервера. Кстати, это же поможет при выборе и тестировании нового хостинга для размещения сайтов на Instant CMS 2.
Для этого сделаю три ветки комментариев: для локальных компов, для шарового хостинга и для виртуальных/выделенных серверов.

2. В случаях проблем или непонятнок пишите сюда в камментах диапазоны ваших значений, описанных в топике. Обязательно поясните как вы их получили: какие страницы сайта, сколько раз обновляли страницы для получения значений, какой сервер. Можем их обсудить и поискать ответы на ваши вопросы.
0
WebMan WebMan 7 лет назад #
Ветка для скринов с локального компьютера.

К скрину напишите какая это страница, тип и частоту проца, описание винчестера/SSD, версия вэб-сервера, PHP, MySQL, другие характеристики компьютера по вашему желанию.

Это ветка комментариев не для вопросов по топику! Только для скринов с описаниями и их обсуждений!
Вопросы по теме топика (не по этим скринам) пишите как комментарии к самому топику (ссылка "Добавить комментарий" в самом низу страницы) или как ответ на нужное сообщение (ссылка "Ответить" под нужным вам сообщением в другой ветке).
0
WebMan WebMan 7 лет назад #
""

Главная страница только что установленного и пропатченного Инстанта 2.1.2.
Процессор Intel Core i5 3.4 ГГц, винт со встроенным флэш-кешем, Апач 2.2.3, ПХП 5.3.29, MySQL-сервер 5.0.91 на этом же компе, включённый антивирус Касперского.
0
WebMan WebMan 7 лет назад #
Ветка для скринов с шарового хостинга.

К скрину напишите тип и частоту проца (её можно посмотреть в панели управления хостингом, версия вэб-сервера и PHP, другие характеристики сервера по вашему желанию.

Это ветка комментариев не для вопросов по топику! Только для скринов с описаниями и их обсуждений!
Вопросы по теме топика (не по этим скринам) пишите как комментарии к самому топику (ссылка "Добавить комментарий" в самом низу страницы) или как ответ на нужное сообщение (ссылка "Ответить" под нужным вам сообщением в другой ветке).
0
WebMan WebMan 7 лет назад #

Главная страница только что установленного и пропатченного Инстанта 2.1.2. В отладке включено всё, что только можно, поэтому время отладки "debug time" довольно большое - 20.3 ms (23%).
Shared hosting, процессор Intel Core i5 CPU 760 2.80GHz, HDD RAID (уровень не знаю), Apache 1.3.42, PHP 5.3.28, отдельный MySQL-сервер 5.1.73. Кеширование файловой системы в ОЗУ.
0
WebMan WebMan 7 лет назад #
Ветка для скринов с виртуальных и выделенных серверов на хостинге.

К скрину напишите тип и частоту проца (её можно посмотреть в панели управления хостингом, версия вэб-сервера и PHP, другие характеристики сервера по вашему желанию.

Это ветка комментариев не для вопросов по топику! Только для скринов с описаниями и их обсуждений!
Вопросы по теме топика (не по этим скринам) пишите как комментарии к самому топику (ссылка "Добавить комментарий" в самом низу страницы) или как ответ на нужное сообщение (ссылка "Ответить" под нужным вам сообщением в другой ветке).
0
solitario84 solitario84 6 лет назад #
под 2.2.0 еще не делали?
+1
WebMan WebMan 6 лет назад #
Как раз сейчас этим занимаюсь. Но я хочу глубже просмотреть код системы - может найду ещё резервы для оптимизации. Поэтому процесс займёт больше времени.
0
Loadырь Loadырь 6 лет назад #
WebMan , ещё по возможности, обратите внимание на кэширование. Вылазят ошибки при попытке создать файл кэша, когда такой файл существует.
0
WebMan WebMan 6 лет назад #
Не замечал такого. Ошибка возникает на Вашем сайте с Вашими настройками и компонентами или даже на дефолтном с моей оптимизацией и отладкой? Приведите, пожалуйста, конкретный путь для воспроизведения ошибки: настройки кэша, включена ли отладка и что именно в ней включено, на какой странице происходит ошибка и при каких действиях, какая именно ошибка (полный текст) и где показывается. Попробую воспроизвести у себя.
0
Loadырь Loadырь 6 лет назад #
Ставлю систему 2.1.2. с нуля, копирую файлы расширенной отладки версии 8. В настройках сайта включаю кэширование, по умолчанию метод кэширования Files. А далее захожу на любую статью, или категорию статей. Первый вход выдаёт несколько строк с ошибками
E_WARNING: mkdir() [function.mkdir]: File exists /system/core/cachefiles.php (14). Их количество зависит от страницы, в записях контента их много, в категориях их всего пара. Нажимаю F5 (обновить страницу), сообщения об ошибках пропадают. при повторных обновлениях не появляются, во всё время жизни кэша. По его истечении снова ошибка при первом заходе/обновлении страницы. С мемкэшем такого нет.
0
WebMan WebMan 6 лет назад #
Это не ошибки, это предупреждения.
При работе с файловым кэшем не осуществляется проверка существования директории для кэшируемых данных перед её созданием. Вместо этого используется подавление вывода информационных сообщений об ошибке.
/system/core/cachefiles.php, строка 14:
Код PHP:
  1. @mkdir($path, 0777, true);
Встроенная (дефолтная) система обработки ошибок прекрасно ловит ошибки, но настроена не перехватывать подобные предупреждения, поэтому на сайте "из коробки" их не видно. У моей отладки уровень перехвата ошибок выставлен выше, чем у встроенной. Поэтому отображаются и ошибки, и предупреждения. Это бывает полезно разработчику, поскольку позволяет увидеть мелкие ошибки в логике кода.

Единственный глюк, который я заметил в моей отладке, это то, что при включённом перехвате ошибок PHP некоторые ошибки обрабатываются некорректно и вместо сообщения об ошибке выводится пустая белая страница. Хотя стандартный обработчик ошибок это всё прекрасно вылавливает и отображает (при отключении перехвата ошибок в моей отладке). С этим ещё буду разбираться.
0
solitario84 solitario84 6 лет назад #
отличная новость!..
0
ivanish ivanish 6 лет назад #
А если поставить на 2.2.1 будет работать?
0
WebMan WebMan 6 лет назад #
Отладку для версии 2.1.2 ставить на 2.2.1 нельзя. Я весной начал делать отладку и оптимизацию для новой версии CMS, но, к сожалению, не успел, а сейчас сильно занят. Чуть позже сделаю.

Еще от автора

Хуки-хухуки: Исключаем неактивных пользователей из списков
Как иногда начинают свой монолог неопытные стендаперы: «У всех в жизни было такое …
«Расширенная отладка» для InstantCMS 2.14.1 (v.14.1.2) – большое обновление для разработчиков
Новые возможности и удобства, облегчающие разработчикам отладку компонентов и шаблонов.
Использование расширенной отладки. Часть 11. Анализ ошибок 403/404 и редиректов
Одной из неудобных задач при отладке для меня является поиск причины ошибки 403/404.
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.