для этого драйвера?
сценарий теста
50 потоков, 10к пачка на поток, 300байт в строке данных.
api.replace(tuple) на пачку занимает 8 сек ~1.2ms на строку.
без разницы сначала future все получить или сразу по каждой ждать.
cpu на клиенте драйвер ненормально сильно уничтожает, а на сервере совсем пусто...
Может кто сталкивался, куда ковырять, профайлером еще не лазил? или это норм скорость для драйвера?
50 потоков ос? у вас там походу все сжирает переключение контекста на клиенте
Думаю в данном случае особо не сжирает - потоки формируют запрос, отправляют в клиент и паркуются для ожидания ответа - конец. Тут количество потов (на вскидку) не влияет на скорость, но эксперимент приветствуется.
да, 50 потоков на 16 ядер было. сейчас уменшил до 25 поток и 32 ядер. cpu стало в пределах 70%, поход у них на каждое соединение типи свой поток с epoll(0) который проц сжигает в пустую для высокой latencety
Мы используем пока другой драйвер - там не так... Если не сложно - запишите jfr теста в profile конфигурации - будет видно кто где кого ждет и блокирует (если блокирует).
Обсуждают сегодня