3

我开发了这个脚本来将 Sitecore 工作流程应用于整个项目，而无需手动单击 GUI。我对它的运行情况感到非常满意，但是它很慢。这是脚本：

Import-Module 'C:\Subversion\CMS Build\branches\1.2\sitecorepowershell\Sitecore.psd1'

# Hardcoded IDs of workflows and states
$ContentApprovalWfId = "{7005647C-2DAC-4C32-8A09-318000556325}";
$ContentNoApprovalWfId = "{BCBE4080-496F-4DCB-8A3F-6682F303F3B4}";
$SettingsWfId = "{7D2BA7BE-6A0A-445D-AED7-686385145340}";

#new-psdrive *REDACTED*

set-location m-rocks:

function ApplyWorkflows([string]$path, [string]$WfId) {
    Write-Host "ApplyWorkflows called: " $path " - " $wfId;
    $items = Get-ChildItem -Path $path;
    $items | foreach-object {
        if($_ -and $_.Name) {
            $newPath = $path + '\' + $_.Name;
            $newPath;
        } else {
            Write-host "Name is empty.";
            return;
        }

        if($_.TemplateName -eq "Folder" -or $_TemplateName -eq "Template Folder") {
            # don't apply workflows to pure folders, just recurse
            Write-Host $_.Name " is a folder, recursing.";
            ApplyWorkflows $newPath $wfId;
        }
        elseif($_.TemplateName -eq "Siteroot" -or $_.TemplateName -eq "InboundSiteroot") {
            # Apply content-approval workflow
            Set-ItemProperty $newPath -name "__Workflow" $ContentApprovalWfId;
            Set-ItemProperty $newPath -name "__Default workflow" $ContentApprovalWfId;

            # Apply content-no-approval workflow to children

            Write-Host $_.Name " is a siteroot, applying approval workflow and recursing.";
            ApplyWorkflows $newPath $ContentNoApprovalWfId;
        }
        elseif($_.TemplateName -eq "QuotesHomePage") {
            # Apply settings workflow to item and children

            Write-Host $_.Name " is a quotes item, applying settings worfklow recursing.";

            Set-ItemProperty $newPath -name "__Workflow" $SettingsWfId;
            Set-ItemProperty $newPath -name "__Default workflow" $SettingsWfId;

            ApplyWorkflows $newPath $SettingsWfId;
        }
        elseif($_.TemplateName -eq "Wildcard")
        {
            Write-Host $_.Name " is a wildcard, applying workflow (and halting).";
            Set-ItemProperty $newPath -name "__Workflow" $ContentApprovalWfId;
            Set-ItemProperty $newPath -name "__Default workflow" $ContentApprovalWfId;
        }
        elseif($_ -and $_.Name) {
            # Apply passed in workflow and recurse with passed in workflow
            Write-Host $_.Name " is a something else, applying workflow and recursing.";
            Set-ItemProperty $newPath -name "__Workflow" $WfId;
            Set-ItemProperty $newPath -name "__Default workflow" $WfId;

            ApplyWorkflows $newPath $wfId;
        }
    }
}

ApplyWorkflows "sitecore\Content\" $ContentNoApprovalWfId;

它在不到一秒的时间内处理一个项目。它的进展有一些停顿 - 证据表明这是Get-ChildItem返回大量物品的时候。我想尝试很多事情，但它仍在针对我们的一个站点运行。大约 50 分钟，看起来可能完成了 50%，也许更少。看起来它的工作是广度优先，所以很难准确地掌握做了什么，什么没做。

那么是什么让我慢了下来？

是路径的构建和检索吗？我试图通过$_or获取当前项目的子项$_.Name，但它总是在当前工作目录（即根目录）中查找，并且找不到该项目。每次递归更改目录会更快吗？

是输出让它陷入困境吗？没有输出，我不知道它在哪里或它仍在工作。有没有其他方法可以让我知道它在哪里，做了多少，等等？

有没有更好的方法让我只使用Get-ChildItem -r过滤器集并循环遍历它们？如果是这样，将非常感谢第一次尝试将我在第一个脚本中的一些条件合并到过滤器集中。我是 PowerShell 的新手，所以我确信我的代码中需要进行的改进不止一两个。

即使没有孩子，我是否总是调用递归位？这里的内容树很宽，有很多没有子节点的叶子。什么是一个很好的检查是否存在子项目？

最后，我们拥有的 PowerShell 提供程序 (PSP) 并不完整。它似乎没有 Get-Item 的有效实现，这就是为什么几乎所有内容都几乎完全用 Get-ChildItem 编写。我们的 Sitecore.Powershell.dll 说它是 0.1.0.0 版本。升级会有帮助吗？有更新的吗？

编辑：终于完成了。我对输出进行了计数，得出了 1857 个项目，运行大约需要 85 分钟，平均每分钟 21 个项目。比我想象的要慢，甚至...

编辑：我的第一次运行是在 PowerShell 2.0 上，使用 Windows PowerShell ISE。我没有尝试过 Sitecore PowerShell 插件模块或社区。直到昨天我才知道它的存在:-)

升级到 PowerShell 3.0 后，我又尝试了一次运行。从本地开始 - 从我的笔记本电脑运行脚本，连接到远程服务器 - 没有明显的区别。我在主机箱上安装了 PowerShell 3.0 并从那里运行脚本，发现速度可能提高了 20-30%。所以这不是我所希望的灵丹妙药——我需要一两个数量级的改进才能使这成为我不必照看和分批运行的东西。我现在正在玩一些由下面的好答案建议的实际脚本改进。我会回复对我有用的东西。

4

3 回答 3

5

我个人认为，如果您开始使用社区 PowerShell 实施而不是 Rocks 实施，您将获得最大的提升。

让我解释一下为什么。

您正在遍历整个树，这意味着您必须访问分支中的每个节点，这意味着它必须被读取并至少在 Rocks Web 服务上传输一次。然后每个属性保存都是另一个 web 服务调用。

我已经在社区控制台中运行了你的脚本，我花了大约 25 秒来处理 3724 个项目。（我已删除修改，因为这些值与我的系统无关）。

一个简单的

Get-ChildItem -recurse

在我的 3724 项目树上，社区控制台用了 11 秒，而 Rocks 实现用了 48 秒。

您可以在社区实施中为您的脚本使用的其他调整将使用 Sitecore 查询，例如：

get-item . -Query '/sitecore/content/wireframe//*[@@TemplateName="Template Folder"]'

并且只将这些项目发送到您的函数中

这并不意味着 Rocks 控制台写得不正确，它只是意味着 Rocks 控制台中的设计选择和他们的目标不同。

您可以在此处找到社区控制台：http: //bit.ly/PsConScMplc

于 2013-08-02T09:19:14.827 回答
1

请参阅此博客文章，其中声明了 foreach-object cmdlet 和 foreach 语句之间的差异。

当您使用 foreach 对象管道 get-childitem 时，您可以加快速度：

get-childitem . | foreach-object { ApplyWorkflow($_) }

这将导致 get-childitem 返回的每个对象将立即传递到管道中的下一个步骤，因此您将只处理它们一次。此操作还应防止长时间暂停阅读所有子项。

此外，您可以递归获取所有项目并按模板过滤它们，然后应用适当的工作流程，例如：

get-childitem -recurse . | where-object { $_.TemplateName -eq "MyTemplate"} | foreach-object { ApplyWorkflowForMyTemplate($_) }
get-childitem -recurse . | where-object { $_.TemplateName -eq "MySecondTemplate"} | foreach-object { ApplyWorkflowForMySecondTemplate($_) }

尽管如此，我还是不希望这个脚本能在几秒钟内运行。最后，您将遍历整个内容树。

最后，您使用的是什么库？这是Sitecore Powershell 控制台（dll 的名称听起来很熟悉）吗？有更新的版本添加了许多新功能。

于 2013-08-02T08:06:25.560 回答
0

我看到的最明显的问题是，每次调用函数时，您要对文件进行两次迭代：

function ApplyWorkflows([string]$path, [string]$WfId) {
    Write-Host "ApplyWorkflows called: " $path " - " $wfId;


    # this iterates through all files and assigns to $items
    $items = Get-ChildItem -Path $path;

    # this iterates through $items for a second time
    $items | foreach-object {  # foreach-object is slower than for (...)

此外，管道到 foreach-object 比使用传统for关键字要慢。

于 2013-08-02T00:39:36.587 回答