BitrixEnv — оптимизация настроек сервера под сайт на bitrix
В очередной раз пришлось повозиться с настройкой Bitrixenv и сайта на нем. В какой-то момент bitrix сайт стал сыпать 500-е ошибки на некоторые операции. По логам было видно, что не хватает памяти для работы некоторых скриптов, хотя раньше хватало. Пришлось заняться расследованием и оптимизацией потребления памяти bitrix сайтом.
Если у вас есть желание научиться администрировать системы на базе Linux, рекомендую познакомиться с онлайн-курсом «Linux для начинающих» в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Подробная информация.
Цели статьи
- Разобраться с потреблением памяти на сервере с bitrixenv — выяснить, кто больше всех потребляет памяти и приводит к нестабильной работе сервера.
- Разобраться, где хранятся настройки различных приложений в bitrixenv.
- Выбрать оптимальные параметры для apache, mysql, php, nginx для равномерного распределения памяти.
Введение
Вопрос с потреблением памяти mysql при работе в bitrixenv я уже разбирал отдельно некоторое время назад — где хранятся настройки mysql. Рекомендую с ней ознакомиться, так как там информация напрямую относящаяся к текущей теме оптимизации использования памяти сайта на bitrix при работе в bitrixenv.
Разработчики bitrixenv упростили работу системных администраторов по настройке сервера, внедрив службу bvat, которая автоматически при запуске сервера подбирает оптимальные параметры следующих служб:
- mysql
- apache
- nginx
- php
В моем случае стандартные настройки перестали подходить. На сервере время от времени появлялась нехватка оперативной памяти. Приходил OOM Killer (OOM — Out of memory) и грохал mysql сервер, так как он потреблял больше всего оперативной памяти.
Какое-то время все работало нормально, потом провторялось то же самое.
Мое внимание привлекли события из мониторинга Zabbix, такие как
Зашел на сервер, посмотрел системный лог. Увидел там вот это:
kernel: Out of memory: Kill process 7382 (mysqld) score 431 or sacrifice child kernel: Killed process 7382 (mysqld) total-vm:3967860kB, anon-rss:1942144kB, file-rss:0kB, shmem-rss:0kB systemd: mysqld.service: main process exited, code=killed, status=9/KILL systemd: Unit mysqld.service entered failed state. systemd: mysqld.service failed. systemd: mysqld.service holdoff time over, scheduling restart. systemd: Stopped MySQL Server. systemd: Starting MySQL Server... systemd: Started MySQL Server.
Первое, что я сделал — увеличил swap раздел до объема всей оперативной памяти. До этого он был размером в 1G.
Это сразу помогло и предотвратило регулярный приход OOM Killer. А я стал спокойно разбираться, что делать дальше.
План дальнейшей настройки сервера для стабильной работы сайта на bitrix следующий:
- Определяем основных потребителей оперативной памяти.
- Распределяем всю свободную память между ними.
- Убеждаемся, что под нагрузкой все работает корректно, всем хватает памяти, OOM Killer не приходит.
Изменение стандартных настроек BitrixVM
Как я уже говорил, служба bvat автоматически регулирует некоторые настройки стандартных служб bitrixenv. Чтобы применять наши настройки, нужно их указывать в отдельных конфигурационных файлах.
- MySQL — /etc/mysql/conf.d/z_bx_custom.cnf
- Apache — /etc/httpd/bx/custom/z_bx_custom.conf
- nginx — /etc/nginx/bx/conf/z_bx_custom.conf
- PHP — /etc/php.d/z_bx_custom.ini
А вот общий список всех основных конфигурационных файлов bitrixenv:
- /etc/php.d/bitrixenv. ini — основные настройки php
- /etc/httpd/bx/conf/prefork.conf — параметры модуля Apache — MPM prefork;
- /etc/php.d/z_bx_custom.ini — пользовательские настройки PHP;
- /etc/httpd/bx/custom/z_bx_custom.conf — пользовательские настройки Apache;
- /etc/mysql/conf.d/z_bx_custom.cnf — пользовательские настройки MySQL;
- /etc/nginx/bx/conf/z_bx_custom.conf -пользовательские настройки nginx;
- /etc/nginx/bx/conf/push-im_settings.conf — настройки nginx-push-stream-module.
ini — основные настройки phpОптимизация настроек Mysql
На подопытном сервере имеется 12 Гб оперативной памяти. Я решил половину этой памяти отдать под mysql. Приступим к тюнингу конфигурации mysql. В общем случае достаточно будет одного параметра, который в основном отвечает за потребление памяти:
innodb_buffer_pool_size = 4G
В моем случае этого было недостаточно. Я решил более внимательно подойти к настройке mysql. Нашел неплохой инструмент — MySQLTuner, который анализируя работу mysql, выдает некоторые рекомендации по настройке.
Сам я не разбираюсь в тонкой настройке mysql, поэтому решил довериться утилите. Судя по отзывам, она неплоха и доверять ей можно, если сам не разбираешься в теме. Забегая вперед скажу, что с помощью этого тюнера я настроил mysql на стабильную работу с фиксированным потребелением памяти. Проблем с этим сервером с тех пор не возникало.
Итак, копируем себе на сервер сам скрипт:
# wget http://mysqltuner.pl/ -O mysqltuner.pl
Запускаем его:
# perl mysqltuner.pl
Для того, чтобы рекомендации получились более эффективные, служба mysql должна поработать у вас несколько дней. Если накануне перезапускали ее, а я это делал, то рекомендую через несколько дней зайти и еще раз прогнать тесты. Будут новые советы по конфигу.
Для оптимизации потребления памяти, достаточно будет прогнать скрипт в любое время. Я вам рекомендую внимательно изучить его возможности. Подробно на них я сейчас не буду останавливаться, а рассмотрю только то, что касается памяти. Помимо прочего, вы увидите следующую информацию.
У меня уже все оптимизировано под потребленее не более примерно 6 Гб памяти. Расскажу, какие параметры за это отвечают. Как уже сказал ранее, это параметр innodb_buffer_pool_size. В общем случае для mysql сревера рекомендуют указывать этот параметр равный 80% доступной памяти сервера. Но это в том случае, если у вас кроме mysql на этом сервере ничего не крутится. А у нас там полно других служб, поэтому нам такой совет не подходит.
Дальше нам нужно выяснить, сколько памяти занимает thread (процесс, который порождает соединение) и в соотвествии с этим выставить предел числа подключений. Размер thread равен сумме следующих парметров — read_buffer_size + sort_buffer_size + join_buffer_size.
Параметр read_buffer_size установлен по-умолчанию в 128 КБ. Я его не стал трогать. Остальные два я изначально выставил по рекомендациям mysqltuner, а значение max_connections, которое отвечает за максимальное количество подключений, выставил такое, чтобы сумма трех буферов, помноженная на количество подключений не превышала 2 Гб памяти.
Сервер немного поработал в таком режиме и выяснилось, что выставленных подключений не хватает. Тогда я снизил join_buffer_size до 18 Мб, а количество подключений увеличил. В итоге остановился на таких настройках.
innodb_buffer_pool_size = 4G sort_buffer_size = 18M join_buffer_size = 18M max_connections = 70
С такими настройками максимальное потребление памяти службой mysql не будет превышать 6.8 Гб, о чем подсказывает вывод mysqltuner. Конкретно моему сайту 70 подключений к mysql достаточно. До этого поставил 50, были сообщения о нехватке подключений. На своем сервере выбирайте параметры сами, у меня не копируйте.
[OK] Maximum possible memory usage: 6.8G (58.69% of installed RAM)
На практике так и получилось. Через несколько дней я зашел и прогнал еще раз проверку, которая показала, что реально использование памяти не вышло за эти пределы. Плюс, подредактировал некоторые параметры.
Советы по изменению параметров даются в заключительной секции mysqltuner — Variables to adjust.
Не буду приводить свои рекомендации, так как они будут актуальны только для конкретного сервера. Советую посмотреть все рекомендации, почитать описание параметров и попробовать применить их у себя. Слепо не надо менять то, что там советуют.
Приведу список основных параметров mysql, которые влияют на производительность и на которые надо в первую очередь обращать внимание:
- max_connections
- log_bin
- table_open_cache_size
- table_definitions_cache_size
- open_files_limit
- innodb_buffer_pool_size
- innodb_log_file_size
- innodb_flush_log_at_trx_commin
- innodb_flush_method=O_DIRECT
Список взял отсюда. Очень полезная статья, рекомендую.
Оптимизация настроек apache в bitrixenv
Дальше переходим ко второму основному потребителю оперативной памяти на сервере с сайтом на bitrix — apache. Ему, как и для mysql, служба bvat автоматически выставляет некоторые настройки. Она хранятся в файле /etc/httpd/bx/conf/prefork.
conf. Нас будут интересовать настройки, касающиеся количества запущенных процессов.
Чтобы узнать, количество запущенных процессов httpd, обслуживающих работу bitrix сайта, введите в консоли сервера команду:
# ps ax | grep httpd | wc -l
Вы получите число, на 2 больше, чем указано в приведенном конфиге, в параметрах модуля mpm_prefork. В моем случае bvat выставлял максимально возможное количество процессов httpd равное 60, но для меня это было слишком много, сервер не тянул такое количество процессов. Я его уменьшил до 30.
Как вы понимаете, в зависимости от bitrix сайта, один процесс httpd будет использовать разное количество памяти, поэтому автоматически невозможно выставить этот параметр корректно для всех сайтов. В данном случае, дефолтный параметр мне не подошел, поэтому я создал свой файл настроек httpd — /etc/httpd/bx/custom/z_bx_custom.conf.
Привожу скриншотом, потому что движок сайта проглатывает все строки в угловых скобках.
Не получается выложить полностью конфиг в текстовом виде. В общем случае, вам надо посмотреть, сколько у вас занимает памяти один процесс httpd и рассчитать максимальное количество процессов, которое потянет ваш сервер.
Посмотреть, сколькло памяти занимает один процесс httpd можно в htop или с помощью команды:
# ps -o vsz,rss,cmd --pid $(pgrep httpd)
Будет один основной процесс, который занимает больше всего памяти и дальше его форки, которые потребляют примерно одинаково. На них и ориентируйтесь. У меня основной процесс потребляет 500 Мб и 30 форков по 100 Мб. В сумме получается 3.5 Гб.
Итого в пике у меня 6.5 Гб использует mysql и 3.5 Гб использует httpd, итого 10 Гб из доступных 12-ти. На практике, свободной памяти обычно больше, чем 2 Гб, так как mysql чаще всего потребляет ниже максимального предела.
Оптимизация php под bitrix
Из настроек php я бы обратил внимание на следующие параметры:
- memory_limit — максимальное количетсво памяти на выполнение php скрипта;
- sendmail_path — управляет параметрами отправки сообщений, хотя к теме текущей статьи и не имеет отношение;
- post_max_size — максимальный размер данных для всего POST запроса;
- upload_max_filesize — максимальный размер файла для загрузки через POST запрос;
- max_execution_time — максимальное время в секундах, в течение которого скрипт должен полностью загрузиться.
Так или иначе, эти параметры, кроме sendmail, влияют на производительнойсть сервера и потребление памяти. Не ставьте эти значения слишком большими без особой надобности. Я бы для начала выставил в 256 Мб и увеличивал по мере необходимости. Да, 256 Мб это и так очень много, но сайт на bitrix требует высоких значений этих параметров для корректной работы. 256 мб это общая рекомендация для дефолтных значений.
Свои параметры php вы можете размещать в отдельном конфиге, который не будет перетираться bitrixenv — /etc/php.d/z_bx_custom.ini. После изменения настроек надо перезапускать apache для применения.
Настройка nginx для сайта bitrix
В самом nginx в bitrixenv настраивать для производительности особо нечего. Он работает в качестве proxy сервера для apache. С помощью proxy_pass он перенаправляет все динамические запросы, а сам отдает только статику. В таком режиме работы он потребляет минимум ресурсов и оптимизировать в нем нечего. Если вам все же интересно разобраться в настройках nginx, то читайте мою отдельную подробную статью.
Отдельной настройки требует только модуль Push and Pull, если он у вас используется. Его конфигурация располагается в файле /etc/nginx/bx/conf/push-im_settings.conf. В контексте данной статьи нас интересует только параметр push_stream_shared_memory_size, который отвечает за использование оперативной памяти.
В принципе, дефолтного значения 256 Мб обычно хватает, хотя по сути это небольшие цифры. Но имейте ввиду, что если свободной памяти совсем нет, то можно подрезать этот параметр.
Заключение
После оптимизации всех указанных выше параметров в bitrixenv, потребление памяти сервером стабилизировалось. Bitrix сайт стал работать ровно с предсказуемой производительностью без неожиданных тормозов и падений.
На этом у меня все по теме оптимизации настроек сервера под bitrix. Система интересная и многогранная. Всегда любопытно заглянуть под капот bitrixenv. Как по мне, сделано неплохо, хотя и доставляет хлопот при разборе каких-то иницидентов.
В целом считаю, что в общем случае, все сделано удобно и функционально для быстрого запуска bitrix сайта. Справится даже неподготовленный человек, а конкретно какой-нибудь программист. Он бы запарился настраивать эту связку самостоятельно, а тут все из коробки работает. Но вот если возникают проблемы, то разобраться бывает не всегда просто.
Следующим этапом жду появление docker сборок с bitrixenv внутри. Либо один общий образ, либо набор через docker-compose. Это было бы логичное продолжение развития в свете популярности контейнеров и микросервисов.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Проверьте себя на вступительном тесте и смотрите подробнее программу по ссылке.
Помогла статья? Подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.Скачать pdf
mysql — PHP Fatal error: Allowed memory size of 4731174912 bytes exhausted. Где увеличить?
Задать вопрос
Вопрос задан
Изменён 3 года 10 месяцев назад
Просмотрен 1k раз
Непонятно почему в один прекрасный день скрипт стал выбрасывать ошибку
PHP Fatal error: Allowed memory size of 4731174912 bytes exhausted (tried to allocate 256 bytes) in /var/www/html/bitrix/modules/main/classes/general/usertype.
php on line
2807причем размер 4731174912 во всех случаях один и тот же и в разных файлах (ошибка).
Пытались увеличить лимит в my.cnf, но результата это не дало.
На сервере 16 Гб, но почему-то упирается именно в 4731174912.
Где можно увеличить лимит памяти, или может причина в чем-то другом?
usertype.php:
database.php:
- php
- mysql
- битрикс
- debian
- выполните вместо вашего кода phpinfo(), посмотрите текущий memory_limit, посмотрите где лежит ваш php.ini
- отредактируйте его, измените memory_limit на значение побольше
- перезапустите веб-сервер, если php — модуль apache (или fpm)
- проверьте в phpinfo, что изменения применены
- если изменения не применены — то или вы отредактировали не тот конфиг, или не правильно осуществили перезапуск, или управляется где-то в вашем коде (значение можно выставить в скрипте при помощи инструкции ini_set(«memory_limit», «<объем_памяти>»)
но все это не решение проблемы.
4+Гб на 1 хит — это сверхмного, такого быть не должно, код нужно оптимизировать.
Зарегистрируйтесь или войдите
Регистрация через Google Регистрация через Facebook Регистрация через почтуОтправить без регистрации
ПочтаНеобходима, но никому не показывается
Отправить без регистрации
ПочтаНеобходима, но никому не показывается
By clicking “Отправить ответ”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.
Производительность
В ноябре 2022 года мы провели нагрузочное тестирование Битрикс24 Self-hosted (Enterprise edition) с развернутым CRM-решением для оценки его производительности.
Общая информация
В ходе нагрузочного теста мы развернули CRM-систему в кластерном решении, заполнили ее большим объемом тестовых данных и подвергли нагрузке, имитирующей поведение реальных пользователей. Операции, выполняемые в целях нагрузочного тестирования, включали стандартные сценарии CRM: авторизация в системе, работа с клиентской базой, управление лидами, обработка сделок и обновление статуса сделок, обмен мгновенными сообщениями и загрузка документов.
Исходя из потребностей крупного корпоративного сегмента, мы определили ключевые задачи такого тестирования:
- моделирование работы CRM-системы, развернутой в крупной корпорации (десятки тысяч сотрудников, тысячи пользователей CRM + большой объем демонстрационных данных, с высокой интенсивностью информационных потоков)
- предоставить методологию тестирования, максимально приближенную к поведению пользователя в реальной жизни
- демонстрируют стабильную работу встроенных технологий масштабирования и отказоустойчивости Битрикс24 на имеющемся оборудовании
- гарантирует, что время отклика развернутого решения не превышает 1 секунды.
Условия испытаний
Оборудование
Для проведения теста были выбраны выделенные виртуальные серверы. Это позволило эмулировать полномасштабное кластерное решение с одновременным снижением накладных расходов на развертывание и поддержку инфраструктуры. Как и в предыдущем тестировании, мы использовали оборудование из доступного на рынке среднего ценового сегмента.
Аппаратное обеспечение, предоставленное для тестирования, включало три конфигурации серверов:
- Сервер баз данных (2 шт.): Intel Xeon (Skylake, IBRS): 2294 МГц (10 ядер), 48 ГБ RAM, 300 ГБ HDD
- Сервер приложений (2 шт.): Intel Core (Haswell, noTSX, IBRS): 1995 МГц (6 ядер), 24 ГБ RAM, 200 ГБ HDD
- Генератор нагрузки (1 шт.): Intel Xeon (Skylake, IBRS): 2294 МГц (10 ядер), 24 ГБ RAM, 300 ГБ HDD.
Кластерное решение и веб-среда
| pfweb1, pfweb2 | Кластер с двумя серверами приложений (веб-серверами): CentOS 7. 9, Nginx 1.20.2, Apache 2.4.6, PHP 8.0.19. Балансировка выполнялась с использованием Nginx на pfweb1 |
| пфдб1, пфдб2 | Кластер с двумя серверами баз данных: CentOS 7.9, Percona Server (MySQL) 8.0.29, конфигурация Master/Slave. |
| пфм | Сервер генерации нагрузки с Jmeter 5.3.3 InfluxDB для извлечения и хранения данных Jmeter и Grafana для отображения и визуализации результатов тестирования |
| процессы данных и потоки (1-7) |
|
Мы развернули кластер с 2 серверами баз данных и 2 серверами приложений.
Эта конкретная конфигурация является стандартной и наиболее распространенной, она выбрана для обеспечения высокой производительности кластера, а также обеспечивает высокую доступность. Программное обеспечение Сервера
настроено с использованием Виртуальной машины Битрикс24 для Linux 7.5.2 и включенного модуля Web Cluster для создания кластерного решения.
После проведения первоначальных «пробных» тестов конфигурации серверов были обновлены.
Список обновлений веб-окружения:
- обновлены параметры операционной системы:
- эхо 1024 65000 > /proc/sys/net/ipv4/ip_local_port_range
- sysctl -w net.ipv4.tcp_tw_recycle=1
- sysctl -w net.ipv4.tcp_tw_reuse=1
- sync_binlog увеличен до 1000
- innodb_buffer_pool_size увеличен до 34 ГБ
- max_heap_table_size установлено как 256 МБ
- max_heap_table_size, max_heap_table_size установлено как 90 МБ
- myisam_sort_buffer_size увеличен до 64 МБ
- max_connections увеличено до 305
Тестовое решение для интранет-портала
В кластерном решении был развернут Битрикс24 Самостоятельный (Enterprise edition) версии 22.
375 (версия основного модуля).
- Стандартный Битрикс24 Самостоятельный (редакция Enterprise), версия 22.375 с последними обновлениями и включенным модулем Web Cluster для создания кластерного решения.
- Демонстрационный контент в начале финального теста:
- 500 000 компаний
- 1 515 000 контактов
- 995 000 лидов
- 500 000 сделок
- 144 000 товаров по каталогу
- 9391 000 событий CRM
- 4 522 000 записей временной шкалы CRM
- 36 000 сообщений ленты новостей
- Количество сотрудников в базе данных портала на момент начала итогового тестирования составляет 22 198 человек (распределено по 14 структурным подразделениям).
Метод генерации нагрузки
Тестирование проводилось по двум основным сценариям CRM:
- Сценарий «Быстрые лиды» с большим количеством менеджеров (до 500 и более), которые управляют потоком входящих лидов для последующей квалификации лидов как проигрыш или выигрыш/конверсия в сделку по покупке товаров/услуг.
- Сценарий «Долгосрочные сделки» с большим количеством менеджеров (до 100 и более), которые ведут сделки, ограничено на 1 менеджера. Каждый день менеджер добавляет новые статусы и обновляет обработанные сделки: назначает встречи, загружает документы, комментарии, звонки и корректирует спецификацию. Ключевая особенность: большое количество товаров в индивидуальной сделке.
Тест предполагал использование компанией одновременно обоих сценариев, связанных с несколькими направлениями бизнеса.
Выбранный сценарий загрузки оказался достаточно ресурсоемким, что позволило проверить работоспособность как портала Битрикс24, так и функции CRM в рамках сложных проектов.
Подробная информация о тестовых сценариях представлена ниже:
| Сценарий (нагрузка %) | Действие | Вес, % |
| Быстрые лиды (80%) | Автор | 100 |
| Список потенциальных клиентов | 100 | |
| Повторный список потенциальных клиентов | 100 | |
| Интерес | 100 | |
| Загрузка продукта 9 0044 | 100 | |
| Загрузка продукта 2 | 100 | |
| Потерянный лид | 18 | |
| Выигранный лид | 2 | |
| Обновление канбана, лиды, пуш | 100 | |
| Список лидов | 100 9 0044 | |
| Авторизация (20%) | Авторизация | 100 |
| Список потенциальных клиентов | 100 | |
| Список сделок | 100 | |
| Открытая сделка | 100 | |
| Загрузка платежных документов | 100 | |
| Добавление вызова | 5 | |
| Компании (1%) | Авторизация | 100 |
| Список лидов | 100 | |
| Список компаний | 100 |
Нагрузка создана с помощью инструмента JMeter версии 5.
5. Тестовые данные были записаны через InfluxDB, высокопроизводительную базу данных, предназначенную для обработки высоких нагрузок запросов и записей. Аналитики использовали Grafana для визуализации. Мониторинг серверов осуществлялся с помощью приложения Telegraf.
Метод генерации нагрузки
CRM-система Битрикс24 (редакция Enterprise), работающая в рамках тестовых сценариев, эмулирующих решение на базе CRM для крупной компании, развернутое на кластере из 4 физических серверов в ходе 24-часового тестирования, обеспечила стабильную одновременную работу CRM для 3000 сотрудников.
Система мониторинга продемонстрировала 423 874 системных запроса за сутки со средним временем ответа 0,713 секунды в 95% запросов.
Итоги теста: количество потоков, динамика количества запросов в секунду, общее количество запросов и ошибок:
Время отклика. 95 процентилей для конкретных страниц и их трафика в рамках теста:
Использование ЦП на серверах баз данных и приложений:
Заключение
Результаты нагрузочного теста Битрикс24 Self-hosted (Enterprise edition) подтвердили высокую производительность платформы и стабильность в условиях высокой нагрузки.
Демонстрационное CRM-решение, развернутое в кластерном решении из 4 серверов , обеспечивало одновременную работу 3000 пользователей , что соответствует примерному профилю нагрузки для крупной корпорации.
При этом система обеспечивала быструю (даже по меркам интернет-проектов) ответ, не превышающий 1 секунду для большинства запросов, что обеспечивает бесперебойную работу пользователей. Технология веб-кластеров в очередной раз доказала свою производительность и надежность.
Методика тестирования, сценарии и профили нагрузки, а также использование физических профилей пользователей позволили получить условия тестирования, максимально приближенные к реальным. Это означает, что результаты этого теста можно использовать в качестве эталона для разработки новых проектов.
Мы готовы предоставить по запросу корпоративных заказчиков и интеграторов методологию тестирования, конфигурацию портала и тестовую среду для проведения полномасштабного тестирования порталов заказной разработки или их прототипов, проверки гипотез, расчета запас прочности нашего решения при пиковых нагрузках.
Среду тестирования можно дополнительно настроить, например, добавив интеграцию с корпоративными системами компании, чтобы обеспечить более точные результаты.
Пожалуйста, свяжитесь с нами для получения дополнительной информации о тестировании.
В январе 2021 года мы провели нагрузочное тестирование собственной версии Битрикс24 (Enterprise edition) для оценки производительности построенного на его базе интранет-портала крупной компании.
Общая информация
Во время нагрузочного теста интранет-портал, развернутый в кластерном решении и заполненный большим объемом тестовых данных, подвергся нагрузке, имитирующей поведение реальных пользователей.
Виртуальные пользователи выполняли наборы операций, напоминающие типичные сценарии работы:
- вход/выход
- чтение новостей
- открытие рабочих групп
- просмотр новостной ленты
- создание индивидуальных и групповых чатов
- обмен мгновенными сообщениями
- постановка задач
- загрузка документов
- запуск бизнес-процессов
Каждый пользователь выполнил один из типовых сценариев и завершил свою работу на портале.
Тестовые задачи
- имитировать работу интранет-портала крупной корпорации (100 000 сотрудников + большой объем демонстрационных данных)
- предоставить методологию тестирования, максимально приближенную к поведению пользователя в реальной жизни
- продемонстрировать стабильную работу портала без ошибок на имеющемся оборудовании (в ситуации, когда ⅓ всех сотрудников компании (не менее 30 000) одновременно используют портал)
- обеспечить время отклика портала не более 1 секунды (для 95% запросов)
Условия испытаний
Оборудование
Аппаратное обеспечение, предоставленное для тестирования, представляло собой физические серверы в двух конфигурациях:
- Сервер базы данных: Intel Xeon W-2255 3,7 ГГц (10 ядер), 128 ГБ DDR4, 2 x 960 ГБ NVMe + 2 x 8000 ГБ HDD Сервер приложений
- : Intel Xeon E-2236 3,4 ГГц (6 ядер), 32 ГБ DDR4, 2 x 480 ГБ SSD
Был развернут кластер из 2 серверов баз данных и 3 серверов приложений (веб-серверов).
Эта конкретная конфигурация была выбрана для обеспечения высокой производительности кластера, а также обеспечения высокой доступности.
Проверка параметров портала интрасети
1. Стандартная локальная версия Битрикс24 (Enterprise edition), версия 20.x.x с последними обновлениями и включенным модулем Web Cluster для создания кластерного решения.
2. Демонстрационный контент на старте финального теста:
- 590 000 сообщений в ленте
- 540 000 комментариев
- 40 000 новостных сообщений
- 180 000 задач
- 415 000 мгновенных сообщений
3. Количество сотрудников в базе данных портала на момент начала итогового тестирования составляет 111 304 человека (распределено по 67 структурным подразделениям).
Метод генерации нагрузки
Нагрузка создавалась с помощью инструмента JMeter версии 5.3.3. Тестовые данные были записаны через InfluxDB, высокопроизводительную базу данных, предназначенную для обработки высоких нагрузок запросов и записей.
Аналитики использовали Grafana для визуализации. Мониторинг серверов осуществлялся с помощью системы мониторинга Zabbix.
Для тестирования было выбрано 29 сценариев из 13 блоков, характерных для типичного интранет-портала:
- Авторизация
- Подача
- Поиск
- Чаты (групповые и один на один)
- Задачи
- Календарь
- Привод
- Сообщения новостей
- Картинная галерея
- Сотрудники
- Профиль
- Бизнес-процессы
- Рабочие группы
Для каждого теста использовалась специальная система распределения нагрузки с учетом работы различных пользователей на портале и доли каждого из блоков в общей нагрузке.
В отличие от предыдущего нагрузочного теста 2015 года, мы использовали новый метод генерации пользовательской нагрузки. Вместо одного виртуального пользователя, случайным образом выполняющего наборы стандартных действий, нагрузку создавало большое количество разных пользователей, каждый со своей учетной записью на портале.
Генератор нагрузки зарегистрировал каждого из этих пользователей в системе, а затем выполнил другой набор пользовательских сценариев под этой учетной записью. Таймаут между запуском каждого нового скрипта составлял от 20 секунд до 10 минут. Это было сделано для имитации максимально реалистичного поведения сотрудников компании, зашедших на интранет-портал и работающих внутри него в течение дня.
Результаты испытаний
Внутрисетевой тестовый портал Битрикс24 (редакция Enterprise) на 111 000 пользователей, установленный на кластере из 5 физических серверов, смог обеспечить бесперебойную работу 30 000 сотрудников одновременно. Максимальное время ответа не превышало 0,9 секунды в 95% запросов.
В течение 1 часа вышеуказанное количество пользователей сгенерировало:
- 39 новостей
- 4614 сообщений в ленте
- 4 685 комментариев
- 440 чатов
- 3 386 мгновенных сообщений
- 2 297 бизнес-процессов
- 912 задач
- 367 документов
- 92 рабочие группы и проекты
- 291 событие в календаре
- 2 385 уведомлений
В течение 24 часов будет сгенерировано:
- 110 736 новых записей в Ленте
- 10 560 индивидуальных и групповых чатов
- 2 208 рабочих групп и проектов
- 112 440 комментариев
- 936 сообщений новостей
- 6 984 события в календаре
- 21 888 задач и поручений
- 8 808 документов
- 81 264 мгновенных сообщения
- 57 240 уведомлений
- 55 128 бизнес-процессов
Вывод
Результаты нагрузочного теста собственной версии Битрикс24 (Enterprise edition) подтвердили высокую производительность платформы и устойчивость в условиях высокой нагрузки.
Демонстрационный портал, развернутый в кластерном решении из 5 серверов, обеспечивал одновременную работу 30 тысяч пользователей, что соответствует примерному профилю нагрузки для крупной корпорации, в которой работает 100-200 тысяч сотрудников.
При этом система обеспечивала быстрый (даже по меркам интернет-проектов) отклик, не превышающий 1 секунды на большинство запросов, что обеспечивает плавность работы пользователей. Технология веб-кластеров в очередной раз доказала свою производительность и надежность.
Методика тестирования, сценарии и профили нагрузки, а также использование физических профилей пользователей позволили получить условия тестирования, максимально приближенные к реальным. Это означает, что результаты этого теста можно использовать в качестве эталона для разработки новых проектов.
Также стоит отметить, что нашей целью не было максимизировать количество генерируемого контента на портале во время тестирования (новости, задачи, документы, сообщения и прочее).
Цель состояла в том, чтобы создать точную симуляцию реального поведения пользователя. Тем не менее, скорость добавления информации на портал также была очень высокой, чего должно быть более чем достаточно для удовлетворения потребностей даже самых требовательных клиентов.
Мы готовы предоставить по запросу наших корпоративных заказчиков и интеграторов методологию тестирования, конфигурацию портала и тестовую среду для проведения полномасштабного тестирования порталов заказной разработки или их прототипов, проверки гипотез, расчета запаса прочности. нашего решения при пиковых нагрузках.
Среду тестирования можно дополнительно настроить, например, добавив интеграцию с корпоративными системами компании, чтобы обеспечить более точные результаты.
В декабре 2015 года Битрикс24 провел нагрузочное тестирование последней на тот момент версии Битрикс24 для оценки производительности системы в условиях крупного бизнеса с большим количеством сотрудников и высокой нагрузкой.
Общая информация
Нагрузочное тестирование проводилось в течение полных 24 часов на развернутом портале с большим объемом тестовых данных. В течение этого периода портал постоянно обрабатывался поступающими данными, имитирующими поведение реальных посетителей-людей.
Виртуальным пользователям было поручено выполнить множество стандартных операций, в том числе:
- включение и выключение
- публикация и комментирование в ленте
- с помощью задач и документов
- добавление записей в CRM
- отправка мгновенных сообщений и многое другое
Каждому из виртуальных пользователей была назначена заранее определенная роль, состоящая из множества операций, выполняемых в бесконечном цикле с небольшой задержкой между итерациями.
Тест был приспособлен для моделирования реального сценария, когда все сотрудники зарегистрированы в базе данных портала, и многие из них используют портал в течение дня, выполняя ряд типичных действий.
Условия испытаний
Программное обеспечение для тестирования:
- Версия Битрикс24: 15.0.4
- Оборудование: один сервер; кластер из 2-х и 3-х часто используемых серверов.
Параметры:
- Готовый шаблон Битрикс24 «из коробки»
Демонстрационные данные:
- 15 683 сотрудника
- 38 146 постов в ленте
- 10 460 задач
- 194 368 мгновенных сообщений
- 2 286 файлов на Битрикс24.Драйв
- 4 966 лидов и 697 компаний в CRM
Тестовая среда:
- Оборудование: Intel Xeon E3-1270v3 3,5 Гц, 32 ГБ RAM, 2 х 240 ГБ SSD.
- Серверная среда настроена с помощью Виртуальной Машины Битрикс. PHP обновлен до 5.6.9.
Результаты испытаний
Готовый портал Битрикс24 (редакция BizPace Enterprise), установленный на одном обычно используемом сервере с тестовыми данными, включающими 15 683 сотрудников, способен одновременно обслуживать 5 000 сотрудников.
Максимальное время отклика не превышало 1065 секунд.
В течение 24 часов данное количество сотрудников выполнило следующие действия:
- отправлено 19 887 мгновенных сообщений
- отправил 987 сообщений в ленту
- создано 1645 задач
- добавил 987 документов в Битрикс24.Драйв
- добавил 384 лида и 384 компании в CRM
Готовый портал Битрикс24 (редакция BizPace Enterprise), установленный на кластере из двух часто используемых серверов с тестовыми данными, включающими 15 683 сотрудников, был способен одновременно обслуживать 7 500 сотрудников (+50%). Максимальное время отклика не превышало 1,224 секунды.
В течение 24 часов данное количество сотрудников выполнило следующие действия:
- отправлено 28 836 мгновенных сообщений
- отправил 1473 сообщения в ленту
- создано 2455 задач
- добавил в Битрикс24.Драйв 1473 документа
- добавил 571 лид и 571 компанию в CRM
Готовый портал «Битрикс24», установленный на кластере из трех часто используемых серверов с тестовыми данными, включающими 15 683 сотрудника, был способен обслуживать 9500 сотрудников одновременно (+90%).
Максимальное время отклика не превышало 0,949 секунды.
В течение 24 часов данное количество сотрудников выполнило следующие действия:
- отправлено 36 702 мгновенных сообщения
- отправил 3124 сообщения в ленту
- создано 2455 задач
- добавил в Битрикс24.Драйв 3124 документа
- добавил 729 лидов и 729 компаний в CRM
Тест сервера Bitrix Site Manager
Тест сервера Bitrix Site Manager| Тестовый сервер Bitrix Site Manager |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Выберите: Требуемые настройки /
Рекомендуемые настройки
2.34
bitrix24.com по 80 порту
Желательно, чтобы памяти ускорителя было достаточно для часто используемых PHP-страниц. 
htaccess:
log