Сравнение производительности версий 5.0 и 6.0. Результаты нагрузочного тестирования: ускорение на 80% Александр Сербул, ведущий специалист отдела качества QSOFT +7 (495)

План доклада Цели и задачи Сервер и ПО Методика создания нагрузки Сбор и анализ данных Архитектура системы Ключевые настройки Исследуем систему под нагрузкой Возникшие проблемы Максимальная стабильная нагрузка на версии 1С-Битрикс 6.0 (редакция «Бизнес») Сравнительные характеристики производительности 1С-Битрикс 5.0 и Битрикс 6.0

Цели и задачи Сравнить версии 5.0 и 6.0 "в динамике" - по различным критериям при изменяющейся нагрузке. Определить максимальную производительность 1С-Битрикс 6.0 на одном сервере при приемлемом времени отклика. Выявить возможные проблемы, возникающие при использовании 1С-Битрикс на проектах с высокой нагрузкой, и выработать методику их решения. А для этого: Создать максимально приближенную к реальности нагрузку. Качественно оценить поведение и устойчивость систем на базе 1С-Битрикс 5.0 и 6.0 при изменении нагрузки.

Сервер и ПО Сервер: Kraftway Express ISP ES11 (2x) Intel Xeon 2.8 GHz, HT MB Intel SE7520JR2 (Jarrell) (1x) SEAGATE ST LC, 144 GB (Ultra320 SCSI) без RAID 2 GB Registered SDRAM DDR333 (PC2700) (1GB х 2) ПО: ОС Linux Debian 4: smp Nginx Apache MySQL PHP (eAccelerator v0.9.5)

Методика создания нагрузки ПО для создания нагрузки: JMeter 2.2 OpenSTA ) Определяем состав и вероятностное распределение цепочек, по которым ходят пользователи. 2) Рассчитываем количество виртуальных пользователей (нагрузочных потоков) для каждой цепочки для создания требуемой нагрузки. 3) Параметризируем цепочки. Создаем справочные таблицы CSV (JMeter) для последующей генерации, например, адресов детальных страниц новости, поисковых фраз. 4) Проверяем правильность расчетов на основе данных модуля «Статистика», нагружая систему в течение небольшого интервала.

Пример цепочек Index > About = 3% Index > About_news_detail > About_news_index > About_news_detail > About_contacts = 2% Index > Catalog_element > Catalog_phone_index > Catalog_accessory_section > Catalog_phone_index = 9% и т.д.

Сбор и анализ данных Для сбора статистических данных использовались утилиты Linux: apachetop, atop, sadc, sadf, curl, innotop, munin. Очень полезный пакет sysstat (sadc, sadf, iostat, vmstat). FreeBSD? Для анализа – awk, MS Excel (проблема 64k строк).

Архитектура системы

Ключевые настройки PHP Кэширование страниц демо сайта 1С-Битрикс 6.0. Акселератор (memory&disk) MySQL innodb_buffer_pool_size table_cache = 512 innodb_flush_log_at_trx_commit=0 (ACID?) innodb_thread_concurrency = 4 Apache 1.3, preforked число процессов (управляющий + серверные) равно числу процессоров (ядер): MinSpareServers=MaxSpareServers=StartServers=MaxClients=5. Сервер noatime + write-back cache для диска.

Исследуем систему под нагрузкой Мониторинг системы целиком - munin Реальная нагрузка на apache – apachetop Что творится в системе, что произошло ночью – atop Состояние СУБД - innotop, log_slow_queries

Возникшие проблемы: php+акселератор Акселераторы php: xcache, APC, eAccelerator. При нагрузке происходит "Segmentation fault" веб сервера apache. Вот что мы делали, пытаясь предотвратить сбои в работе предкомпиляторов: перекомпилировали PHP, предкомпиляторы без режима оптимизации: –O0; меняли версию gcc с 4.1 на 3.3; увеличивали ulimits, меняли параметры ядра Linux; перебирали настройки предкомпиляторов, настройки компиляции (./configure …); убирали из конфигурации PHP «лишние» модули.

Возникшие проблемы: php+акселератор Фрагмент коредампа: (gdb) bt #0 0x40493a74 in _efree () from /usr/lib/apache/1.3/libphp4. so #1 0x404a5380 in _zval_dtor () from /usr/lib/apache/1.3/libphp4. so #2 0x4049c2e9 in _zval_ptr_dtor () from /usr/lib/apache/1.3/libphp4. so #3 0x404ac6ca in zend_hash_destroy () from /usr/lib/apache/1.3/libphp4. so #4 0x404a53ad in _zval_dtor () from /usr/lib/apache/1.3/libphp4. so #5 0x4049c2e9 in _zval_ptr_dtor () from /usr/lib/apache/1.3/libphp4. so Выбрали eAccelerator, т.к. он создает минимальную нагрузку на процессор. Shell-скрипт перезагрузки apache после падения - вполне подходящее решение: на полтора миллиона хитов в сутки пришлось лишь 0,07% ошибок, при этом apache был перезагружен 3 раза.

Возникшие проблемы: деградация производительности системы Постепенная деградация производительности. Невидимость сервера MySQL в Linux Debian - %CPU=0. Служебные внутренние таблицы Битрикс по умолчанию очищаются агентами в большинстве случаев раз в сутки. Для предотвращения деградации вследствие роста служебных таблиц был уменьшен интервал запуска агента CStatistics::CleanUpPathCache. Агенты перевода статистики на новый день выполняют "тяжелые" запросы и как правило попадают в лог медленных запросов. Для запуска подобных агентов лучше выбирать время наименьшей посещаемости веб-ресурса (по умолчанию в полночь). "Посетитель-неудачник" и запуск агентов через крон.

Возникшие проблемы: деградация производительности системы Время хранения данных статистики (хиты, посетители, события...), размер базы данных, buffer_pool - нужно искать компромисс, т.к. база данных должна помещаться в ОЗУ. x86-32 ограничивает размер buffer_pool менее чем 2G. Рекомендуем для сервера MySQL с таблицами innodb использовать 64-х разрядную архитектуру, в которой подобного ограничения на buffer_pool нет. Полезные утилиты для диагностики "торможения" СУБД MySQL во время нагрузки - innotop, mysqldumpslow.

Максимальная стабильная нагрузка на версии 1С-Битрикс 6.0 (редакция «Бизнес») Среднее время загрузки страницы, сек. - 0,35 Среднее время построения страницы, сек. - 0,22 Обработано запросов Распределение времени загрузки страницы: Меньше либо равно 1 сек.: (98,63%) Больше 1 сек.: (1,37%) Больше 2 сек.: 4172 (0,26%) Ошибки 50x: 1047 (0,07%)

Время построения/загрузки главной страницы 1С-Битрикс 6.0 (сек.)

Скорость обработки запросов (в сек.), Битрикс 6.0 редакция «Бизнес»)

Сравнительные характеристики производительности 1С-Битрикс 6.0 и 5.0 Время отклика - 0,4 секунды 1С-Битрикс 6.0 показывает при нагрузке в хитов в сутки, а Битрикс 5.0 – при хитов в сутки. При данном времени отклика (~0,4 сек) производительность 1С-Битрикс 6.0 возросла на 80%. При нагрузке в диапазоне от до хитов в сутки Битрикс 5.0 использует CPU в среднем на 12,4% интенсивнее и загружает систему в среднем на 48% выше (load average), чем 1С-Битрикс 6.0.

Время загрузки главной страницы в зависимости от количества хитов в сутки (сек.)

Время построения главной страницы в зависимости от количества хитов в сутки (сек.)

Загрузка процессора в зависимости от количества хитов в сутки (%)

Загрузка системы в зависимости от количества хитов в сутки

Вопросы? Александр Сербул Спасибо за внимание!