Битрикс монитор производительности не считает хиты
В интернете ходят разговоры о том, что Битрикс очень тяжелый и тормозной. Отчасти это так - чем больше используется функционала и чем в большей степени он универсален, тем тяжелее система. И это не зависит от конкретной CMS. Но в большинстве случаев медленная работа сайтов определятся ошибками разработки, плохими настройками хостинга, отдельных компонентов и сайта в целом. Разберем способы выявления проблемных мест.
Сервер
Администрирование - Настройки - Инструменты - Проверка системы. Здесь не должно быть значений выделенных красным цветом.
Администрирование - Настройки - Производительность - Сервер БД. Здесь не должно быть значений выделенных красным цветом.
Администрирование - Настройки - Производительность - Панель производительности - Вкладка Конфигурация - Тестировать конфигурацию. Здесь стоит обратить внимание на параметры ниже эталонных. Среди прочих в таблице есть строка "Конфигурация" в которой отображаются некие битрикс-попугаи они сильно зависят от сервера, а от Вашего проекта единственное, что может негативно повлиять, это плохо организованный init.php. Для серверов с PHP 5.6 и ниже этот показатель ниже 30 - признак плохо сконфигурированного сервера, для PHP7 и выше плохой уровень уже около 50 битрикс-попугаев.
Администрирование - Настройки - Производительность - Панель производительности - Вкладка Битрикс. Здесь не должно быть написано "Не оптимально"
Администрирование - Настройки - Производительность - Панель производительности - Вкладка Масштабируемость. Запустите тестирование. Показатели сильно зависят и от сервера и от качества разработки вашего проекта. Здесь обратите внимание на график. Если график имеет много глубоких провалов - это, скорее всего, показатель не качественного хостинга.
Настройки сайта
Администрирование - Настройки - Настройки продукта - Настройки модулей - Главный модуль - блок "Оптимизация CSS". Желательно, чтобы были включены все опции. Как правило, их отключают если в скриптах есть косяки. После включения проверьте работу функционала сайта.
Администрирование - Настройки - Настройки продукта - Автокеширование. Кеширование компонентов и управляемый кеш должны быть включены. Отключением этого функционала некоторые горе-разработчики скрывают ляпы разработки. Если вам разработчик заявляет "этот функционала сырой, глючный и ненужный", то сразу гоните его от своего проекта - это дилетант. Кеш не нужен только в одном случае - весь контент вашего сайта ежесекундно полностью изменяется. После включения проверяйте сайт - заходите по несколько раз на каждый тип страниц и смотрите весь ли контент на месте (включая заголовки страницы, meta-теги).
Администрирование - Настройки - Настройки продукта - Композитный сайт - Настройки. Этот функционал желательно включать. Иногда при включении проявляются косяки верстки (например не закрытые теги).
Модули
Данный блок лучше тестировать на копии сайта и перед повторением на боевом - не забывайте выполнять резервное копирование.
Администрирование - Настройки - Настройки продукта - Модули. При развертывании Битрикс активирует все модули, чтобы сразу работал весь функционал. На конкретном проекте некоторые модули могут не использоваться. На этой странице можно отключить не нужны. Только проверяйте работоспособность после отключения или пропускайте если не уверены в назначении.
Администрирование - Marketplace - Установленные решения. Здесь так же могут быть лишние модули, особенно на проектах с историей где сменилось много разработчиков. Оставшиеся модули так же стоит оценить на качество кода. К сожалению встречаются написанные крайне безграмотно.
Настройки компонентов и выявление тяжелых
Режим отладки. В публичной части сайта, авторизовавшись пользователем с правами администратора. На панели инструментов Битрикс нажмите "Отладка". Около каждого компонента и для все страницы будет отображено время выполнения и количество запросов. Запросы можно просмотреть. После этого сбросить кеш (кнопкой на панели), и опять оценить параметры. В первом случае, данные берутся из кеша, во втором кеш создается. Следовательно, тут можно оценить настройку кеширования. В первом случае запросов должно быть на страницу значительно меньше ем во втором. На компоненты с большим числом запросов и временем исполнения следует обратить внимание.
Тестирование производительности
Администрирование - Настройки продукта - Настройки модулей - Монитор производительности. Включаете Вести журнал медленных запросов, предупреждения PHP. Запускаете тестирование чем дольше тем лучше - главное чтоб посетители были и сами пройдитесь по всему сайту. По прошествии времени можно оценивать результаты.
Администрирование - Настройки - Производительность - Индексы - Анализ индексов. Здесь собраны запросы для которых существуют индексы или система посчитала эти индексы полезными. По клику на каждой строке можно перейти в детальный анализ запроса. Там можно посмотреть как индекс система предлагает создать и какое время без него. Вы можете его создать либо указать, чтоб система больше не предлагала. Если вы не разбираетесь в этом: можете создавать индекс и сравнивать время с ним и без него. В большинстве случаев индексы предлагаются дельные.
Администрирование - Настройки - Производительность - Кеширование. Здесь стоит обратить внимание на компоненты создающие большой по размеру кеш.
Администрирование - Настройки - Производительность - Ошибки PHP. Здесь желательно избавиться от всех ошибок. К сожалению среди записей много нотисов от ядра.
Анализ времени отдачи страницы
Администрирование - Настройки - Производительность - Скорость сайта. Здесь время работы сайта стоит оценивать в динамике. Утрировано говоря если у вас долго не было посетителей, а потом зашла 1000 из тундры с допотопных телефонов через GPRS. Скорость будет очень низкой. Более информативным на этой странице является график "Последние посещения сайта". Здесь можно увидеть на чем теряется время при загрузке странице в браузере посетителя. Так, например, большое время на "Обработку HTML" стоит уделить внимание оптимизации верстки.
Пример типовой проблемы "периодически сайт начинает тормозить, помогите найти причину". Основные проблемы три:
- проблемы работе почтовой системы (почта отправляется медленно или функция mail подвисает при отправке на некорректные адреса), решается вынесением почты на cron ;
- работа системных агентов (периодически медленный агент вешает сайт);
- поисковые роботы (порой бот сканирует сайт так усердно, что это напоминает DOS атаку).
В последнем случае основная проблема - понять, где именно создаётся нагрузка на сервер. На практическом примере покажу, как решается задача при помощи модуля "монитора производительности".
Реальный клиент и реальная проблема, как описано выше: "сервер периодически не справляется с нагрузкой, стоит ли переходить на более мощный?".
Заходим в админку и включаем на 10 минут сбор статистики по производительности:
Теперь на каждый хит в базу попадает вся необходимая информация, связанная с производительностью: число, время запросов, время открытия страницы, медленные запросы.
Пока идёт сбор статистики можем посмотреть, как улучшить параметры базы (привёл скрин локальной системы):
Чаще всего проблема бывает не на уровне базы, а на уровне приложения, здесь идёт, так сказать, тюнинг. Сразу вижу, что мне надо увеличить параметры:
Но тут надо рассчитывать чтобы общей системной памяти хватало и для работы всех процессов php (для варианта Apache + mod_php +eaccelerator это будет грубо: memory_limit * max_clients + eaccelerator.shm_size).
Сделал для себя пометки и уже через 10 минут видим такую картину:
(1) Обратная сортировка по времени сразу даёт проблемную страницу, в нашем случае это отображение всех элементов секции инфоблока. Совет такой: либо увеличить время кеширования (а бывает и вовсе выключено автокеширование), либо полностью отказаться от показа всех элементов на одной странице. Ну, естественно, вариант с оптимизацией страницы тоже имеет место, хотя это и не всегда возможно.
(2) Далее видим, что страницы с элементами каталога тоже открываются долго. Следует заняться их оптимизацией, а если это сложно - существенно увеличить время кеширования.
(3) Бросается в глаза бестолковая страница, имеющая имя blank.jpg .
Происходит такая ситуация: где-то в коде html имеется ссылка на эту картинку (зачастую, ставится размер 1x1, и её не видно), картинка отсутствует (неправильная ссылка или картинку удалили). Браузер запрашивает картинку, веб сервер её не находит, работают правила ЧПУ и в итоге формируется какая-то страница каталога (правда, её никто не видит). И при этом страница потребляет существенные ресурсы сервера.
Это ошибка верстальщика, но сервер должен быть к этому готов
Если бы был настроен nginx , то нагрузка была бы около нуля: запрос бы попросту не дошёл до Битрикса. Т.е. рекомендация понятна: настроить фронт энд .
Всё это должно дать результаты. Суть проблем всегда одна, но на каждом проекте источники разные. Хотелось бы получить большую популяризацию этого эффективного инструмента.
Чем больше значение теста производительности, тем лучше конфигурация сервера.
После тестирования вы получите итоговый показатель и сможете сравнить их с эталоном 1С-Битрикс.
Если показатели выше эталона, то беспокоиться не о чем. Вы можете улучшать их либо оставить как есть.
Когда показатели ниже, следуйте советам по улучшению.
Как улучшить показатель Монитора производительности
1. Разместить онлайн-проект на более мощном тарифе
Производительности зависит от мощности сервера: частоты и количества ядер процессора, доступной оперативной памяти. Чем они выше и больше, тем производительнее хостинг.
Наши тарифы хостинга оптимизированы для работы проектов на 1С-Битрикс. Мы тонко настроили серверы и подобрали параметры для мощной работы сайтов. Вы можете выбрать виртуальный хостинг или виртуальный сервер, полностью готовый к работе 1С-Битрикс.
2. Обновить PHP до последней версии
Последняя версия делает код более удобным и простым в дальнейшей поддержке и помогает увеличить производительность сайта.
Последняя версия может повлиять на работу сайта не так, как ожидается. Например, некоторые модули пока не поддерживают версию 7.4 и перестанут быть совместимыми для сайта. До перехода рекомендуем проконсультироваться с программистом вашего проекта. Обсудите преимущества и недостатки перехода на новую версию и только после этого вносите изменения.
3. Оптимизировать CSS
Оптимизация CSS и JS помогает уменьшить размер таких файлов и экономить ресурсы сервера. Выполните настройки оптимизации по инструкции 1С-Битрикс.
4. Сокращать размер изображений на сайте
Можно выполнить разными способами:
Уменьшите разрешение на 30-50% в редакторе или сервисе: Optimizilla, Compress JPEG, TinyPNG и др.
Конвертируйте файлы из PNG в JPG: они весят в 5 раз меньше.
5. Проверить подключение memcached
Memcached — способ кэширования данных в оперативной памяти на основе хеш-таблицы. Он позволяет быстро обрабатывать десятки запросов, необходимых для обработки одной страницы, однако требует много оперативной памяти. Подключите, если ее достаточно для работы вашего проекта.
Мы описали основные способы ускорения сайта при низких баллах Монитора производительности. За рекомендацией обращайтесь к нашим специалистам — поможем сделать ваш проект мощнее.
В данном топике я бы хотел обсудить до боли частую проблему с клиентами, которые используют CMS Битрикс на хостинге, VPS или выделенном сервере.
К сожалению, многие владельцы CMS Битрикс думают, что данный показатель является эталоном и показывает скорость загрузки сайта, качество хостинга или VPS сервера, на котором размещен сайт. НО это не так.
Даже сами разработчики CMS Битрикса утверждают, что это не так.
Официальный ответ от компании Битрикс:
В связи с вышесказанным, пожалуйста, не оценивайте качество CMS хостинга данным тестом.
Несмотря на то, что показатель сам по себе не имеет ничего с общей загрузкой сайта, мы все же решили провести самостоятельное исследование, и изучить, как выполняется данный тест.
Аналогичная ситуация с почтовой системой и другими показателями. Что интересно, очень сильно влияет на конечный показатель выполнение требований от самого битрикса, а именно включение php кеширования, отключение open_basedir и изменения других директив для PHP. Как оказалось, показатель мог меняться в 2-4 раза. Что еще более интересно, на конечную скорость загрузки это практически не влияло. Мы решили удостовериться в этом опытным путем и использовали внешние сервисы тестирования скорости загрузки сайта, чтобы исключить все факторы, которые могут искажать результат. Как оказалось, это практически не влияет на результат.
Но, мы также повторимся:
Другими словами, ядро может даже не делать запросы к БД и в принципе не грузить статику. Оно абсолютно не коррелируется со скоростью загрузки сайта.
Видимо, одному Богу известно, как оно грузится.
Напоследок, мы решили провести обширное тестирование на серверах с разной мощностью. На всех серверах было одинаковое ПО, но разные процессоры, объем памяти, диски.
Итак, есть 3 сервера:
Далее, мы решили проверить корреляцию загрузки 3-х сайтов (главной страницы) с использованием режима отладки:
Результаты видны в левом нижнем углу:
1) 0.31 сек
2) 0.23 сек
3) 0.24 сек
Как Вы можете заметить, погрешность загрузки очень мала, НО, что самое интересное, самый мощный сервер выдал всего 10 баллов. Какие-то только оптимизации мы не делали с ним. Причем первый сервер при нагрузочном тестировании показал лучшие результаты, а как раз этот показатель важен для высоко нагруженных проектов. Также, данный показатель не считает общую производительность процессора, а только одного ядра!
Что это означает?
Наши рекомендации:
В процессе тестирования, мы выявили ряд мер, который действительно влияют на конечную скорость загрузки сайта и в целом на производительность битрикса. В порядке их влияния:
Также не забудьте, что мы предлагаем оптимизированный хостинг для Битрикса.
Модуль «Монитор производительности» позволяет протестировать производительность проекта и сравнить полученные результаты с эталонной системой. Модуль предназначен для разработчиков веб-проектов. Функционал модуля поможет проанализировать скорость работы проекта. Модуль позволяет в абсолютных величинах оценить конфигурацию проекта, сравнить ее с эталонной системой, проанализировать общую производительность проекта и выявить «проблемные участки».
Диагностика хостинг-платформы
Имея встроенную систему эталонной оценки хостинговых систем, модуль является удобным инструментом для поиска технических проблем – в сайте, CMS, конфигурации, некачественной разработке или хостинге.
Панель производительности модуля позволяет не только протестировать производительность проекта, но и сравнить полученные результаты с эталонной системой. И, что важно, при этом даются рекомендации по настройке и приводится список самых нагруженных страниц.
Как работает модуль?
При запуске скрипта выполняется тестирование конфигурации оборудования и анализ факторов, влияющих на производительность системы, а также анализ параметров платформы «1С-Битрикс». По итогам проверки показывается итоговый показатель производительности, этот показатель сравнивается с эталонным, полученным при замере на «1C-Битрикс: Виртуальная машина». Автоматически выводятся рекомендации для повышения производительности системы и параллельно выполняется оценка качества интеграции проекта на основе автоматических тестов. В BitrixHub мы уделяем особенное внимание настройке и оптимизации виртуальных машин Битрикс.
В модуле «Монитор производительности» включена поддержка memcached. Продукт может хранить кеш не только на диске, но и в memcached, в APC, в eAccelerator и сервере Zend. Включается этот способ хранения в «Модуле производительности».
С каким эталоном сравнивает Битриксовский тест быстродействие хостинга?
Эталонные замеры производительности, которые используются «Монитором производительности», выполнены на виртуальной машине VMware, разработанной специалистами «1С-Битрикс». Вы тоже можете проверить, насколько быстро заработает ваш сайт на «1C-Битрикс: Виртуальная машина».
Оцените хостинговые пакеты BitrixHub, мы имеем высочайшие эталонные результаты и наш хостинг оптимизирован для работы под 1С Битрикс.
Читайте также: