Я пытаюсь понять, как работает Slick-Hikari, я прочитал много документации, но у меня есть вариант использования, поведение которого я не понимаю.
Я использую Slick 3 с Hikari с конфигурацией по умолчанию. У меня уже есть производственное приложение, к которому одновременно подключено ~ 1000 пользователей. Мое приложение работает с веб-сокетами, и когда я развертываю новую версию, все клиенты переподключаются. (Я знаю, что это не лучший способ справиться с развертыванием, но в данный момент у меня нет кластеризации.) Когда все эти пользователи повторно подключаются, все они начинают выполнять запросы, чтобы получить свое пользовательское состояние (эффект собачьей кучи). Когда это происходит, Slick начинает выдавать множество ошибок, например:
java.util.concurrent.RejectedExecutionException: Task slick.backend.DatabaseComponent$DatabaseDef$$anon$2@4dbbd9d1 rejected from java.util.concurrent.ThreadPoolExecutor@a3b8495[Running, pool size = 20, active threads = 20, queued tasks = 1000, completed tasks = 23740]
Я думаю, что это происходит из-за того, что гладкая очередь для ожидающих запросов заполнена, потому что она не может обработать всех клиентов, запрашивающих информацию из базы данных. Но если я увижу метрики, которые мне предоставляет Dropwizard, я увижу следующее:
Возле 16:45 видим деплой. Пока старый экземпляр не завершится, мы можем видеть, что количество подключений увеличилось с 20 до 40. Я думаю, что это нормально, учитывая то, как выполняется процесс развертывания.
Но если очередь запросов Slick становится полной из-за эффекта собачьей кучи, почему он не использует более 3-5 соединений, если у него есть 20 доступных соединений? База данных работает очень хорошо, поэтому я думаю, что узким местом является Slick.
Есть ли у вас какие-либо советы по улучшению этого процесса развертывания? Сейчас у меня всего 1000 пользователей, но через несколько недель их будет намного больше.
