Комментарии 9
У вас что-то сломано. Почему такая медленная скорость загрузки в один поток, 13 мегабайт в секунду??? Вы там случайно gzip'ом не жмёте трафик и не упёрлись в проц? Если да, просто выкиньте gzip и используйте нормальные алгоритмы компрессии типа lz4/zstd. В один поток без всяких шаманств с чанками можно спокойно хоть гигабит в секунду отдавать.
Добрый день! Спасибо за комментарий.
Да, мы используем gzip, но это происходит до передачи архива, а не «на лету». Основная причина медленной монолитной загрузки — ограничения TCP: один поток упирается в размер TCP-окна.
5 потоков = 5 независимых TCP-окон, что дает рост с 13 до 65 МБ/с.
один поток упирается в размер TCP-окна
У вас отключен TCP window scaling и RTT > 50 ms?
В нашем решении существует два варианта использования платформы: self-hosted и SaaS. В обоих случаях Runner работает на мощностях пользователей, где мы не можем управлять сетевыми настройками TCP, а чанковая загрузка позволяет гарантировать высокую скорость передачи без необходимости для пользователей выполнять настройку сетевых параметров.
А почему передача одного и того же файла должна идти быстрее если его разбить на куски и создать много потоков? По моему уже на этом уровне что то не то, сетевая карта всё равно одна
Добрый день! Отличный вопрос!
Дело не в сетевой карте, а в TCP: один поток не может полностью использовать канал из-за ограничений окна. Параллельные потоки решают это, однако важно заметить, что больше потоков ≠ бесконечное ускорение.
Наши тесты показывают оптимальную зону в 4-6 потоков — дальше накладные расходы на управление потоками и конкуренция за ресурсы снижают эффективность.
Очень интересный кейс
Понравилось, что автор сумел разъяснить казалось бы сухую технику, простым и приятным к восприятию языком
А за сокращение времени передачи данных почти в 4 раза автору можно смело руку пожать. мОлодец!
отличная статья
Чанковая загрузка артефактов CI/CD: оптимизация передачи файлов