Оптимизация проектов под высокие нагрузки

В феврале 2007 года, при поддержке компаний 1С-Битрикс и Мастерхост, мы провели серию нагрузочных тестов платформы "1С-Битрикс: Управление сайтом" версий 5.0 и 6.0 (редакции «Бизнес»), основная цель которых - дать объективную оценку производительности платформы при достаточно высокой нагрузке (1 500 000 хитов в сутки), сравнить производительность версий 5.0 и 6.0, определить возможные проблемы, возникающие во время нагрузки и выработать принципы их решения, попытаться сформировать рекомендации для системных администраторов по настройке веб-приложения на максимальную производительность.

Полагаем, что представленный ниже материал будет полезен не только системным администраторам и специалистам по нагрузке, но и широкому кругу лиц, заинтересованным вопросами настройки веб-приложений на базе платформы 1С-Битрикс на работу в условиях высокой нагрузки.

Ключевой результат

После проведения серии работ по настройке и оптимизации сервера и программного обеспечения, демосайт 1С-Битрикс 6.0 (редакция «Бизнес») в течение суток обработал 1,5 миллиона хитов (17,4 запросов в секунду). Среднее время загрузки страницы составило 0,35 сек. с 0,07% ошибок.

При дальнейшем увеличении посещаемости до 2 миллионов хитов в сутки, время загрузки страницы плавно возрастало, система стабилизировалась по нагрузке (~5-6) и использованию CPU (~70-80% user).

В ходе работ по оптимизации системы были обнаружены следующие проблемы:

• Недостаточная скорость работы интерпретатора PHP;
• Проявляющиеся при высоких конкурентных нагрузках сбои в работе связки прекомпилятор-PHP, вызывающие «Segmentation fault» дочерних процессов вебсервера apache;
• Лавинообразный рост «медленных» запросов в СУБД MySQL, вызывающий общую деградацию производительности системы через несколько часов после начала нагрузочного тестирования.

Для их устранения были проведены следующие мероприятия:

• PHP: в несколько раз ускорена обработка PHP скриптов за счет использования прекомпилятора eAccelerator; также был написан несложный системный скрипт, отслеживающий сбои прекомпилятора и перезапускающий apache;
• MySQL: оптимально настроена СУБД MySQL с учетом высокой конкурентной нагрузки;
• Платформа: оптимизированы некоторые таблицы модуля «Статистика», оптимально сконфигурирован модуль «Статистика», а также агенты, работающие с данными модуля;
• Frontend/backend: подобраны оптимальные настройки двухуровневой конфигурации frontend/backend, позволяющие системе выдерживать высокие нагрузки, при этом сохраняя внутренний баланс.

А теперь поподробнее…

Описание тестового стенда

• Демосайт 1С-Битрикс; версия главного модуля - 6.0, редакция «Бизнес».
• Сервер “Kraftway Express ISP ES11”, предоставленный компанией “.masterhost” (http://masterhost.ru).
• Программное обеспечение:
  • ОС 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)

Методология тестирования

Нагрузочное тестирование

Для создания нагрузки использовался программный пакет OpenSTA 1.4.3, установленный на отдельной машине. Создавалась равномерная нагрузка в течение 24 часов. Распределение запросов по страницам демосайта осуществлялось согласно полученной на ряде действующих проектов схожей направленности гистограмме путей посетителей по сайту. Для сбора статистических данных использовались утилиты Linux: sadc, sadf, curl, munin. Для анализа – MS Excel.

Методика создания нагрузки

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

Каждая «цепочка» состоит из определенного количества загружаемых пользователем страниц (запросов, хитов). Цепочки и их распределение были подобраны на основании экстраполированной статистики ряда действующих проектов на базе 1С-Битрикс «Бизнес». Каждый новый пользователь проходит по случайно выбранной цепочке и больше на сайт не возвращается, таким образом, старые пользователи постоянно сменяются новыми (новые пользователи являются самой существенной нагрузкой для модуля статистики).

Задержка между загрузками страниц выбирается случайным образом из диапазона от 18 до 37 секунд, что составляет в среднем 27,5 сек.

Создаваемая на сервер нагрузка равномерно распределена по времени, что позволяет оценить «устойчивость» сервера к нагрузке.

Сравнительные тесты версий 5.0 и 6.0 (редакция «Бизнес»)

Уровень нагрузки демосайтов ступенчато изменялся с 500 000 до 2 000 000 хитов в сутки. Продолжительность ступени составляла 30 минут, контрольный замер - 20 минут. Показатели снимались с главной страницы демосайта с помощью специальной программы, определяющей: время соединения, время загрузки, время построения страницы, время ожидания в очереди.

Следует отметить, что в реальных условиях характеристики систем возможно будут зависеть от процента наполнения таблиц модуля «Статистика», определяющегося настройками времени хранения данных. Например, показатели системы с временем хранения хитов посетителей в 10 дней будут вероятно отличаться через 1, 3, 5 дней после запуска теста. В связи с вышеизложенным при сравнении версий 5.0 и 6.0 использовались одинаковые настройки модуля «Статистика».

Процесс тестирования

Мы поставили перед собой следующую основную цель – добиться на версии 6.0 максимальной производительности при приемлемом времени загрузки страницы менее 0.5 секунды.

Кэширование

В целях сокращения времени на обращения к СУБД было включено кэширование всех компонентов на тестируемых страницах демосайта. Дополнительно, для кэширования карты сайта было установлено значение «магического» параметра: $GLOBALS["MAP_CACHE_TIME"]=300; В связи с тем, что использовался выделенный сервер, дополнительная настройка «управляемого» кэша платформы не проводилось.

Настройка софта

Вначале была выполнена стандартная настройка конфигурации frontend/backend, согласно рекомендациям С.Рыжикова в сертификационном курсе «Конфигурирование веб-систем для оптимальной работы».

СУБД MySQL, путем анализа статусных переменных во время эксплуатации проекта, можно подстраивать и дальше, в частности это касается параметров кэша запросов. Мы не стали углубляться в этом направлении, т.к. имеющаяся скорость работы СУБД устраивала, да и демосайт был максимально закэширован.

Можем на основе нашего опыта еще раз подтвердить, что движок хранения данных MyISAM является «узким местом» при более менее реальной нагрузке, в особенности при использовании модуля «Статистика» - сайт начинает виснуть. Поэтому для средних и больших проектов настоятельно рекомендуем движок InnoDB.

Следует указать на серьезный компромисс между скоростью работы СУБД и надежностью хранения данных (более точно – соответствию режима работы СУБД MySQL концепции ACID http://en.wikipedia.org/wiki/ACID). 1С-Битрикс рекомендует отключение параметра: innodb_flush_log_at_trx_commit=0 чего разработчики MySQL, однако, не советуют делать. И хотя отключение и ускоряет работу СУБД, вполне возможна ситуация, когда в случае сбоя потеряется часть финансовой транзакции или вообще испортятся файлы данных InnoDB.

На проектах, использующих ценную информацию, в том числе работающих с электронным магазином и лицевыми счетами пользователей, в целях обеспечения большей надежности мы рекомендуем следующую настройку: innodb_flush_log_at_trx_commit=1; sync_binlog=1;

На тестируемой конфигурации данные параметры были отключены.

Вебсервера nginx и apache были настроены также с учетом рекомендаций вышеуказанного курса 1С-Битрикс. Обнаружили следующую особенность: на разных проектах оптимальное количество запущенных дочерних процессов apache различно. В результате экспериментов под нагрузкой определили оптимальное количество дочерних процессов apache для нашей конфигурации – 5. Полагаем, если код php «равномерно» использует CPU и не изобилует обращениями к внешним ресурсам, например к СУБД или диску, то количество дочерних процессов apache должно быть близко к количеству виртуальных процессоров системы. Если код «неравномерный» - подбирать количество экспериментально.

Интерпретатор PHP – «узкое место»?

Работать с комплексными программными продуктами на PHP, такими как система управления веб-проектами "1С-Битрикс: Управление сайтом", без прекомпилятора очень некомфортно. Страницы строятся долго, иногда по несколько секунд.

Были протестированы наиболее распространенные прекомпиляторы: xcache, APC, eaccelerator. К сожалению, ВСЕ прекомпиляторы через некоторое время после начала нагрузки демосайта 1С-Битрикс «Бизнес» вызывали «падение» дочерних процессов вебсервера apache - «Segmentation fault». Если вовремя не перезапустить apache, он мог вообще «намертво» зависнуть (apache + eaccelerator).

Следует отметить, что при тестировании редакции «Старт» (нагрузка: ~60 запросов в секунду в течении суток; load average ~25; CPU user ~ 350% из 400%) eaccelerator ни разу не «упал». Видимо редакция платформы влияет на «падения» прекомпилятора: или количество кэшируемых файлов php или проблемы с распределением памяти между MySQL (запросов к СУБД в редакции «Бизнес» значительно больше) и apache играют «роковую» роль.

Обнаружилась следующая закономерность – при незначительной нагрузке системы (load average: 1-3) прекомпиляторы «падают» реже, при повышении нагрузки до 10 – падают чаще.

Похоже, что прекомпилятор является «ахилесовой пятой» вебпроекта на PHP. Качественных «бесплатных» прекомпиляторов, способных выдержать высокие нагрузки, пока по-видимому нет. Очень интересно, как будет работать ZendPlatform с использованием встроенного прекомпилятора при высоких нагрузках? (это мы протестируем в следующий раз)

Вот что мы делали, пытаясь предотвратить сбои в работе прекомпиляторов:

• перекомпилировали PHP, прекомпиляторы без режима оптимизации: –O0;
• меняли версию gcc с 4.1 на 3.3;
• увеличивали ulimits, меняли параметры ядра Linux;
• перебирали настройки прекомпиляторов, настройки конфигурации компиляторов в PHP (./configure …);
• убирали из конфигурации PHP «лишние» модули.

Coredump apache, получаемый при «падениях» прекомпиляторов, не содержал ничего интересного из-за постоянно «поврежденного» стека. Невозможно было определить, кто же виноват? В конце концов все же удалось получить более менее полные «коредампы», собрав прекомпиляторы и php в режиме –O0 (с поддержкой отладки в php).

Видны характерные проблемы программ на C – баги, связанные с управлением памятью…

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

В общем, «лезть» в исходный код прекомпиляторов мы не решились и обошли проблему с другой стороны – написали простой bash-скрипт, отслеживающий появление в логе apache сообщений «Segmentation fault» и перегружающий apache.

Оказалось, что это вполне подходящее решение: на полтора миллиона хитов в сутки пришлось лишь 0,07% ошибок, при этом apache был перезагружен 3 раза.

Тюнинг работы "1С-Битрикс: Управление сайтом" с MySQL

После запуска нагрузки стало наблюдаться постепенное возрастание показателя использования процессоров (user), общей загруженности системы (load average), и «медленных» SQL-запросов. В итоге, примерно через 8 часов процессоры использовались практически на 100%, нагрузка (load average) поднималась до 10 и выше, а система начинала использовать swap – производительность падала фактически до 0. Нагрузочное тестирование приходилось останавливать.

Начали анализ работы СУБД. Утилита innotop показала «торможение» запросов к таблице b_forum_stat. После консультаций с 1С-Битрикс в таблицу был добавлен индекс, решивший проблему «торможения» данных запросов, но так и не решивший проблему деградации производительности (появился в очередном обновлении модуля «Статистика»). Далее были обнаружены «тормозящие» запросы к таблице b_stat_path_cache, лавинообразно накапливающиеся через несколько часов нагрузки; при этом размер таблицы иногда вырастал до 1ГБ. Проблема была решена отключением настройки модуля «Статистика»: «Использовать дополнительную обработку посетителей не принимающих файлов cookie» (вероятно проблема проявилось из-за особенностей нашей методологии тестирования) и уменьшением интервала запуска агента, очищающего временные таблицы статистики - CStatistics::CleanUpPathCache().

Агенты 1С-Битрикс, как оказалось, сыграли немаловажную роль в процессе оптимизации системы.

Итоги

В результате проведенных мероприятий основные показатели системы: CPU, load average, использование памяти во время нагрузочного тестирования (1 сутки) оставались стабильными. Это дает основание предположить, что аналогичная конфигурация будет способна выдерживать высокую нагрузку длительный период времени.

Было также обнаружено, что выполняемые «ежедневными» агентами периодические мероприятия по обслуживанию таблиц модуля «Статистика» вызывают кратковременную (иногда 1-2 минуты) деградацию производительности системы. Поэтому рекомендуется установить время запуска «ежедневных» агентов в период минимальной посещаемости сайта (CStatistics::CleanUpStatistics_1, CStatistics::CleanUpStatistics_2, CStatistics::SetNewDay).

Интервал запуска CStatistics::CleanUpPathCache нами был установлен в 30 минут.

Рекомендации по исследованию проблем производительности

Для анализа производительности Linux серверов мы рекомендуем программные пакеты sysstat, atop, innotop.

Утилита sadc пакета sysstat собирает различные данные о системе, sadf – форматирует собранные данные в нескольких представлениях. Обработку данных удобно проводить в MS Excel.

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

Неоценимую помощь при анализе производительности сервера MySQL, использующего таблицы innodb, оказывает утилита innotop, а также лог «медленных» запросов сервера MySQL.

Результаты тестирования

Максимальная стабильная нагрузка на версии 6.0 (редакция «Бизнес»)

Таблица «Основные параметры»

Параметр	Среднее значение	Максимальное значение
Время загрузки страницы, сек.	0,35	199,42
Время построения страницы, сек.	0,22	0,68
Суммарная загрузка процессоров, % (100% = максимум)	77,71	98,83
Обработано запросов	1593983

Критерий	Значение	%
Меньше либо равно 1 сек.	1572073	98,63
Больше 1 сек.	21910	1,37
Больше 2 сек.	4172	0,26
Больше 3 сек.	3502	0,22
Больше 5 сек.	2611	0,16
Больше 7 сек.	2026	0,13
Ошибки 50x	1047	0,07

График "Время построения/загрузки главной страницы версией 6.0 (сек.)"

График "Скорость обработки запросов (запросов в сек.)"

Сравнительные характеристики производительности версии 5.0 и 6.0

Ядро версии 6.0, как известно, были качественно оптимизировано, в том числе с учетом особенностей работы продукта на виртуальном хостинге. В частности, был «досконально» оптимизирован весь код ядра, уменьшено число запросов к СУБД за счет «управляемого» кэширования, оптимизирована работа с меню.

Как показывает график «Время загрузки страницы», страница версии 5.0 при нагрузке в 600000 хитов в сутки загружается уже более чем в 2 раза медленнее. А при нагрузке свыше 1600000 система на версии 5.0 уже не успевает обрабатывать все поступающие запросы: значительно возрастает время загрузки страницы, постепенно переполняется очередь запросов frontend, растет количество ошибок 50x.

Как показывает график «Время построения страницы БУС», страница на версии 5.0 строится значительно медленнее.

Как показывают графики «CPU», «Load average» система на версии 5.0 более активно использует процессоры и интенсивнее «нагружает» систему, что, в свою очередь, сказывается на общей производительности.

Выводы:

Версия 5.0 более интенсивно использует вычислительные ресурсы и перестает справляться с нагрузкой, превышающей 1 600 000 хитов в сутки. При этом на версии 6.0, при увеличении посещаемости c 1 600 000 до 2 миллионов хитов в сутки, время загрузки страницы плавно возрастает до 0,88 сек, система стабилизируется по нагрузке (~5) и использованию CPU (~65% user).

Время отклика - 0,4 секунды на версии 6.0 показывает при нагрузке в 1 800 000 хитов в сутки, а версии 5.0 – при 1 000 000 хитов в сутки. При данном времени отклика (~0,4 сек) производительность версии 6.0 возросла на 80%.

При нагрузке в диапазоне от 500 000 до 1 600 000 хитов в сутки версия 5.0 использует CPU в среднем на 12,4% интенсивнее и загружает систему в среднем на 48% выше (load average), чем версия 5.1.

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

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

График "Загрузка процессора в зависимости от количества хитов в сутки (проценты)"

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

Дополнительные материалы

	Описание цепочек, используемых при нагрузочном тестировании (*.doc 30 Kb)
	Фрагменты отладочных дампов (*.doc 37 Kb)