30 тысяч пользователей одновременно: как мы тестировали корпоративный портал «1С-Битрикс24: Enterprise»

Решения для больших компаний обычно должны выдерживать высокие нагрузки. 

Когда в штате много десятков тысяч человек, и значительная доля из них ежедневно пользуются какими-либо приложениями и системами, эти продукты становятся критически важными для компании. К ним предъявляются высокие требования по производительности и отказоустойчивости. В том числе и при пиковых нагрузках. С переходом на удалённую работу количество и важность подобных систем лишь возросли. 

Недавно мы вместе с Selectel провели нагрузочное тестирование корпоративного интранет-портала «1С-Битрикс24» в редакции Энтерпрайз. Хотим рассказать, как мы это делали и какие получили результаты.

Для чего нужен корпоративный портал?

Корпоративные порталы в компаниях помогают решать кучу задач. На них могут храниться всевозможные информационные документы для сотрудников. Порталы помогают автоматизировать многочисленные рутинные процессы вроде оформления заявок и запросов. Могут быть витриной для кадровых и ИТ-сервисов, выступать в роли медиа-хранилища и досок объявлений. А в сочетании с мобильными приложениями корпоративные порталы превращаются в инструмент быстрого информирования десятков тысяч сотрудников — где бы они ни находились. 

О том, что собой представляет «1С-Битрикс24: Enterprise» — наша платформа для создания корпоративных порталов — мы здесь рассказывать не будем, подробно о ней рассказано здесь. А теперь — о тестировании.

Тестовый стенд

Нашей задачей было создать тестовый стенд, имитирующий корпоративный портал крупной корпорации, в которой работают не менее 100 тысяч сотрудников, с большим объемом данных, и затем протестировать его в условиях экстремальных пиковых нагрузок. 

Для нагрузочного тестирования образца корпоративного портала мы создали кластер из 5 серверов. Все заботы об оборудовании взяла на себя Selectel. Машины были двух конфигураций:

1. Сервер баз данных (2 шт): Intel Xeon W-2255, 3,7 ГГц, 10 ядер; 128 ГБ DDR4; 2 × 960 ГБ NVMe +2 × 8 ТБ HDD.

2. Сервер приложений (3 шт): Intel Xeon E-2236, 3,4 ГГц, 6 ядер; 32 ГБ DDR4; 2 x 480 ГБ SSD.

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

Затем настроили ПО на серверах с помощью готовой сборки «1С-Битрикс: Виртуальная машина» для Linux 7.4.3. В кластере мы применили два раздельных пула: один для балансировки HTTP-запросов, работы веб-приложения и сервера мгновенных сообщений; второй для работы баз данных и системы кеширования.

Общая схема тестового стенда:

Из чего состоял стенд:

На стенде мы развернули типовое коробочное решение «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-доске;

• оптимизировали очистку очереди с подпиской на уведомления изменений различных сущностей; 

• добавили индекс сортировки бизнес-процессов, отключили постраничную навигацию;    

• уменьшили отсечку по времени для построения списка в живой ленте;    

• при отправке счетчиков убрали ожидание получения блокировки БД;    

• реализовали единый запрос для получения информации по количеству лайков для всех сообщений и комментариев к ним в живой ленте, выводимых в данный момент на странице;    

• внедрили механизм очереди при отправке уведомлений при добавлении сообщений в живую ленту;    

• добавили индексы для репликации;    

• оптимизировали очистку тегированного кеша.