4

На этом завершается в 2,3 минут на LocalServer:PSRemoting накладных расходов производительность с Get-ChildItem

A: measure-command {$x = invoke-command {gci -recurse "C:\"}}

На этом завершается в 38,4 минут на LocalServer:

B: measure-command {$x = invoke-command -comp LOCALSERVER {gci -recurse "C:\"}}

Почему B так медленнее? Это потому, что «вывод сериализуется в XML, а затем снова воссоздается на объекты», как объясняется here, с B, но не с A? Или что-то еще происходит?

LOCALSERVER запускает Windows 2008R2 с PS v3. В обоих случаях $x.count - 98973.

Мне было интересно изменить существующий скрипт, чтобы использовать PSRemoting для поиска файлов на удаленных серверах. Я думал, что поиск может завершиться раньше, когда gci работает на удаленной цели. В нескольких тестах поиски на самом деле выполнялись намного дольше с PSRemoting. Я спрашиваю о шлейф-сценарии только потому, что это казалось простейшим случаем; Я видел аналогичные результаты с удаленными серверами. Так что я буду придерживаться UNC поисков пути, как это:

gci -recurse \\REMOTESERVER\C$\folder 

... если эти результаты не кажутся странными, а некоторые корректировки по моей конфигурации удаленного взаимодействия или синтаксис может предложить большой прирост производительности?

+0

Я видел сценарии удаленного пса принять навсегда в локальном IDE, но когда побежал через командную строку Powershell они завершают в доле времени ... связано с тем, как обрабатывается потоковая обработка (с учетом изменений поведения IDE x86 или x64, которые я считаю) –

+0

Нет IDE для этих тестов. Я просто набрал 'powershell' в подсказке vanil cmd. – noam

ответ

2

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

Invoke-Command -comp LOCALSERVER { Measure-Command { gci -recurse "C:\" } } 
+0

Спасибо, я буду экспериментировать с результатами фильтрации на удаленной стороне. – noam

+0

Ты отказался от ответа на этот вопрос? Я не уверен, как это поможет вам больше, чем моя. Без обид, Эфран. – x0n

+0

Я был разорван. Твой - самый ясный и самый прямой ответ, но Ефран заставил меня фильтровать результаты gci на удаленной стороне. Я поддержал ваш ответ и согласился с ним, если бы мог. – noam

1

Да, вы правы относительно накладных расходов на сериализацию/десериализацию объектов FileInfo и DirectoryInfo по проводам. Если вы не заботитесь о получении реальных объектов, сделать что-то вроде этого:

icm -comp server { gci -rec c:\ | out-string } 

Это должно быть на порядок быстрее, по крайней мере.

+0

Действительно, это заняло 3,3 минуты. Благодарю. – noam

+0

вы можете получить псевдо объекты обратно с помощью convertfrom-csv на стороне клиента и convertto-csv на сервере (вместо out-string) и по-прежнему значительно улучшить скорость. См. Ответ @ mjolinor ниже. – x0n

2

Где-то в между возвращением полных объектов и просто получить список строк, если удаленная система работает V3, вы можете получить неполные десериализации с помощью JSON:

ConvertFrom-Json (icm -comp server { gci -rec c:\ | convertto-json -Depth 1}) 

Edit:

Преобразования в/из CSV получает вас (мелководный) десериализованный объект, и actuall, кажется, работают быстрее, чем из-строка:

ConvertFrom-csv (icm -comp server { gci -rec c:\ | convertto-csv}) 
+0

Спасибо, это аккуратный трюк. 3,1 минуты с CSV. – noam

Смежные вопросы