v2.37 b309 наблюдение - да, при обновлении файлов на FTP загрузка ЦП может быть высокой...

[VictorVG]

В обсуждении плагина есть запись http://forum.farmanager.com/viewtopic.php?f=5&t=6317&start=1616#p119451 о том, что он сильно грузит ЦП при коннекте. Да, я только что видел этот факт у себя, только у меня ЦП помощнее этого (http://ark.intel.com/ru/products/29734/Intel-Celeron-Processor-420-512K-Cache-1_60-GHz-800-MHz-FSB) - Pentium DC E5800@3,2 GHz, а потому по данным Process Hacker загрузка ЦП была более чем вдвое ниже - 45,23%. Явление было вызвано вот этим фактом:

"EugeneRoshal 16:38 04-06-2014 Dook MoveFile либо ReadFile+WriteFile. Но логика для zip модуля используется частично унаследованная от инфозиповского кода, а частично уже rar'овская, и к некоторым местам есть вопросы. Я сейчас посмотрел на эту функцию повнимательнее, кое-что поменял и перевыложил английскую сборку beta 4. Если будет время - посмотрите, я тоже ее сейчас буду тестировать."

у парня обрезаются по размеру 4Гб -1 Zip архивы, и Женя перевыложил бету. Но поскольку обновление дерева длилось несколько минут, то я поймал момент обновления данных на сервере - штамп времени файлов 04.06.2014 17:47:00 мск, а потому смог подтвердить данное наблюдение.

Мне думается что можно снизить частоту опроса дерева каталогов удалённого сервера использовав механизм "Перерисуем по событию, а если нет то раз в секунду" Но это просто возможный вариант для обсуждения имеется ли смысл так делать или нет?

[VictorVG]

Судя по сообщению на форуме явление связано с баг-фиксом http://bugs.farmanager.com/view.php?id=2632 . Я с ходу проверить не могу, а тащить старые исходники нет времени....

[VictorVG]

v2.1..37.311 - на момент считывания листинга каталогов видим загрузку ЦП http://i049.radikal.ru/1406/2f/a0bd38398545.png, быстро считали - освободили. Я думаю что вопрос можем считать решённым. Временная сетка на диаграммах мониторинга в Process Hacker 2.34.5632 - 5 сек/деление.

[VictorVG]

С ру-борда: http://forum.ru-board.com/topic.cgi?forum=5&topic=31718&start=5180#9

Alexyz21 NetBox 2.1.37 при общении с сервером тратит 20 секунд просто на ожидание непонятно чего, видно в логах.

посему переоткрыл - может эти наблюдения принесут пользу....

[z0hm]

Лог из которого видно, что сабж теряет 20 секунд в трёх местах по 5, 5 и 10 секунд. http://forum.farmanager.com/viewtopic.php?f=5&t=6317&start=1616#p119516 http://forum.farmanager.com/viewtopic.php?f=5&t=6317&start=1632#p119681 Есть ещё момент - при загруженном канале FarFTP на низкой скорости, но заливает, NB2.1.37 пытается залить, но в процессе умирает - отдаст чуть-чуть и пауза секунд на 15, ядро при этом загружено на 100%.

[VictorVG]

И ещё одно наблюдение, так же с руборда:

skipik

Провёл у себя эксперимент по поводу нагрузки на ЦП. Far 3.0.3955 x64, NetBox 2.1.37.309, Core i5-2500K. Заходил на ftp://ftp.rarlabs.com/rar/ несколько раз, пиковая нагрузка всегда подпрыгивает до 25%.

и на основе имеющихся наблюдений гипотеза объясняющая эффект снижения нагрузки на многоядерные (SMP) систем:

при работе NetBox с FTP код не оптимизированный под параллельную обработку алгоритм реализованный в WinSCP полностью загружает один ЦП (или ядро в многоядерных ЦП) из доступных на данной ЭВМ ожиданием потерянных в нём ответов сервера.

[VictorVG]

в новом билде 313 с загрузкой ЦП нормально, большая загрузка совпала со временем скачивания в фоне дистрибутива Libre Office 4.2.5 Win (~256 Mb), заодно и убедимся что при фоновой передаче с FTP не падаем. (горизонтальня шкала время, 5 сек/деление, вертикальная загрузка ЦП, 33.33(3) %/деление).

Проверял на этих сборках:

FarNetBox-2.1.38_Far3_x64.7z https://yadi.sk/d/QNgp0-fMUNipQ FarNetBox-2.1.38_Far3_x86.7z https://yadi.sk/d/ieY1OR2YUNitv

7-Zip v9.33 Alpha, LZMA, SOLID, MAXIMUM

[z0hm]

WinXPSP2 x86, FAR3.0.3955, FarNetBox-2.1.38_Far3_x86 - всё по прежнему - загрузка ядра 100% никаких отличий не вижу. Обращаю внимание - нагрузки быть вообще не должно, в частности NB2.1.36 при скачивании с FTP создаёт нагрузку 0-1%.

[VictorVG]

z0hm

Есть у меня подозрение что тут часть вина на брандмауэрах лежит - они могут отсекать часть пакетов вызывая активность FTP движка. И могу точно сказать - код однопоточный, я при сборке не включал поддержку OpenMP.

[z0hm]

Зачем гадать? - не проще ли посмотреть на внесённые изменения между финальной 2.1.36 и первым билдом 2.1.37?

[VictorVG]

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

[michaellukashov]

Исправлено в текущей версии.