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

Пример типовой проблемы "периодически сайт начинает тормозить, помогите найти причину". Основные проблемы три:
- проблемы работе почтовой системы (почта отправляется медленно или функция mail подвисает при отправке на некорректные адреса), решается вынесением почты на cron;
- работа системных агентов (периодически медленный агент вешает сайт);
- поисковые роботы (порой бот сканирует сайт так усердно, что это напоминает DOS атаку).
В последнем случае основная проблема - понять, где именно создаётся нагрузка на сервер. На практическом примере покажу, как решается задача при помощи модуля "монитора производительности".

[spoiler]

Реальный клиент и реальная проблема, как описано выше: "сервер периодически не справляется с нагрузкой, стоит ли переходить на более мощный?".
Заходим в админку и включаем на 10 минут сбор статистики по производительности:


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

Пока идёт сбор статистики можем посмотреть, как улучшить параметры базы (привёл скрин локальной системы):


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

Также желательно и
Но тут надо рассчитывать чтобы общей системной памяти хватало и для работы всех процессов php (для варианта Apache + mod_php +eaccelerator это будет грубо: memory_limit * max_clients + eaccelerator.shm_size).

Сделал для себя пометки и уже через 10 минут видим такую картину:


(1) Обратная сортировка по времени сразу даёт проблемную страницу, в нашем случае это отображение всех элементов секции инфоблока. Совет такой:  либо увеличить время кеширования (а бывает и вовсе выключено автокеширование), либо полностью отказаться от показа всех элементов на одной странице. Ну, естественно, вариант с оптимизацией страницы тоже   имеет место, хотя это и не всегда возможно.

(2) Далее видим, что страницы с элементами каталога тоже открываются долго. Следует заняться их оптимизацией, а если это сложно - существенно увеличить время кеширования.

(3) Бросается в глаза бестолковая страница, имеющая имя blank.gif.
Происходит такая ситуация: где-то в коде html имеется ссылка на эту картинку (зачастую, ставится размер 1x1, и её не видно), картинка отсутствует (неправильная ссылка или картинку удалили). Браузер запрашивает картинку, веб сервер её не находит, работают правила ЧПУ и в итоге формируется какая-то страница каталога (правда, её никто не видит). И при этом страница потребляет существенные ресурсы сервера.
Это ошибка верстальщика, но сервер должен быть к этому готов
Если бы был настроен nginx, то нагрузка была бы около нуля: запрос бы попросту не дошёл до Битрикса. Т.е. рекомендация понятна: настроить фронт энд.

Всё это должно дать результаты. Суть проблем всегда одна, но на каждом проекте источники разные. Хотелось бы получить большую популяризацию этого эффективного инструмента.