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

Монитор производительности умеет фиксировать хиты. Можно настроить какие имменно хиты фиксировать:
- медленные SQL запросы
- большой кеш

А вот настройки "большое использование памяти" нет. А очень бы пригодилось.

Проблема:

Сайт работает с двумя БД: локальной (в ней новости, данные пользователей, прочая обычная информация) и удаленной (внутренняя БД клиента с конфиденциальной информацией, которую недопустимо хранить на сайте).

Работу с внешней БД организовали через подключения d7, но монитор производительности никак не регистрирует такие запросы и не позволяет узнать, есть ли среди них проблемные. А это очень бы не помешало.

Собственно, идея:
Научить монитор производительности в режиме журнала SQL-запросов вести запись SQL-обращений ко всем зарегистрированным подключениям.

Сейчас это сплошной код на странице админки /bitrix/admin/perfmon_tables.php?lang=ru&orm=y :



А должен быть удобный для использования метод вида:

Сейчас при использовании стандартного и идущего из коробки с версии PHP 5.5 акселератора Zend OPcache,
монитор производительности ругается на то, что не установлен ни какой акселератор:

Нужно научить монитор производительности понимать установленный Zend OPcache (который дефолтный с версии PHP 5.5 - php_opcache.*)

Например в редакции "Старт" Монитор качества ругается на отсутствие проактивной защиты, а в редакции "Первый сайт" еще и на монитор производительности, которого там просто нет.

Неужели нельзя в мониторе качества ставить проверку на текущую редакции и пропускать тесты, которые в принципе невозможно пройти на текущей редакции?

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

Для разработчиков сайтов гораздо больший интерес представляет именно индекс по времени генерации.

Были проблемы с производительностью проекта. Экспертиза производительности начинает разбираться и в качестве одной из причин указывает

Не хватает индексов после обновления.  Необходимо создать недостающие индексы для таблиц
статистики.

Решение:
Автоматическая проверка модулем производительности всех таблиц продукта на наличие индексов для текущей версии каждого из модулей.

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

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