Про производительность уже говорилось много, но всегда есть, что сказать. Сегодня хочу показать, как можно относительно просто отловить достаточно сложную проблему через профилирование. Этот пост является продолжением повествования о модуле bitrix.xdebug, где я обещал рассказать о профилировщике.
Положим, ваш сайт или корпоративный портал работает на хорошем железе, оценка производительности нормальная. Конфигурация сервера правильная (хорошо, если это наша виртуальная машина или rpm). Но какая-то страница или сайт в целом работает неудовлетворительно. Куда двигаться в такой ситуации?
Кто работал с каким-либо дебаггером кода, знает, как это бывает удобно для быстрой отладки: код можно выполнять построчно в поисках ошибки. PHP из коробки не имеет такой возможности, но можно поставить xdebug настроить GUI и получить тот же результат. На практике это хорошо работает для локальных скриптов, но настройка сильно усложняется когда скрипт работает на дальнем сервере. Когда речь идет о поддержке, то почти всегда приходится работать с дальним кодом. Мне давно хотелось решить эту проблему.
После перехода на новую версию появилось много жалоб на производительность. Главным образом пользователи заметили серьезное уменьшение "попугаев" монитора производительности. Мы тестировали дистрибутив и обновления в лабораторных условиях перед выпуском и не выявили проблем (выявленные проблемы были отправлены на доработку не попав в обновления). Но продолжаем регистрировать жалобы и исследовать их. Уже собралась порядочная статистика, которая выявила главные проблемы.
Мы часто говорим о том, что архитектура важна, что нужно заниматься проектированием, что архитектура бывает простая, сложная, правильная, неправильная. А что это и зачем оно надо, каждый понимает по-своему. Для кого-то это паттерны программирования, для кого-то - понятное АПИ, а кто-то, может быть, сюда относит отступы в коде. Изучая проблему одного проекта, подумал, что число 13 000 может стать хорошим подспорьем в вопросе выбора правильной архитектуры проекта на битрикса. Но об этом числе чуть позже.
Часто приходится слышать вопрос: у нас свой сервер (или два), много ядер, памяти... почему же монитор производительности битрикса дает оценку производительности не выше (или ниже), чем на маленькой виртуальной машине? Давайте разберемся в этом вопросе.
Довелось впервые выступить на партнёрской конференции. За кулисами обсуждали работу техподдержки и технические проблемы. Лично для себя вынес много ценной информации. Надеюсь, что для партнёров мероприятие было такое же полезное и интересное как для нас, разработчиков. Одной из тем докладов была производительность. И судя по тому, что на второй день конференции не раз возвращались к этому вопросу в кулуарах, понятно, что тема интересная и животрепещущая Хочу теперь зафиксировать квинтэссенцию доклада и этих обсуждений.
Обновление от 16.09.09: улучшил скрипт по совету из комментариев.
Пример типовой проблемы "периодически сайт начинает тормозить, помогите найти причину". Основные проблемы три: - проблемы работе почтовой системы (почта отправляется медленно или функция mail подвисает при отправке на некорректные адреса), решается вынесением почты на cron; - работа системных агентов (периодически медленный агент вешает сайт); - поисковые роботы (порой бот сканирует сайт так усердно, что это напоминает DOS атаку). В последнем случае основная проблема - понять, где именно создаётся нагрузка на сервер. На практическом примере покажу, как решается задача при помощи модуля "монитора производительности".
Предлагаю вашему вниманию свои изыскания по вопросу производительности php (а точнее, предпочтительный вариант конкретно для Битрикса) в разных режимах запуска. Целью не было получить какие-то цифры по возможной посещаемости, а именно сравнить разные варианты при прочих равных условиях.