为什么这个PowerShell脚本这么慢?我怎样才能加快速度?

时间:2013-08-01 22:58:23

标签: powershell sitecore

我开发了这个脚本,将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%,也许更少。看起来它的工作范围很广,所以很难掌握所做的和不做的事情。

那是什么让我失望?

是路径构建和检索吗?我试图通过$_$_.Name让当前项目中的孩子,但它总是在当前工作目录中查找,这是根,并且找不到该项目。在每次递归时更改目录会更快吗?

输出是否会让它陷入困境?没有输出,我不知道它在哪里或它仍在工作。还有其他一些方法可以说明它的位置,完成了多少等等吗?

有没有更好的方法,我只使用Get-ChildItem -r过滤器集并循环使用?如果是这样的话,第一次尝试将我的第一个脚本中的一些条件合并到一个过滤器集中将非常感激。我是PowerShell的新手,所以我确信我的代码中有一两个以上的改进。

即使没有孩子,我总是称之为递归位吗?这里的内容树非常广泛,有很多没有孩子的叶子。什么是好的检查子项是否存在?

最后,我们拥有的PowerShell提供程序(PSP)并不完整。它似乎没有Get-Item的工作实现,这就是为什么一切几乎完全用Get-ChildItem编写的原因。我们的Sitecore.Powershell.dll说版本是0.1.0.0。升级有帮助吗?有更新的吗?

编辑它终于完成了。我对输出进行了计算,得出了1857项,运行时间约为85分钟,平均每分钟21项。比我想象的要慢,甚至......

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

升级到PowerShell 3.0后我尝试了另一次运行。从本地启动 - 从我的笔记本电脑运行脚本,连接到远程服务器 - 没有明显的区别。我在主机盒上安装了PowerShell 3.0并从那里运行脚本,看到速度提高了20-30%。所以这不是我希望它的银弹 - 我需要一个数量级或两个值的改进才能做出这样的事情,我不需要小心翼翼地分批运行。我现在正在玩下面的精确答案建议的一些实际脚本改进。我会回复一些对我有用的内容。

3 个答案:

答案 0 :(得分:5)

我个人认为,如果你开始使用社区PowerShell实现而不是Rocks one,那么你将获得最大的推动。

让我解释原因。

您正在遍历整个树,这意味着您必须访问分支中的每个节点,这意味着必须至少读取一次并通过Rocks网络服务。 然后每个属性保存都是另一个Web服务调用。

我在社区控制台中运行了你的脚本,3724件物品花了我大约25秒。 (我删除了修改,因为这些值与我的系统无关)。

简单

Get-ChildItem -recurse

在我的3724项目树上,社区控制台需要11秒,而在Rocks实施中需要48秒。

您可以在脚本的社区实施中使用的其他调整将使用Sitecore查询,如:

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

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

这些都不意味着Rocks控制台没有正确编写,它只是意味着Rocks控制台中的设计选择和目标不同。

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

答案 1 :(得分:1)

请参阅this blog post,其中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 Console(dll的名字听起来很熟悉)吗?有更新的版本,添加了许多新功能。

答案 2 :(得分: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关键字要慢。