Я пытаюсь выполнить нагрузочное тестирование простого приложения Spring webflux с помощью инструмента gatling. Приложение разработано с использованием проектов «spring-boot-starter-webflux» и «spring-boot-starter-data-mongodb-реактивный». Это просто чтение монго документа с определенным уникальным столбцом. Я внедряю одновременных пользователей, используя gatling setUp (scn.inject (atOnceUsers (userCount)). Протоколы (httpConf))
Я запускаю экземпляр dong монго, как показано ниже
Replica
mongod --replSet rs0 --port 27020 --bind_ip localhost, somehostname, some_ip --dbpath C: \ mongo \ data \ db0 --smallfiles --oplogSize 128
mongod --replSet rs0 --port 27021 --bind_ip localhost, somehostname, some_ip --dbpath C: \ mongo \ data \ db1 --smallfiles --oplogSize 128
mongod --replSet rs0 --port 27022 --bind_ip localhost, somehostname, some_ip --dbpath C: \ mongo \ data \ db2 --smallfiles --oplogSize 128
автономный
mongod --port 27018 --bind_ip localhost, somehostname, some_ip --dbpath C: \ mongo \ data \ db9 --smallfiles --oplogSize 128
Настройка 1:
приложение, работающее в Windows Desktop (Intel i5 и 16 ГБ ОЗУ), режим реплики Mongo DB (3 узла), работающий на ноутбуке с Windows (процессор Intel i7 и 16 ГБ ОЗУ) и сценарии тестирования загрузки Gatling также на рабочем столе. Сценарии приложений и Gatling на рабочем столе находятся в контейнерах.
Размер очереди по умолчанию равен 500, я переопределил размер очереди 1000, используя waitQueueMultiple
Я получаю это исключение com.mongodb.MongoWaitQueueFullException: даже с 3000 параллелизмом.
Настройка 2:
У меня те же настройки, что и выше, но БД Mongo работает в автономном режиме
Я получаю это исключение com.mongodb.MongoWaitQueueFullException: даже с 3000 параллелизмом.
Настройка 3:
приложение, автономный режим Mongo DB и сценарии нагрузочного тестирования Gatling, все запущенные на рабочем столе. И все они в контейнерах и связаны с сетью моста
Размер очереди по умолчанию равен 500, переопределяется размером очереди 1000
эта настройка работает нормально до 10000 параллелизма. Я понимаю, что здесь нет роли задержки в сети, поэтому лучшая производительность
У меня есть вопрос ниже
1. Как устранить это исключение, кроме увеличения размера очереди.
- Почему mongodb в режиме реплики не работает так же, как в автономном режиме.
Как упомянуто выше, настройки 1 и 2 вызывают исключение при параллельности ~ 3000 пользователей. Я повторяю эти тесты в случайное время суток. Но в какой-то момент автономная настройка производительности базы данных mongo чрезвычайно удалась, и до 48000 одновременно работающих пользователей приложение хорошо масштабировалось (без исключений). Я проверил, что Mongo получает запросы, просматривая mongostat / mongotop, а также подтвердил, запустив db.adminCommand ("top") до и после каждого теста. Я могу подтвердить, что число считываний увеличивается по числу одновременных пользователей, которых я использовал для теста. Мое единственное беспокойство в то же время, если я использую mongo DB в режиме реплики (установка 1), она не показывает лучшую производительность, она продолжает выдавать исключение при самом параллелизме 3000. Почему режим реплики не работает аналогично автономному режиму) Код приложения такой же, скрипт gatling такой же.
mongodb-драйвер-реактивные потоки 1.9.2
Mondo DB 4.0.8