PSRemoting 使用 get-childItem 处理性能开销答案

【问题标题】：PSRemoting performance overhead with get-childItemPSRemoting 使用 get-childItem 处理性能开销
【发布时间】：2013-04-18 20:47:53
【问题描述】：

这在 LOCALSERVER 上在 2.3 分钟内完成：

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

这在 LOCALSERVER 上在 38.4 分钟内完成：

乙：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

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

【问题讨论】：

我已经看到远程 ps 脚本在本地 IDE 中需要很长时间，但是当通过 powershell 命令行运行时，它们在很短的时间内完成......与线程的处理方式有关（使用 x86或 x64 IDE 改变我相信的行为）
没有用于这些测试的 IDE。我刚刚在原版 cmd 提示符下输入了 powershell。

标签： powershell powershell-3.0 powershell-remoting get-childitem

【解决方案1】：

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

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

【讨论】：

谢谢，我会在远端试验过滤结果。
你放弃了我的答案？我不确定这对你的帮助比我的更大。无意冒犯，埃弗兰。
我被撕裂了。你的答案是最清楚和最直接的，但 Efran 让我在远程过滤 gci 结果。我赞成你的回答，如果可以的话，我会同时接受。

【解决方案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})

【讨论】：

【解决方案3】：

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

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

至少应该快一个数量级。

【讨论】：

确实，这花了 3.3 分钟。谢谢。
您可以通过在客户端使用convertfrom-csv和在服务器端使用convertto-csv（而不是out-string）来获取伪对象，并且仍然大大提高了速度。请参阅下面@mjolinor 的答案。