Мы уже отмечали, что в версия 8.5 один из ключевых акцентов будет сделан на Производительность и новые инструменты быстрого поиска и локализации проблемных мест в системе.
Напомню, что для разработчиков в продукте есть богатый инструментарий для отладки и анализа производительности системы. Включается на публичной странице сайта в режиме разработчика:
Все компоненты размещенные на странице выделяются, для каждой выводится время исполнения и SQL запросы. Внизу под страницей выводилась общая статистика по производительности системы и SQL запросы не входящие в компоненты.
Но для полного анализа производительности страницы всегда хотелось свести в одном интерфейсе все цифры и увидеть, что больше тормозит и где нужно искать резервы производительности.
Вот так это будет выглядеть в новой версии продукта при нажатии на ссылке "Время создания страницы":
[spoiler]
В одном общем диалоге вы сможете увидеть в процентах время исполнения всех составляющих страницы, число, время и процент исполнения компонентов, число, время и процент исполнения SQL запросов и все это в разрезе по каждой из составляющих страницы.
Теперь мы отдельно выделяем данные по Прологу и внутри него Ядро, Агент и Шаблон.
Представленные цифры на тестовом проекте показывают, что 84% времени страницы занимает выполнение Пролога из которых Ядро потребляет почти 50% и 34% - это Шаблон.
В окне ниже видно, что компоненты на странице не сильно тормозят, а время потребляет PHP код не входящий в компоненты. Причиной такого торможения может быть медленная работа PHP вообще, отсутствие прекомпилятора и загруженная файловая система. (в этом тестовом проекте это отсутствие прекомпилятора)
Мы видим, что SQL запросы потребляют очень мало времени не смотря на их количество. Что свидетельствует о хорошей производительности базы данных. Нажимая на PHP код мы можем посмотреть все SQL запросы не входящие в компоненты и выполняемые ядром продукта.
Время SQL запросов составляет 1.11% от времени выполнения страницы. Но мы можем изучить каждый запрос и понять где и как он вызывается.
На другой странице в мониторе видно, что картина производительности уже другая. Рабочая область, насыщенная компонентами (21 штука) потребляет уже 43%. Мы можем просмотреть все компоненты на странице и увидеть, что самый медленный из них компонент bitrix:desktop, работающий в режиме Автокеширования, выполняющий только 2 запроса, но требующий 0.28 секунды для выполнения на этой машине. Причина медленной работы компонента может быть разная, но уже видно, где нужно смотреть. В данном случае компонент открывает соединение к Яндексу и получает данные по погоде или пробкам, это требует времени.
Вот так выглядит те же страницы, на той же машине уже после включения Автокеширования, перехода на PHP5 и установки APC.
Тут случай в общем никакой, просто пример использования и изменения конфигурации системы.
Но я уверен, что данный инструментарий будет полезен для всех разработчиков и позволит быстро анализировать ситуацию и улучшать производительность проектов.
На очереди Монитор производительности, который полностью преобразится и войдет в большинство редакций.
Но за производительностью нужно бороться в массовых редакциях.
База Oracle и модуль бизнес-процессов тогда вполне выведут ББ на нужное позиционирование, больше наверное ничего и не надо.
Очень хотелось бы ускорить работу PHP кода в Ядре, особенно на тех хостингах, файловые системы которых сильно загружены, и акселератор не дает нужного эффекта. Либо где вообще нету возможности настраивать параметры акселератора (виртуальный хостинг).
Но как правило хостер ничего в своих настройках менять не будет, а только посоветует "перейти на более мощный пакет", или на свой сервер.
Но первоначально важно понимать, в чем и где проблемы. И наша задача в модуле производительности вам это показать. И в нем, кстати, будет сравнение с эталонной системой на базе нашего Виртуального сервера.
Ну а дальше уже выводы будут самостоятельно делаться, переехать на другого хостера, взять в аренду наш виртуальный сервер у этого или хостера (предложения уже готовятся) или требовать доработки и устранения проблем хостером.
Кстати, подготовлен хороший скрипт для переноса проекта между хостерами. Он идет в поставке виртуального сервера.
Общая производительность зависит от Хостара+Битрикса+Разработки.
И новый модуль должен давать быстрый и точный ответ, где проблема и что надо ремонтировать. Будет в нас, будем устранять, будет у хостера или в разработке - нужно будет так же устранять проблемы.
разернул его и остался доволен результатами.
снизилась загрузка процессора на сервере (примерно в 2 раза).
То что бета-вылезла пара ошибок. К сожалению, он сейчас в отпуске и подробностей я не знаю.
Вы не проводили тесты кешера от Microsoft?