Ускоренная загрузка с заголовками диапазона HTTP-байтов

Question

Кто-нибудь имел опыт использования байтовых диапазонов HTTP в нескольких параллельных запросах для ускорения загрузки?

У меня есть приложение, которое должно загружать довольно большие изображения из веб-службы (1 МБ +), а затем отправлять измененные файлы (с измененным размером и обрезкой) в браузер. Существует много таких изображений, поэтому вполне вероятно, что кеширование будет неэффективным, т. Е. Кеш может быть пустым. В этом случае мы сталкиваемся с довольно большим временем ожидания, пока изображение загружается, 500 м / с +, что превышает 60% общего времени отклика нашего приложения.

Мне интересно, смогу ли я ускорить загрузку этих изображений, используя группу параллельных запросов диапазона HTTP, например, каждый поток загружает 100 КБ данных, и ответы объединяются обратно в полный файл.

Есть ли у кого-нибудь подобный опыт? Снижают ли накладные расходы дополнительных загрузок увеличение скорости или эта методика действительно работает? Приложение написано на ruby, но опыт / примеры на любом языке могут помочь.

Несколько подробностей о настройке:

• Нет никаких ограничений пропускной способности или подключения к услуге (она принадлежит моей компании)
• Трудно предварительно сгенерировать все обрезанные и измененные размеры изображений, существуют миллионы с большим количеством возможных перестановок
• Сложно разместить приложение на том же оборудовании, что и коробки с образами дисков (политическое!)

Спасибо

Answer 1

Я нашел ваш пост от Google, чтобы посмотреть, написал ли кто-нибудь параллельный аналог wget, который делает это. Это определенно возможно и будет полезно для очень больших файлов по каналу с относительно высокой задержкой: я получил более чем 10-кратное улучшение в скорости благодаря нескольким параллельным соединениям TCP.

Тем не менее, поскольку ваша организация запускает как приложение, так и веб-службу, я предполагаю, что ваша ссылка имеет высокую пропускную способность и низкую задержку, поэтому я подозреваю, что этот подход вам не поможет.

Поскольку вы передаете большое количество небольших файлов (по современным стандартам), я подозреваю, что на самом деле вы перегорели из-за настройки соединения больше, чем из-за скорости передачи. Вы можете проверить это, загрузив похожую страницу, полную крошечных изображений. В вашей ситуации вам может потребоваться идти по порядку, а не параллельно: посмотрите, есть ли в вашей клиентской библиотеке HTTP возможность использовать постоянные соединения HTTP, так что трехстороннее рукопожатие выполняется только один раз на страницу или меньше один раз за изображение.

Если в конечном итоге вы по-настоящему фанатичны в отношении задержки TCP, вы также можете обмануть , как это делают некоторые основные веб-службы.

(Моя собственная проблема связана с другим концом спектра производительности TCP, когда длительное время приема-передачи действительно начинает затягивать мою пропускную способность для передачи файлов с несколькими ТБ, так что если вы включите параллельную библиотеку HTTP, Я хотел бы услышать об этом. Единственный инструмент, который я нашел, под названием «puf», распараллеливает файлы, а не байты. Если вышеупомянутое не помогает вам, и вам действительно нужен инструмент параллельной передачи, аналогичным образом свяжитесь: I возможно, сдался и написал это к тому времени.)

Answer 2

Я написал бэкэнд и сервисы для того места, откуда вы тянете изображения. Каждый сайт отличается, поэтому детали, основанные на том, что я сделал, могут не относиться к тому, что вы пытаетесь сделать.

Вот мои мысли:

• Если у вас есть сервисное соглашение с компанией, из которой вы извлекаете изображения (что необходимо, поскольку у вас достаточно высокая пропускная способность), то предварительно обработайте их каталог изображений и сохраните эскизы локально, либо в виде двоичных объектов базы данных, либо в виде файлов. на диске с базой данных, содержащей пути к файлам.
• Разве у этой службы нет изображений, доступных в виде миниатюр? Они не собираются отправлять полноразмерное изображение в чей-либо браузер ... если только они не сумасшедшие или садистские, а их пользователи сумасшедшие и мазохистские. Мы предварительно обработали наши изображения тремя или четырьмя различными размерами миниатюр, поэтому было бы просто представить, что вы пытаетесь сделать.
• Если ваш запрос - это то, чего они ожидают, то у них должен быть API или хотя бы некоторые ресурсы (программисты), которые могут помочь вам получить доступ к изображениям максимально быстрым способом. Для этого у них должен быть выделенный хост.

Как фотограф, я также должен упомянуть, что с тем, что вы делаете, могут быть проблемы с авторским правом и / или условиями предоставления услуг, поэтому убедитесь, что вы выше совета, проконсультировавшись с юристом И сайтом, на котором вы работаете. получающий доступ. Не думайте, что все в порядке, ЗНАЙ, что это так. Законы об авторском праве не соответствуют представлениям широкой общественности о том, что такое авторские права, поэтому привлечение адвоката может быть по-настоящему познавательным, а также дать вам хорошее ощущение, что вы находитесь на прочном основании. Если вы уже разговаривали с кем-то, вы знаете, о чем я говорю.

Answer 3

Я бы предположил, что использование любой p2p-сети было бы бесполезным, поскольку существует больше перестановок, чем часто используемых файлов.

Загрузка нескольких параллельных частей файла может дать улучшение только в медленных сетях (медленнее, чем 4-10 Мбит / с).

Чтобы улучшить использование параллельной загрузки, вам необходимо убедиться, что на сервере будет достаточно мощности.От вас текущая проблема (ожидание более 500 мсек для подключения) Я предполагаю, что у вас уже есть проблема с серверами:

• вы должны добавить / улучшить балансировку нагрузки,
• вы должны подумать о смене серверапрограммное обеспечение для чего-то с большей производительностью

И снова, если 500 мс - это 60% общего времени отклика, то ваши серверы перегружены, если вы думаете, что это не так, вам следует искать узкое место в соединениях / производительности сервера.