Батчинг (пакетная обработка). Часть 2. 🌐 Аналогично батчинг применяют для уменьшения сетевых расходов при HTTP взаимодействии (aka REST API). Проектируя свои сервисы и имея высокие требования по пропускной способности/времени отклика, вы можете предусмотреть использование батчинга. Скажем, у вас есть API для обновления статуса заказа по его id: POST /orders/{orderId}/status Content-Type: application/json { "status": "delivered", "timestamp": "2021-08-01T00:00:00Z" } 🌪 Давайте изменим API таким образом, чтобы можно было обновить статусы сразу для нескольких заказов в рамках одного запроса. POST /orders/status Content-Type: application/json { "statuses": [ { "orderId": "1", "status": "delivered", "timestamp": "2021-08-01T00:00:00Z" }, …. ] } 🍴 Это изменение позволяет не только сократить расходы на сетевое взаимодействие, но и использовать возможности параллелизма на стороне сервера. Например, если в предыдущем примере на сетевой обмен мы тратили 80 ms, а на выполнение 20 ms, то для десяти отдельных запросов время выполнения составит (80 ms + 20 ms) * 10 = 1000 ms. А если объединим в батч размером 10 и выполним параллельно на стороне сервера, то время составит (80 ms + 20 ms) = 100 ms, что в 10!!! раз меньше, чем без батчинга. ❗️Здесь стоит упомянуть, что, существует предел прироста производительности при параллелизации кода. Но в посте мы рассматриваем идеальную ситуацию. Если вам интересна эта тема, то можете прочитать пост про закон Амдала. ✍️ Важно отметить, что, поскольку батчинг является способом экономить именно на сетевых задержках, то его использование не даст сколько-нибудь значительный прирост при использовании HTTP2 и других протоколов, умеющих в мультиплексирование. Хотя и здесь нельзя совсем отметать экономию, например, на объеме метаданных. 🚨 При самостоятельной реализации батчинга, я бы советовал опираться на два параметра: 1. Максимальный размер батча, который должен быть отправлен. Пример: скопилось 50 команд - отправляем. 2. Максимальное время накопления батча. Например: прошло 30ms, за это время скопилось только 20 запросов - все равно отправляем. ⚖️ Нужно найти баланс между этими двумя параметрами. Чем больше батч, тем больше экономия на сети. Однако у слишком большого сетевого запроса тоже может возрастать время передачи в том числе из-за большей вероятности повторной пересылки пакетов. Второй параметр абсолютно необходим, чтобы не случалось ситуаций вечного накопления батча. Кроме того, он устанавливает максимальный оверхед для каждой отдельной операции при использовании батчинга. ☀️ Тема батчинга кажется мне настолько важной и базовой, что в одном из заданий моего курса по устойчивым системам студенты-выпускники ИТМО должны обнаружить потенциальное узкое место для его применения, и реализовать собственный батчер. Работаем над тем, чтобы запустить курс на широкую аудиторию💪 #highload #architecture