D
Так там внутри все равно же пул тредов?
ага, но в бенчмарке там пул из 1 треда)
Size: a a a
2020 December 04
D
чтоб ты понимал
PD
Ну, это без транзакций, это не интересно.
PD
(На одном треде не сделать много транзакций, если только у Pg не появилось совсем нового API под это)
D
я только видел чужие графики, автор говорил, мол для серверлесс или кубика вообще идеально
D
видимо придется самому протестировать
PD
Хм, а что, 10-20 тредов съедают настолько много ресурсов?
А больше для работы с БД не требуется, особенно для Pg
А больше для работы с БД не требуется, особенно для Pg
DP
вот да, интересный это вопрос.. Что из-за осутствия в PG нормального API для реактивного взаимодействия, не понятно, что даст реактивный драйвер, если в проекте есть транзакции..
D
поищу тесты
D
D
D
тут небольшая ошибка, quarkus тестировался с vertx reactive client
D
и в целом показал самый лучший результат
D
JDBC took a lot more memory and CPU than the reactive client. This difference became larger at high concurrency.
D
собственно вот
PD
Э, но почему и как? Бенчи - ок, но какие причины (если они не понятны, то смысла в бенчмарке нет).
Разница в отклике вообще самая странная, 20ms vs 40ms похоже на задержки на стороне PG, не клиента
Разница в отклике вообще самая странная, 20ms vs 40ms похоже на задержки на стороне PG, не клиента
D
Э, но почему и как? Бенчи - ок, но какие причины (если они не понятны, то смысла в бенчмарке нет).
Разница в отклике вообще самая странная, 20ms vs 40ms похоже на задержки на стороне PG, не клиента
Разница в отклике вообще самая странная, 20ms vs 40ms похоже на задержки на стороне PG, не клиента
по задержке кстати там можно сделать вывод, что jdbc не хуже
D
а может даже и лучше
D
но мой посыл выше был про ресурсы
D
цпу и памяти jdbc есть при высоком параллелизме больше