Блог

Сейчас я создаю веб-приложение с использованием MongoDB Spring Data Mongodb.

Это приложение имеет API, который представляет собой простой запрос MongoDB:

 db.myCollectionName.aggregate([{ "$sample" : { "size" : 100}}, { "$project" : { "myFieldName" : 1, "_id" : 0}}])
 

Мы случайным образом выбираем 100 документов из myCollectionName и проекта myFieldName . Это простой запрос на чтение.

Общая коллекция составляет около 100 миллионов записей, и я правильно использую $sample оператора:

• $sample является первой стадией трубопровода
• N составляет менее 5% от общего количества документов в коллекции
• Коллекция содержит более 100 документов

Наш кластер mongodb представляет собой набор реплик из 3 узлов, один узел обрабатывает запросы на запись, а два других обрабатывают запросы на чтение.

Я тестирую свое приложение с помощью JMeter, пытаясь выяснить, сколько TPS приложений может поддерживать максимум.

Отчет показывает, что, когда число параллелизмов равно 100, производительность приложения TPS является наилучшей, достигая 1000, со средней задержкой 95pct 180 мс. Рабочая нагрузка равномерно распределяется между двумя вторичными узлами. Количество операций составляет около 500, количество подключений-около 180 в каждом вторичном узле.

Между тем, на стороне приложения рабочая нагрузка довольно низкая, используется всего 30% процессора и памяти.

Затем я пытаюсь добавить еще один вторичный узел, чтобы посмотреть, будет ли TPS линейно увеличиваться, и теперь происходят странные вещи:

После того, как число параллелизмов превысит 100, TPS системы не увеличивается линейно. TPS остается на уровне 1000, при этом каждый вторичный узел обрабатывает только 400 операций (одинаковое количество операций). По мере увеличения числа параллелизмов средняя производительность приложения 95pct также начинает снижаться со 180 мс до ~450 мс.

В то же время я замечаю, что количество подключений неравномерно установлено в каждом вторичном узле. Один вторичный узел установил более 300 соединений, в то время как два других имеют только 180. Более того, по мере того, как число параллелизмов превышает 150, на узле с большим количеством подключений начинают появляться медленные запросы.

Я могу подтвердить, что рабочая нагрузка на стороне приложения довольно низкая, с 3 вторичными узлами приложение все еще не достигает своих ограничений по нагрузке. Максимальное количество подключений, настроенное на стороне клиента MongoDB, составляет 2000, насколько я знаю, этого должно быть достаточно.

Обзор https://github.com/mongodb/specifications/blob/master/source/server-selection/server-selection.rst в разделе «Алгоритм выбора сервера».

Во-первых, проверьте задержки, которые видит драйвер для каждого из серверов. При необходимости увеличьте окно, используя localThresholdMS параметр URI.

Затем вы либо неправильно собрали данные, либо у вас проблема с сервером, потому что

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

Если у вас есть узел, способный поддерживать 400 соединений, но с той же рабочей нагрузкой, он не может поддерживать >150 >

После того, как вы это сделаете, обратите внимание, что в алгоритме выбора сервера есть этот пункт:

Из двух случайно выбранных серверов выберите тот, у которого меньше количество операций. Если оба сервера имеют одинаковое количество операций, произвольно выберите один из них.

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