Батчинг (пакетная обработка). Часть 1. 🏛 Ситуация: в моменты повышенной нагрузки время выполнения запросов к БД начинает расти и сказываться на производительности. Профайлер показывает вам, что значительную часть длительности операции занимает ожидание получения JDBC соединения. У вашего приложения уже 20 подключений к базе и больше подключений вам выделять не хотят. Что делать? 🏕 Осознаем природу проблемы: 🎼 Паттерн работы с JDBC подключением следующий 1. Запрашиваем свободное подключение из пула 2. Посылаем в него команду 3. Ожидаем, когда придет ответ из этого же подключения 4. Возвращаем его в пул 🛑 То есть коннекция блокируется на все время выполнения одного конкретного запроса. Давайте представим, что время на доставку запроса до базы по сети составляет 40 ms, еще 40 ms занимает доставка ответа от базы. И только 20 ms занимает сам запрос. Получается из 100 ms мы тратим 80% на сетевое взаимодействие. Именно эти расходы мы и будем оптимизировать. 📦 Батчинг (пакетная обработка) - процесс выполнения нескольких запросов/команд в рамках одного сетевого запроса. ✅ Давайте отправлять в коннекцию не один запрос, а объединять запросы на вставку/обновление данных в “пачки” или “батчи” по 10 и отправлять вместе. Сетевые расходы на один “пакет” остаются более-менее неизменными, зато теперь вместо 10 сетевых обменов мы будем иметь всего один. Считаем: без батчинга 100 ms 10 = 1000 ms, с батчингом 40 ms + 20 ms 10 + 40 ms = 280 ms. То есть вы сэкономили уже 72%! ✅ Батчинг позволяет вам увеличить пропускную способность приложения. Однако, не стоит забывать и о том, что он может в худшую сторону повлиять на время выполнения отдельно взятой операции, ведь в нее будет входить время, затраченное на формирование пакета. Время формирование батча - один из важнейших параметров при реализации подхода наряду с размерами формируемых пакетов. 🚩 Пример выше не является чем-то каноническим. Применимость батчинга довольно ограничена, не для всех типов операций его легко реализовать. Но для insert/update операций он реализуется достаточно просто. 🧠 Буду переодически в постах рассматривать детали этого подхода, границы его применимости, связанные метрики и нюансы реализации. #highload #architecture