223  /  253

Поиск "узких" мест сайта

Просмотров: 4497 (Статистика ведётся с 06.02.2017)
Дата последнего изменения: 31.01.2017

Для оценки производительности необходимо перейти в раздел Монитор производительности (Настройки > Производительность > Панель производительности).

Нажатие кнопки Тестировать производительность позволит вам определить слабые места настройки хостинга. Важно понимать, что цифры в строке Конфигурация могут отличаться в разы при изменении нагрузки на сервер: если нагрузки нет, производительность может быть высокой, если есть – она сможет снизиться. Это связано с тем, что данные цифры показывают скорость открытия пустой страницы сайта и, естественно, зависят от общей загрузки сервера.

Однако далеко не всегда проблема кроется в хостинге - она может быть и в самом сайте. С помощью модуля это можно определить в чем именно проблема и поправить "узкие" места сайта. Для этого требуется запустить тест производительности в течение некоторого времени – для малопосещаемых проектов – час, для посещаемых можно выбрать меньшее время. Система будет фиксировать посещения и собирать статистику о времени выполнения каждой страницы, числе SQL запросов и других параметров.

В случае, если сайт малопосещаемый, рекомендуется самому открывать различные страницы сайта для сбора статистики модуля.

Показатель производительности - величина, обратная времени исполнения ядра продукта (среднему на 10 измерений).

Т.е. в данном примере (Производительность = 19,54) можно сказать, что публичная страница сайта с пустым шаблоном (например, версия для печати), с пустой рабочей областью будет создаваться за 1/19,54 или 0,0512 сек. Если говорить проще, то сервер сгенерирует 19 (пустых, но с подключением ядра) страниц в секунду.

Умножив 19 (страниц в секунду) на 60 получим, что сервер может генерировать около 1140 пустых, но с подключением ядра, страниц в минуту. Так, если посещаемость ресурса составляет всего 1000 человек в день, то производительности сервера будет более чем достаточно. Естественно, в реальных условиях производительность, конечно, будет ниже, в зависимости от "нагруженности" различных страниц сайта, нагрузки на сам сервер и других условий.

Показатель производительности не вычисляется на основе производительности файловой системы, работы базы, сессий и почты. Эти цифры нужны для того, чтобы помочь системному администратору найти узкое место (если такое есть). Величина производительности всегда обратна величине среднего времени отклика.

Закладка «Конфигурация»

В этой закладке отображается текущие показатели производительности подсистем сервера и сравнение их с показателями эталонной системы.

Если какая-то подсистема не удовлетворяет оптимальным условиям, то будет выведена ссылка с рекомендациями по исправлению в колонке Примечание.

Основные ошибки конфигурации:

  • Не установлен акселератор php.
    Наличие акселератора php просто жизненно необходимо, в общем случае без дополнительных настроек страницы открываются в три раза быстрее, во столько же раз снижается нагрузка на процессор. Сегодня можно рекомендовать Zend Server CE - быстрее любого акселератора в два раза. К сожалению, на некоторых конфигурациях он работает нестабильно, тогда ставьте (в порядке приоритета) OPcache, APC, XCache.

    Внимание: eAccelerator не совместим с PHP v5.3+ и больше не поддерживается в продуктах «1C-Битрикс» с версии ядра 15.0.13. Подробнее см. в блоге разработчиков.

  • Включено ограничение open_basedir.
    На shared хостинге сложно отделить клиентов друг от друга, самый простой вариант, который обычно используют: включить open_basedir, тогда на все операции с файлами происходит дополнительная проверка пути. Что существенно снижает производительность. Решением будет использовать свой экземпляр apache для каждого пользователя или установка дополнительных модулей на сервер для ограничения доступа. В случае своего сервера или VPS ограничение open_basedir ставить не нужно! Доступ ограничивается системой для пользователя веб-сервера.
  • Не установлен или не настроен nginx.
    Хоть это напрямую не влияет на оценку производительности, но чрезвычайно важно для нагруженных проектов: вся статика (картинки, стили, ява скрипты) должна отдаваться nginx и не обрабатываться apache. Посмотрите логи доступа apache: там не должно быть ни одного запроса к статике!
  • Не настроена база данных.
    По возможности всегда используйте формат данных InnoDB, рекомендуемые настройки смотрите на странице монитора производительности Сервер БД. Очень полезно также протестировать базу скриптом mysqltuner.pl, который чрезвычайно прост в установке и полезен для оптимальной настройки СУБД MySQL.
  • Стоят не оригинальные драйвера оборудования.
    Особенно актуально для RAID контроллеров: при установке на Linux системах обычно предлагает к установке open source драйвера, которые не всегда достаточно эффективно работают с оборудованием. Всегда ставьте оригинальные драйвера с сайта разработчика.
  • PHP как CGI.
    PHP, запускаемый как CGI (не FastCGI) – плохая схема.
    На каждое обращение к php-скрипту запускается новый процесс интерпретатора PHP. Все это работает очень медленно, производительность сайта будет крайне низкой.

Как читать оценку подсистем

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

  • Конфигурация - собственно, оценка производительности.
  • Среднее время отклика - цифра, обратная оценке производительности.
  • Процессор (CPU). Делается большое число простых математических вычислений. Задача не распараллеливается, поэтому идет оценка работы одного ядра процессора. Когда сайт работает на VPS, здесь часто можно увидеть, что "зажат" процессор.
  • Файловая система. Этот тест показывает не столько работу диска, сколько работу PHP с файлами: создается, исполняется, удаляется большое число простых файлов. Данный показатель зависит от производительности файловой системы и эффективности работы PHP акселератора. В целом хорошо показывает, как работает PHP на данной конфигурации (без учета работы базы).
  • Почтовая система. Отправляется тестовое письмо на hosting_test@bitrix.ru. Содержимое письма: "This is test message. Delete it." Никакая служебная информация не передается! Если настроена отправка почты на cron, этот показатель можно игнорировать.
  • Время старта сессии. Сессия стартует на каждый хит, поэтому это время будет прибавляться к работе каждой страницы. Проблемы обычно возникают, когда меняются настройки хранения сессий PHP так, что скапливаются сотни тысяч файлов сессий.
  • База данных (чтение/запись/удаление). Отправляется большое число простых запросов в базу. Это очень утрированный тест: он не показывает, как база будет работать со сложными запросами на больших объемах данных. Очевидно, что для базы данных на локальной машине цифры будут выше, чем для базы на отдельном сервере. Это нормально.

Закладка «Битрикс»

В этой закладке отображаются текущие настройки продукта, непосредственно влияющие на производительность, с соответствующими рекомендациями для оптимальной настройки.



Закладка «Разработка»

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

Например, ошибкой, которую предлагается исправить, является некэшированнное меню.

Примечание: Для просмотра информации об ошибках используйте ссылку в колонке Ошибки разработки.

Чтобы увидеть причину ошибки, нужно нажать на адрес страницы в колонке 20 самых нагружающих страниц.


Список адресов и статистики выполнения для страницы /catalog/furniture/index.php:

Обратите внимание – на странице /catalog/furniture/index.php находится комплексный компонент Каталог с включенным ЧПУ, поэтому реальные URL для этой страницы – разные. Приведенная таблица отсортирована по уменьшению времени выполнения страницы, и хорошо видно, что если в первый раз страница /catalog/furniture/office открывалась 2 секунды, то в последующие разы – около 0,5 с. При этом наиболее существенно сработало кэширование компонентов, и, как следствие - уменьшение времени на выполнение SQL-запросов.

Проверим, какие компоненты выполняются на этой странице. Для этого необходимо нажать на число в колонке Компоненты нужной страницы. Список компонентов и их характеристики для хита 17 по адресу /catalog/furniture/office.

Здесь мы видим список компонентов, подключаемых на странице, число SQL-запросов из них и тип кэширования. 17 компонент – как раз то некэшированное меню, о котором нам сообщал монитор производительности.

Аналогичным образом мы можем посмотреть список SQL-запросов на этой странице (для данного хита). Однако, как же определить, какое из меню (на странице их 3) не кэшируется, а также причину медленной работы?

Для этого вернитесь на страницу Монитор производительности: хиты и нажмите на ссылку >> перед адресом страницы. Вам откроется сводная статистика по странице. Здесь вы можете увидеть, на каком именно этапе построения страницы сайта затрачивается максимальное время:

Закрыв окно, нажмите на Панели управления кнопку Отладка (Отладка > Суммарная статистика), и вы увидите, что нижнее меню действительно не кэшируется. Кроме того, можно настроить его, выбрав нужный компонент из списка компонентов на странице. Как правило, компоненты расположены на странице в том же порядке, что и на странице диагностики:

Примечание: Подробнее про работу с монитором производительности в публичной части сайта смотрите в уроке Публичная часть модуля.


Закладка «Масштабируемость»

Начиная с версии 10.0 доступен встроенный инструмент тестирования нагрузки многопоточных и веб-кластерных систем.

Монитор производительности

Примечание: Подробнее про инструмент тестирования можно посмотреть в курсе Администратор. Модули, урок Тест производительности.


Что важно знать:
  • Оценка зависит от редакции продукта.
    Раз мы замеряем время работы ядра, очевидно, оно будет зависеть от размера ядра. Для редакции «Бизнес» со всеми включенными модулями оценка всегда будет ниже, чем на «Старте» на том же оборудовании. Эталонная оценка в Мониторе производительности продукта делалась на редакции «Бизнес».
  • Результат зависит от пользовательских функций в /bitrix/php_interface/init.php.
    Указанный файл подключается на каждый хит, в том числе и при работе административной части. Файл /bitrix/php_interface/init.php не должен содержать запросы к БД и любые другие ресурсоемкие операции.
  • Оценка будет меняться в зависимости от нагрузки.
    Чем больше нагружен сервер, тем ниже будет оценка. Но даже при пиковой нагрузке она не должна опускаться ниже приемлемого уровня, чтобы можно было говорить, что сервер справляется (например, не ниже 10 единиц, т.е. 0,1 сек. на страницу).
  • Показатель производительности не показывает возможности масштабирования системы.
    Процесс веб-сервера работает на одном ядре, а значит, когда измеряется производительность без нагрузки, число ядер процессора не влияет на результат. Другое дело под нагрузкой: многоядерная система в состоянии сохранить высокие показатели.
  • Для базы данных на отдельном сервере оценка производительности будет ниже.
    Когда речь идет о кластере, мы имеем масштабируемую систему: при увеличении нагрузки она должна сохранять хорошие показатели. Но при моментальном замере времени открытия страниц без нагрузки мы неизбежно увидим небольшое замедление за счет межсерверных коммуникаций.


12
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии