Решения для больших компаний обычно должны выдерживать высокие нагрузки.
Когда в штате много десятков тысяч человек, и значительная доля из них ежедневно пользуются какими-либо приложениями и системами, эти продукты становятся критически важными для компании. К ним предъявляются высокие требования по производительности и отказоустойчивости. В том числе и при пиковых нагрузках. С переходом на удалённую работу количество и важность подобных систем лишь возросли.
Недавно мы вместе с Selectel провели нагрузочное тестирование корпоративного интранет-портала «1С-Битрикс24» в редакции Энтерпрайз. Хотим рассказать, как мы это делали и какие получили результаты.
Для чего нужен корпоративный портал?
Корпоративные порталы в компаниях помогают решать кучу задач. На них могут храниться всевозможные информационные документы для сотрудников. Порталы помогают автоматизировать многочисленные рутинные процессы вроде оформления заявок и запросов. Могут быть витриной для кадровых и ИТ-сервисов, выступать в роли медиа-хранилища и досок объявлений. А в сочетании с мобильными приложениями корпоративные порталы превращаются в инструмент быстрого информирования десятков тысяч сотрудников — где бы они ни находились.
О том, что собой представляет «1С-Битрикс24: Enterprise» — наша платформа для создания корпоративных порталов — мы здесь рассказывать не будем, а поговорим о её тестировании.
Тестовый стенд
Нашей задачей было создать тестовый стенд, имитирующий корпоративный портал крупной корпорации, в которой работают не менее 100 тысяч сотрудников, с большим объемом данных, и затем протестировать его в условиях экстремальных пиковых нагрузок.
Для нагрузочного тестирования образца корпоративного портала мы создали кластер из 5 серверов. Все заботы об оборудовании взяла на себя Selectel. Машины были двух конфигураций:
Сервер баз данных (2 шт): Intel Xeon W-2255, 3,7 ГГц, 10 ядер; 128 ГБ DDR4; 2 × 960 ГБ NVMe +2 × 8 ТБ HDD.
Сервер приложений (3 шт): Intel Xeon E-2236, 3,4 ГГц, 6 ядер; 32 ГБ DDR4; 2 x 480 ГБ SSD.
Мы выбрали такие конфигурации и их соотношение для того, чтобы кластер был высокопроизводительным, устойчивым к сбоям, но при этом не обходился втридорога.
Затем настроили ПО на серверах с помощью готовой сборки «1С-Битрикс: Виртуальная машина» для Linux 7.4.3. В кластере мы применили два раздельных пула: один для балансировки HTTP-запросов, работы веб-приложения и сервера мгновенных сообщений; второй для работы баз данных и системы кеширования.
Общая схема тестового стенда:
Из чего состоял стенд:
app1, app2, app3 | Кластер из трех серверов приложений (веб-серверов): CentOS 7.9, Nginx 1.18, Apache 2.4, PHP 7.3. Балансировка нагрузки выполнялась с помощью Nginx на app1. |
db1, db2 | Кластер из двух серверов баз данных: CentOS 7.9, Percona Server (MySQL) 8.0.22, конфигурация Master / Slave. |
storage of metrics | Мониторинг серверов, сбор метрик с Nginx, mysql-percona, метрики по процессору, памяти и т.п. На основе Zabbix 4.4. |
load server | Сервер генерации нагрузки с использованием Jmeter 5.3.3. |
collection of indicators | Связка из высокопроизводительной базы данных InfluxDB для получения и хранения данных от Jmeter и Grafana для отображения и визуализации результатов теста. |
На стенде мы развернули типовое коробочное решение «1С-Битрикс24: Enterprise» версии 20 с последними обновлениями, с использованием технологии кластеризации в модуле «Веб-кластер». В базе данных создали записи для 111 304 сотрудников, распределив их по 67 структурным подразделениям. Тестовые данные, наполнявшие серверы на момент запуска последнего теста, содержали: 590 тыс. сообщений в живой ленте, 540 тыс. комментариев, 40 тыс. новостей, 180 тыс. задач, 415 тыс. мгновенных сообщений.
Нагрузка и методика тестирования
Тестовая нагрузка на портал должна была моделировать одновременную работу не менее чем 1/3 от всех сотрудников (30 000 пользователей). Нагрузку мы генерировали с помощью JMeter 5.3.3. Результаты тестов сохраняли в InfluxDB — эта БД выдерживает большую нагрузку на запись и чтение. Графики строили с помощью Grafana, а серверы мониторили в Zabbix.
Мы поставили перед собой задачу, чтобы тесты проходили без ошибок для 1, 5, 10, 20 и 30 тыс. одновременных пользователей (потоков JMeter). При этом у нас не было цели выжать максимальные значения RPS, потому что для корпоративных порталов это не так важно. Куда важнее было проверить безотказность и стабильность в условиях пиковых нагрузок.
Для тестирования выбрали 29 сценариев в 13 функциональных блоках. Цепочки были характерные для типового интранет-портала: авторизация, живая лента, поиск, чат (групповой и один на один), задачи, календарь, новости, фотогалерея, сотрудники, профиль, бизнес-процессы, рабочие группы. Для каждого сценария мы подобрали веса, учитывающие работу различных пользователей на портале и долю каждого из функциональных блоков в общей нагрузке.
Нагрузка создавалась большим количеством разных пользователей с отдельными учётными записями. Генератор нагрузки авторизовывал каждого такого пользователя в системе, а затем выполнял под ним разнообразный набор сценариев. Например, при работе с задачами пользователи могли просматривать их в виде списка, диаграммы Ганта, Kanban-доски или календаря, искать задачи, создавать новые, а также комментировать, выполнять и завершать их. Всё это учитывалось в построении цепочек и назначении им весов.
Между сценариями мы делали паузу от 20 секунд до 10 минут, чтобы как можно точнее смоделировать реальное поведение сотрудников, которые зашли в интранет-портал и работают с ним в течение дня.
Методика тестирования, сценарии и профили нагрузки, использование физических пользовательских профилей максимально приблизили условия теста к реальным.
Тестирование проводили итерационно, и в каждой итерации:
выполняли один или несколько тестовых прогонов;
оптимизировали стенд при возникновении ошибок;
анализировали объём сгенерированных сущностей и их реальности, настраивали веса типовых операций в сценарии;
финально прогоняли тест 2-3 часа, фиксировали результаты и переходили к следующей итерации.
Во время тестирования мы оптимизировали некоторые настройки типового решения:
увеличили время кеширования компонентов (дни рождения, важное) на главной странице портала;
отключили типовой компонент «кто на сайте» и компонент статистики;
изменили настройки ряда констант в dbconn.php;
выполнение всех агентов перенесли на Cron (https://dev.1c-bitrix.ru/community/webdev/user/8078/blog/2755/);
в главном модуле включили быструю отдачу файлов через nginx;
в модуле push&pull включили использование последней версии сервера мгновенных сообщений.
Также были внесены изменения в продукт, позволяющие повысить производительность отдельных компонентов.
В итоге нам удалось успешно «прогнать» все тесты согласно плану тестирования. В финальном тесте на 30 тысяч одновременных пользователей (потоков jMeter) удалось добиться стабильного и быстрого отклика системы.
Результаты
Портал обеспечивал работу одновременно 30 тыс. пользователей из общего количества в 111 тыс. При этом в 95 % обращений длительность ответа портала не превышала 0,9 с.
Суточный запуск данного теста обеспечивает генерацию в рамках портала:
936 новостей;
110 736 сообщений в живой ленте;
112 440 комментариев;
10 560 чатов;
81 264 мгновенных сообщений;
55 128 заданий бизнес-процессов;
21 888 задач;
8 808 документов;
2 208 рабочих групп и проектов;
6 984 встреч в календарях;
57 240 уведомлений.
При обработке запросов от 30 тысяч пользователей кластер работал вовсе не на пределе возможностей, у него был приличный запас по производительности — 30-40 %. Поэтому он способен будет выдержать всплески посещаемости без увеличения длительности отклика. А повышенная отказоустойчивость кластера позволяет проводить плановые или аварийные работы без перебоев в обслуживании.
По результатам тестирования мы решили внедрить в ближайших обновлениях платформы такие оптимизации:
добавили индекс для сортировки в справочнике компаний;
изменили параметры кеширования некоторых стандартных объектов;
добавили дополнительный индекс для проверки прав календаря;
изменили метод выборки списка групп в Kanban-доске;
оптимизировали очистку очереди с подпиской на уведомления изменений различных сущностей;
добавили индекс сортировки бизнес-процессов, отключили постраничную навигацию;
уменьшили отсечку по времени для построения списка в живой ленте;
при отправке счетчиков убрали ожидание получения блокировки БД;
реализовали единый запрос для получения информации по количеству лайков для всех сообщений и комментариев к ним в живой ленте, выводимых в данный момент на странице;
внедрили механизм очереди при отправке уведомлений при добавлении сообщений в живую ленту;
добавили индексы для репликации;
оптимизировали очистку тегированного кеша.
