4

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

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

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

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

为什么B这么慢？是因为“输出被序列化为 XML，然后再次重组为对象”，如此处所述，使用 B 而不是 A？还是发生了其他事情？

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

我想知道如何更改现有脚本以使用 PSRemoting 在远程服务器上进行文件搜索。我认为在远程目标上运行 gci 可能会更快完成搜索。在少数测试中，使用 PSRemoting 的搜索实际上运行的时间要长得多。我询问环回方案只是因为它似乎是最简单的情况；我在远程服务器上看到了类似的结果。所以我会坚持使用这样的 UNC 路径搜索：

gci -recurse \\REMOTESERVER\C$\folder

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

4

3 回答 3

2

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

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

编辑：

转换为/从 csv 为您提供一个（浅）反序列化对象，并且实际运行速度似乎比输出字符串快：

ConvertFrom-csv (icm -comp server { gci -rec c:\ | convertto-csv})
于 2013-04-19T16:30:00.740 回答
2

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

Invoke-Command -comp LOCALSERVER { Measure-Command { gci -recurse "C:\" } }
于 2013-04-19T14:11:12.133 回答
1

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

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

至少应该快一个数量级。

于 2013-04-19T14:06:59.003 回答