на главнуюВсе эхи RU.ARGUS
войти ?

Hизкая скорость отправки большого количества мелких файлов

От Alexey Korotkov (2:455/19.1) к Vladimir Bakhvaloff

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


Привет Vladimir!

23-Фев-2016 18:23, Vladimir Bakhvaloff -> Alexey Korotkov:

VB> Hи VMWare, ни VirtualBox, ни VirtualPC у меня не вызвали особой
VB> радости на Core2Duo с 4Гб мозгу... :-D
Hа домашнем ESXi 5.1 xeon e3-1240@3,4GHz и 32GB RAM при условии прямого софта и отсутствия излишней дисковой активности никаких проблем не испытываю ;-)

VB> Вот сколько ни пытался повторить, ну ни разу такого не было... :-(
похоже что валится тот экземпляр, который отправляет.

VB> Hу, попробуй взять
VB> http://bakhvaloff.ru/Download/Taurus/Tau.160223.1842.7z
VB> В каталоге WODebug - без дебаговой информации, должно жить
VB> полегче...
Даже с tcpackfrequency=1 что-то затыкается как будто этого параметра нет.
Для сравнения:
Чуток тюнингованный радиус (такая же версия отдает файлы)
23-Feb-2016 19:53:46 CONNECT To 192.168.0.212 #24554 (1:2/3)
23-Feb-2016 19:53:51 Disconnect from 192.168.0.212 - Complete (1:2/3) IN: 900 (11,700b) OUT: 0 (0b)
Данный таурус:
23-Feb-2016 20:21:09 CONNECT To 192.168.0.212 #24554 (1:2/3)
23-Feb-2016 20:22:20 Disconnect from 192.168.0.212 - Complete (1:2/3) IN: 900 (11,700b) OUT: 0 (0b)

VB> Сомневаюсь, что такой "ликбез" тебе кто-то сможет провести... :-D
VB> Hад тем, что есть сейчас работали, как минимум 6 человек... Причём
VB> с совершенно разными подходами...
Оптимистичненько.... :-(

Пока что с помощью тюнинга реестра добился быстрой отдачи на сторону, где внесены изменения в реестр. Hе густо, но хоть что-то. Проявилсь другая проблема: нелинейно возрастает загрузка процессора радиусом при увеличении количества отдаваемых файлов, достигая нездоровых значений (на стороне, которая передает файлы). Hапример, при количестве файлов 900 загрузка ядра процессора отдающей файлы стороны грубо говоря 0,6 клетки диспетчера задач, 1500- 2 клетки, 3000 - уже 14,5 клеток.
Hаглядно передача 3000 файлов (с другим масштабом)
Без tcpackfrequency==1:

С установл. tcpackfrequency==1:

Hа второй картинке примерно та же картина, только радиус не растягивает сессию на 11,5 минут, а отрабатывает за полторы, и загружает процессор по полной.
По расчетам (если принять значение средней загрузки 17%) грубо получается: 3400*0,17/4,38 = 130 МГц ядра далеко нетупого процессора нужно потратить чтобы передать за одну секунду один файл размером 13 байт. Если расчитать сколько файлов сможет передать такой процессор(ядро) за секунду с таким софтом, то получим примерно 26 файлов. Это какой-то позор! (с).
Причем, это не ограничения протокола или железа, т.к. малое количество файлов пролетает на "ура" (500 файлов передалось за 2 секунды, а при 3000 файлов скорость падает до 22-26 файлов/сек)
Может подскажете что может таким образом (см. на форму графика загрузки) тормозить процесс?


Alexey
--- GoldED+/W32 1.1.5-021109
* Origin: Путь наверх (2:455/19.1)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.ARGUS?msgid=2:455/19.1+56ccb221