1 / 22

Александр Сербул, ведущий специалист отдела качества QSOFT +7 (495) 771-73-63

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

goro
Download Presentation

Александр Сербул, ведущий специалист отдела качества QSOFT +7 (495) 771-73-63

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  5. Пример цепочек 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% и т.д.

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

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

  8. Ключевые настройки 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 для диска.

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

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

  11. Возникшие проблемы: 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 раза.

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

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

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

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

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

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

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

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

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

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

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

More Related