Test case: 44 хита в секунду – Битрикс «Большой бизнес» на Oracle 11g

Совместно с отделом тех.поддержки принимали участие в решении проблем производительности при проведении партнёром Битрикс компанией One Agile нагрузочных тестов развлекательного портала на платформе "Большой бизнес" / Oracle 11g
[spoiler]
Конфигурация серверов:

• Веб: Intel® Xeon® CPU E5506  @ 2.13GHz – 2 штуки, ОЗУ 12 GB, CentOS 5.4 x86, nginx/0.6.3.9, apache/2.2.3, apc  (apc.shm_size=1024MB), PHP 5.2.9
  
• БД: Intel® Xeon® CPU 5160 @ 3.00GHz - 2 штуки, ОЗУ 16 GB, raid1-массив из 2-х SAS 15k дисков ST3300555SS, Red Hat Enterprise Linux Server 5.5 x86_64, Oracle 11.2
  

Конфигурация продукта:

• Редакция продукта:   Большой бизнес
  
• Проактивная защита: включена
  
• Веб-антивирус выключен
  
• Модуль статистки включен
  
• Автокеширование компонентов Включено
  
• HTML кеш Выключен
  
• Сбор данных для отчета "Пути по сайту" Выключен
  
• Фиксация числа показов баннеров Выключена или нет баннеров с фиксацией
  
• Настройки модуля поиска       Включен быстрый морфологический поиск
  
• Хранение кеша              APC
  
• Управляемый кеш       Включен
  
• Закодированные модули         Не найдены
  
• Модуль компрессии   Установлен
  
• Используется persistent database connection
  

Далее привожу без изменений описание методики и результатов тестов, любезно предоставленное компанией One Agile

1. Отчёт о тестировании

1.1. Цели и методы проведения тестов

При нагрузочном тестировании эмулировались HTTP запросы, отправляемые пользователями на сервер. Каждый пользователь эмулируется одним «виртуальным пользователем» (vuser). Виртуальный пользователь совершает те же запросы, что реальный пользователь, который использовался при записи скрипта (включая задержки между запросами), при этом просматриваемые элементы (игры, блоги и т.д.) выбираются случайно из существующих в БД. Из-за ограничения Интернет-канала на нагрузочных серверах пользователи не запрашивали статику.

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



При создании нагрузки 70% пользователей выполняли авторизацию операции на чтение, т.е. просмотр, поиск, 20% пользователей – операции на чтение и на запись – голосование, комментирование, отправку сообщений, 10% - операции на чтение без авторизации.

Использовался следующий профиль нагрузки – инициализировалось каждые 5 секунд по 2 виртуальных пользователя до достижения количества 1200. После этого 1 час держалась постоянная нагрузка в 1200 пользователей.

Во время нагрузки собирались следующие данные: HTTP статус ответа, число ошибочных ответов, вид ошибки, время отклика. По результатам этих данных анализировалась эффективная и предельная нагрузка, которую выдерживает сайт.

1.2. Анализ результатов



1.3. Заключение

Эффективный профиль нагрузки, то есть число пользователей, на котором время отклика комфортно для пользователя, составляет около 700-800 одновременно работающих пользователей.

При этом сайт выдерживает нагрузку 1200 одновременно работающих пользователей, но с увеличением времени отклика и ростом числа 504 ошибок.

3. Количество хитов в секунду / Hits per Second





5. Среднее время выполнения транзакции / Average Transaction Response Time



7. Время выполнения транзакции при нагрузке / Transaction Response Time Under Load



8. Процессорная нагрузка и ср.время выполнения страницы / Load average



time – время теста
vusers – кол-во пользователей
page – среднее время генерации страницы
web – load average веб-сервера
db – load average сервера БД Oracle

Наблюдавшиеся проблемы

Для предотвращения неконтролируемого роста процессорной очереди на веб сервере (Load Average доходил до 176 !) было ограничено максимальное количество дочерних процессов Apache, параметр MaxClients был уменьшен c 256 до 50. Интересно, что даже при наблюдавшейся до изменения параметра MaxClients высокой процессорной нагрузке на веб сервер (Load Average>=176) сайт открывался с удовлетворительными временами создания страниц: 1-3 сек.

Первоначально, в бд клиента был установлен параметр CURSOR_SHARING=SIMILAR (что допускается рекомендациями), но собиралась статистика по распределению значений столбцов таблиц (гистограммы, что категорически не рекомендуется). Это порождало блокировки и значительные ожидания доступа к разделу shared pool System Global Area экземпляра Oracle. После рекомендаций и консультаций с ИТ службой клиента значение параметра было изменено на CURSOR_SHARING=FORCE (также рекомендованное без дополнительных условий по гистограммам) и проблема с блокировками перестала быть существенной

После решения проблем с блокировками shared pool на первое место со стороны бд вышли ожидания записи лог данных на диск сервера бд. Из статистики Oracle:



видно, что ожидание log file sync (фактически время операции записи логов на диск) занимает более 58% процессорного времени с очень высоким средним временем ожидания 35 мс. Проблема известна и партнёру, и клиенту и связана с неполным выполнением клиентом рекомендаций специалистов партнёра по конфигурации дисковой подсистемы и с особенностями конфигурации и реализации технологии Oracle Active Dataguard специалистами клиента, ответственными за эксплуатацию бд. Это не проблема Битрикс, как продукта.

При 1200 пользователей онлайн, ~50 хитов в секунду наблюдалась высокая нагрузка на веб сервере - load average: 28, связанная с повышеннной из-за дисковых ожиданий нагрузкой на сервере БД - load average: 14 (процессы веб-сервера ждали ответа от сессий бд, которые в свою очередь ждали выполнения серверным процессом Oracle операции log file sync . Интересно отметить, что при этом наблюдались удовлетворительные типичные времена оздания страниц (большую часть времени занимали операции бд insert/update):

Время создания страницы: 0.5429 сек.
Всего SQL запросов: 14
Время исполнения запросов: 0.3898 сек.

Время создания страницы: 0.7861 сек.
Всего SQL запросов: 14
Время исполнения запросов: 0.6755 сек.

В качестве эксперимента во время тестов был установлен параметр commit_write=’BATCH,NOWAIT’, позволяющий буферизовать и асинхронно выполнять операции записи логов (последнее является небезопасным с точки зрения сохранности бд и не может быть рекомендовано для business critical приложений). В конфигурации клиента это не дало заметного эффекта, пропорционально увеличив среднее время ожидания и уменьшив количество ожиданий:



В результате тестирования специалистами клиента и партнёра было выявлено несколько неэффективных с точки зрения производительности запросов в коде Битрикса (направлены на исправление, часть уже исправлена и выйдет в ближайших обновлениях продукта)

Панель производительности Oracle версии показывает совсем невыдающиеся результаты (по сравнению с эталонным MySQL)



Невысокие данные монитора производительности о скорости работы «Файловой системы» можно объяснить использованием не самого быстрого (но одного из самых надёжных) оптимизатора APC
Относительно низкая тестовая скорость операций с базой данных (Oracle на удалённом сервере) по сравнению с эталоном (MySQL на локальном) также известны и объяснимы

При этом время генерации страниц очень хорошее, на примере главной страницы:

Время создания страницы: 0.1567 сек.
Всего SQL запросов: 26
Время исполнения запросов: 0.063 сек.

- отличная работа разработчиков компании партнёра!

И хорошая зафиксированная способность справляться с высоким уровнем нагрузки (масштабироваться до 44 запроса в секунду на тяжёлой редакции «Битрикс» совсем непросто независимо от платформы, даже на "быстром" MySQL)!

Заключение

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

Также важно отметить, что основной функционалом, используемым в  тестируемом развлекательном портале, является модуль социальной сети – «слабокешируемый и тяжелый», по словам специалистов компании-партнёра. Модуль объективно содержит динамично меняющуюся информацию, и подобные внедрения помогают специалистам Битрикс выявлять и устранять «узкие» в плане производительности места

Приведённый тест кейс наглядно показывает возможности и перспективу использования Битрикс на платформе Oracle в высоконагруженных проектов класса Enterprise для обеспечения высокой производительности приложений и масштабируемости платформы. Использование промышленных технологий Oracle Real Application Cluster даёт возможность горизонтального масштабирования базы данных (с минимальным временем прерывания сервиса), а технология Битрикс хранения информации о сессиях в базе данных открывает возможности масштабирования веб-сервисов