В нашем решении существует два варианта использования платформы: self-hosted и SaaS. В обоих случаях Runner работает на мощностях пользователей, где мы не можем управлять сетевыми настройками TCP, а чанковая загрузка позволяет гарантировать высокую скорость передачи без необходимости для пользователей выполнять настройку сетевых параметров.
Дело не в сетевой карте, а в TCP: один поток не может полностью использовать канал из-за ограничений окна. Параллельные потоки решают это, однако важно заметить, что больше потоков ≠ бесконечное ускорение.
Наши тесты показывают оптимальную зону в 4-6 потоков — дальше накладные расходы на управление потоками и конкуренция за ресурсы снижают эффективность.
Да, мы используем gzip, но это происходит до передачи архива, а не «на лету». Основная причина медленной монолитной загрузки — ограничения TCP: один поток упирается в размер TCP-окна.
5 потоков = 5 независимых TCP-окон, что дает рост с 13 до 65 МБ/с.
Владислав, добрый день! На связи команда платформы GitFlic
Пока подготавливал статью возникла проблема с ключевым словом include и одновременно условием по наличию тега (версия сервиса 3.5.2). После фиксации бага - укажу апдейт в этом блоке.
Взяли задачу на исправление проблемы, благодарим вас, будем держать в курсе изменений) Так же в случае возникновения вопросов или обнаружения ошибок вы можете написать в чат сообщества плафтормы в телеграм(ссылка указана в профиле), отвечаем оперативно
В нашем решении существует два варианта использования платформы: self-hosted и SaaS. В обоих случаях Runner работает на мощностях пользователей, где мы не можем управлять сетевыми настройками TCP, а чанковая загрузка позволяет гарантировать высокую скорость передачи без необходимости для пользователей выполнять настройку сетевых параметров.
Добрый день! Отличный вопрос!
Дело не в сетевой карте, а в TCP: один поток не может полностью использовать канал из-за ограничений окна. Параллельные потоки решают это, однако важно заметить, что больше потоков ≠ бесконечное ускорение.
Наши тесты показывают оптимальную зону в 4-6 потоков — дальше накладные расходы на управление потоками и конкуренция за ресурсы снижают эффективность.
Добрый день! Спасибо за комментарий.
Да, мы используем gzip, но это происходит до передачи архива, а не «на лету». Основная причина медленной монолитной загрузки — ограничения TCP: один поток упирается в размер TCP-окна.
5 потоков = 5 независимых TCP-окон, что дает рост с 13 до 65 МБ/с.
Владислав, добрый день!
На связи команда платформы GitFlic
Взяли задачу на исправление проблемы, благодарим вас, будем держать в курсе изменений)
Так же в случае возникновения вопросов или обнаружения ошибок вы можете написать в чат сообщества плафтормы в телеграм(ссылка указана в профиле), отвечаем оперативно