Я думаю, вы могли бы найти это, немного погуглив, - но я все равно отвечу здесь.
Преимущества дозирования обычно зависят от того, что вы с ним делаете.
Если у вас есть соединение keep-alive, у вас нет накладных расходов на рукопожатие, и тогда вы не тратите слишком много времени на обработку последующих пакетов по этому соединению. Затем вы можете направить запросы и уменьшить время ожидания. Тем не менее, в HTTP1.1 запросы по-прежнему FIFO - так что вы должны «рукопожатие» каждый из Здесь вы можете использовать мощь дозирования!
Поскольку в дальнейшем вы можете отправлять / извлекать все данные, необходимые для всех запросов, вы можете минимизировать накладные расходы, возникающие при настройке каждого отдельного HTTP-соединения. Это означает , что вам придется подождать немного дольше, чтобы обработать запрос, поскольку все упаковано в один запрос, но ваша пропускная способность улучшается. Причиной этого является то, что от первого запроса до получения окончательного ответа и обратно не умножается на количество запросов, которые вы должны сделать.
Однако следует иметь в виду TTFB - время до первого байта. Если вы загружаете данные постепенно, пользователь может воспринимать их быстрее. Представьте себе веб-сайт, который загружает один из каждых тысячи ресурсов одновременно, и вы, как пользователь, можете видеть их всплывающие окна по сравнению с веб-сайтом, который загружает все тысячи одновременно, и вы просто видите счетчик, пока все ресурсы не будут загружены ? Готов поспорить, вы найдете, что прогрессивная схема загрузки «выглядит» быстрее.
Естественно, пакетирование очень сильно зависит от того, что вы делаете с запросами, если оно того стоит.
Иногда вам нужно быть осторожным с пакетной обработкой, поскольку вы можете создать большую нагрузку на сервер, если несколько пользователей одновременно выполняют пакетные запросы, и это может быть лучшей схемой балансировки для последовательной обработки запросов. Конечно, вы сможете понять это с помощью небольшого количества мониторинга и аналитики.