Нагрузочное тестирование и статистика использования SugarCRM
В 2014 году у нас будет три проекта, в которых планируется 500+ пользователей SugarCRM. Сотни одновременно работающих пользователей – это не шукти, и один, даже мощный сервер, будет не в состоянии обеспечить комфортную работу в SugarCRM. После запуску проектов в работу мы обязательно напишем, как мы, в конце концов, организовали взаимодействия серверов, а пока хочу поделиться статистикой, которую мы собрали для оценок результатов нагрузочных тестов.
Нагрузочное тестирование для SugarCRM
RPS (requests per second или количество запросов в секунду) – основной показатель производительности сервера при нагрузочном тестировании. Все нагрузочные утилиты прежде всего меряют именно его. В мировой практике принято, что для определения максимального количества пользователей CRM-систем, которые могут комфортно работать, надо умножить RPS на 4 (для компаний, которые занимаются активными продажами коэффициент существенно ниже, т.к. они более активно работают с системой). Т.е. если сервер выдерживает нагрузку в 30 одновременных запросов, то с этим сервером может работать до 4*30=120 пользователей.
На реальных серверах наших клиентов коэффициент получается побольше.
В компании с 20 активно работающими CRM-пользователями максимальное количество запросов, которое приходило в течение одной секунды – четыре, но это единичный случай: как правило не более двух запросов в течение одной секунды. Т.е. если сервер выдерживает нагрузку 30 одновременных запросов, то в SugarCRM может работать и 150 пользователей.
Но это максимальные цифры. В среднем один пользователь SugarCRM в течение дня делает не более 400 запросов. В самый активный час – не более 100 запросов. Т.е. пользователь в пиковую свою активность инициирует менее двух запросов в минуту.
Технические итоги
- Тесты мы проводили на серверах Amazon, т.к. там достаточно просто можно запустить и остановить сервер, не оплачивая простой сервера, развернуть еще один такой же сервер, управлять конфигурацией сервера
- В качестве генератора запросов использовали Яндекс.Танк, которому подсовывали для тестов сценарии, собранные из работы реальных пользователей
- Правильная конфигурация инфраструктуры (веб-сервера, СУБД, кэша, PHP) может увеличить максимальный RPS в 3 раза
- Самой быстрой связкой для веб-сервера оказались: nginx+fpm+php (на 20% быстрее, чем apache+php+memcache+apc)
- Первым узким местом для сервера с 4 ядрами и 16 ГБ ОЗУ оказалось CPU - его не хватает веб-серверу
- Добавление еще одного веб-сервера на отдельной машине пропорционально увеличивает максимальное количество RPS
- Для 500 пользователей будет достаточно трех 8 ядерных веб-серверов, подключенных к одной такой же машине с СУБД, рекомендуемый объем ОЗУ - 32 Гб
Забавная статистика
Когда мы стали собирать данные по разным клиентам, меня поразила, насколько похожа статистика у разных компаний:
- в компании выделяется 20-25% сотрудников, у которых активность в CRM в 1,5-2 раза выше, чем средняя активность по компании
- соотношение активности пользователя к средней активности по всей компании прослеживается как на интервале в месяц, так и на интервале в день, так и на интервале в час. Т.е. если менеджер Василий в 2 раза больше делает запросов в месяц, то в любой из дней он будет делать где-то 2 раза больше запросов, и в любой из часов этого дня он будет делать в 2 раза больше запросов
- Максимальные пики нагрузок на CRM (т.е. по факту максимальная активность сотрудников) в компаниях, которые работают с 9 до 18 приходится на 11-12 утра (т.е. где-то за час до обеда) и на 14-15 дня (т.е. где-то через час после окончания обеда)
- первый и последний часы рабочего дня самое неактивное время (активность в это время ниже где-то в 4 раза по сравнению с пиковой активностью)