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

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
30-Апр-2021 14:30

Цитировать

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

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

выполняли один или несколько тестовых прогонов;
оптимизировали стенд при возникновении ошибок;
анализировали объём сгенерированных сущностей и их реальности, настраивали веса типовых операций в сценарии;
финально прогоняли тест 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 %. Поэтому он способен будет выдержать всплески посещаемости без увеличения длительности отклика. А повышенная отказоустойчивость кластера позволяет проводить плановые или аварийные работы без перебоев в обслуживании.

Время отклика: 95 процентиль для некоторых страниц и их трафик в рамках теста.По результатам тестирования мы решили внедрить в ближайших обновлениях платформы такие оптимизации:

добавили индекс для сортировки в справочнике компаний;
изменили параметры кеширования некоторых стандартных объектов;

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

===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_testirovanie_itsistem (Тестирование IT-систем), #_testirovanie (тестирование), #_high_load, #_blog_kompanii_1sbitriks (
Блог компании 1С-Битрикс
), #_vysokaja_proizvoditelnost (
Высокая производительность
), #_testirovanie_itsistem (
Тестирование IT-систем
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 20:21
Часовой пояс: UTC + 5