Question

这在LOCALSERVER上完成了2.3分钟：

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

这在LOCALSERVER上完成了38.4分钟：

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

为什么B这么慢？是因为“输出被序列化为XML然后再重新构建为对象”，如here解释的那样，B而不是A？或者还有其他事情发生了吗？

LOCALSERVER使用PS v3运行Windows 2008R2。在这两种情况下$x.count都是98973。

我想知道如何更改现有脚本以使用PSRemoting在远程服务器上进行文件搜索。我认为搜索可能会在远程目标上运行gci后尽快完成。在一些测试中，PSRemoting实际上搜索的时间更长。我问的是环回场景只是因为它看起来像是最简单的情况;我看到远程服务器有类似的结果。所以我会坚持使用这样的UNC路径搜索：

gci -recurse \\REMOTESERVER\C$\folder

...除非这些结果看起来很奇怪，对我的远程配置或语法进行一些调整可能会带来很大的性能提升？

Answer 1

正如您所提到的，远程调用命令所需的时间还必须考虑反序列化从远程管道返回的任何给定对象所需的时间（在您的情况下是C驱动器的FileSystemInfo的整个树）。我建议限制你通过网络序列化和反序列化的对象数量，并且在比较服务器的性能时，可能会考虑从运行代码的机器中获取的时间：

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

Answer 2

在返回完整对象和获取字符串列表之间的某处，如果远程系统正在运行V3，则可以通过json进行浅反序列化：

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

编辑：

转换为/从csv转换为（浅）反序列化对象，并且实际上运行速度似乎比out-string更快：

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

Answer 3

是的，您对通过线路序列化/反序列化FileInfo和DirectoryInfo对象的开销是正确的。如果您不关心获取真实物体，请执行以下操作：

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

至少应该快一个数量级。

使用get-childItem PSRemoting性能开销

3 个答案: