SharePoint ワークフローのチューニング

こんにちは SharePoint サポートの森 (kenmori) です。

SharePoint ワークフローのパフォーマンス チューニングについて記載させていただきます。ワークフローのパフォーマンス チューニングについては、以下のページに記載された内容が非常に詳しいため目新しいことを記載できませんが、本ブログでは少しでもわかりやすく記載できるように努力させていただきます。

タイトル : Workflow Scalability and Performance in Windows SharePoint Services 3.0

アドレス : https://msdn.microsoft.com/en-us/library/dd441390.aspx

なお、本投稿では WSS3.0 ベースの情報を記載しています。SharePoint Foundation 2010 以降につきましては、下記のブログ記事をご参考にしてください。

タイトル : SharePoint 2010 形式ワークフローの動作制御について (チューニング)

アドレス : https://blogs.technet.com/b/sharepoint_support/archive/2015/05/21/sharepoint-2010-mode-workflow-behavior.aspx

最初にワークフローにおいて設定可能な値をご紹介するにあたって前提情報を以下に記載いたします。

前提情報

ワークフローは、即座に実行、終了するイベントレシーバーなどとは異なり、長期に渡り大量の同時進行プロセスが起動するようなプログラムとなります。そのため、以下のような永続性サービスの実装は欠かせません。

多くのビジネス プロセスは、完了までに長い時間 (数か月、ときには数年) がかかります。ワークフローをメモリ内に保持することは、メモリ容量には限りがあるため現実的ではなく、また、1 つのインスタンスは 1 つのサーバー上で処理する必要があるため、拡張性もなくなります。長時間にわたって実行されるワークフローの多くは、フローや処理ロジックを活発に実行しているわけではなく、ユーザーや他のシステムからの入力待ちで事実上アイドル状態になっています。アイドル状態のインスタンスをアンロードすると、メモリを節約できるだけでなく、処理サーバー全体の高いスケーラビリティを実現できます。

(抜粋元 : https://msdn.microsoft.com/ja-jp/library/ms734764(VS.80).aspx )

SharePoint は、独自の永続性サービスを実装しています。特に長期に渡って実行されるワークフローについては、処理を必要に応じてバッチという単位に分割して実行します。適切なタイミングで適切なプロセスが該当のバッチ処理をコンテンツ DB からロードして実行していきます。

ワークフローの処理を実行する主なホストプロセスは以下となります。

1) w3wp.exe (ワーカー プロセス)

特徴 : 即座に実行 (ユーザー操作が集中すると心配・・・)

既定では 15 個以上 <Throttle> のワークフローを同時に起動しようとした場合、ワークフロー インスタンスの状態を開始処理中とマークしてワークフローの起動を遅延させます。

主な条件 :

 ブラウザからワークフロー開始

 ブラウザからアイテム / タスク変更などの操作 (イベント発生) 時

2) OWSTIMER.EXE (Windows SharePoint Services Timer サービス  )

特徴 :   実行対象としてキューイングされているバッチを取り出し 1 つずつ実行  (完了が遅くなります。)

既定では、”ワークフロー” タイマー ジョブが 5 分に 1 回 <Workflow Timer Interval>、最大 100 個 <Batch Size> のワークフロージョブを読み込み実行します。

主な条件 :   ワークフローが永続化された後、後続の処理を実行する場合

そして、SharePoint ワークフローが永続化するタイミングが主に以下となります。細かな条件は他にもあるでしょう。

1.       DelayActivity アクティビティなどを使用し、ワークフローがアイドル状態になった場合

2.       SharePoint ワークフローのバッチ実行タイムアウト <Timeout> を迎えた場合

3.       PersistOnCloseAttribute 属性を使用するカスタム アクティビティが完了したとき。

まとめると、ワークフローをブラウザから起動した場合、最初は w3wp.exe で実行されますが、処理内容やサーバーの状況によっては後続の処理が owstimer.exe で実行されるよう切り替わります。

そして、ワークフローではこの各種実行処理の制限値を設けることができるようになっています。

設定方法

以下の設定値の設定方法と注意点を記載します。書いておいて申し訳ないのですが、パフォーマンスチューニングにあたっては、最初にこれらの値を変更することは影響が大きいためお勧めしません。

まずは、お客様が作成しているワークフローの設計を変更して調整することを最初にご検討ください。パフォーマンスを向上するためのワークフロー設計の推奨事項は後述します。

1.     Throttle

2.     Batch Size

3.     Timeout

4.     Workflow Timer Interval

タイトル : ワークフロー : Stsadm プロパティ (Windows SharePoint Services)
アドレス : https://technet.microsoft.com/ja-jp/library/cc288139.aspx

1. Throttle

この設定により、ワークフローの同時実行数が、既定では 15 として設定されております。これを超えてワークフローが同時実行される際は、ワークフローを再試行するまで待機する動作に移ります。

設定方法は以下のサイトをご確認ください。

タイトル : Workflow-eventdelivery-throttle : Stsadm プロパティ (Windows SharePoint Services)

アドレス : https://technet.microsoft.com/ja-jp/library/cc287939.aspx

上記制限値によって大量のワークフローが待機状態になると、それぞれのワークフローが自分の実行される順番を待機するため、ワークフローの起動が順次遅延していくことが考えられます。

パフォーマンスカウンタを使用して、開始中の状態にあるワークフローの数を "Workflow Pending" にて確認することができます。Throttle の値を大きくすると、この数が 15 を超えて推移していくことを確認できます。タイトル : ワークフロー パフォーマンス カウンタ
アドレス :https://msdn.microsoft.com/ja-jp/library/ms732345(VS.80).aspx

注意点

急激に大きな値を設定すると、特にワーカープロセス (w3wp.exe) に、ユーザー操作が同じ時間帯に集中すると、一度に大量のワークフローが起動できるようになるため、ページの表示速度の遅延など様々な影響を及ぼす可能性がございます。

この値を変更する場合は、運用を想定した十分なテストを実施する必要があります。

2. Batch Size

Windows SharePoint Services Timer (OWSTIMER.EXE) において、ワークフロー ジョブ (既定では 5 分に 1 回起動する) が、最大この制限値 (既定では 100) までのワークフローバッチをロードして実行します。

タイトル : Workitem-eventdelivery-batchsize : Stsadm プロパティ (Windows SharePoint Services)

アドレス : https://technet.microsoft.com/ja-jp/library/cc288293.aspx

3. Timeout

ワークフローのジョブ実行では、この Timeout 値 (既定では 5 分) を超えて継続して実行できません。実行中のワークフロージョブが Timeout を迎えた場合は、そこで処理を中断し、後続の処理は再度キューに戻され、ワークフロー タイマージョブがまた実行するサイクルとなります。

タイトル : Workflow-eventdelivery-timeout : Stsadm プロパティ (Windows SharePoint Services)

アドレス : https://technet.microsoft.com/ja-jp/library/cc288917.aspx

4. Workflow Timer Interval

ワークフロージョブの実行サイクル (既定では 5 分に 1 回) をこの設定によって変更できます。

既定だと DelayActivity などで 1 分待機する設定を実施したとしても、本タイマー ジョブの動作の関係上、最大 5 分待機せざるを得ません。本設定値を変更することで、この実行間隔を狭めることは可能です。

タイトル : Job-workflow : Stsadm プロパティ (Office SharePoint Server)

アドレス : https://technet.microsoft.com/ja-jp/library/cc424970(office.12).aspx

2015.05.19 追記
SharePoint Server 2010 以降では、Job-workflow プロパティ変更によるジョブの実行間隔の変更は実施できなくなりました。
SharePoint サーバーの全体管理画面で "ワークフロー" ジョブの実行間隔を変更するか、PowerShell を使用する必要があります。

こちら をご確認ください。

推奨事項

以下にワークフローのパフォーマンスを向上するにあたって推奨事項をご案内します。

1. 最初のワークフロー バッチ サイズを可能な限り小さくする

ワークフロー開始処理の負荷をワーカープロセスに集中させることを防ぐため、ワークフローの最初の方に DelayActivity などを入れて、早めに終わらせます。

ワーカープロセスで実行すると、ワークフロー開始に至ったユーザー操作とワークフロー開始処理が同時に動きます。このため、該当ユーザー操作とワークフローの処理が共通的に参照するリソースにおいて競合が発生する可能性が高まります。

開始時のエラーを避けるためにも、この対処策はベストプラクティスとなります。

2. 一度にたくさんのイベントを待たない

イベントなども w3wp.exe に処理が集中する可能性を高めます。ParallelActivity, ReplicatorActivity, ConditionedActivityGroup (CAG) Activity などによって、大量のイベントを同時に待つような実装は可能な限り避けてください。

このような実装をしている場合において、複数のイベントが同時に発生した場合に、ワークフローがハング (EventDeliveryFailedException) する現象も報告されております。本事象については、別途ブログでご紹介を予定しておりますが、この現象を避け、ワークフローを安定稼働させるためにも、この点についてはご注意ください。

3. 履歴リストにはあまり書き込まない

履歴リストも高機能を有する SharePoint のリスト アイテムである以上、あまり頻繁に履歴リストにログを記載すると、パフォーマンスに影響を及ぼします。特に、実運用に入り、ワークフローの起動数が増えていけばいくほど、深刻化する可能性があります。

イベントログ、診断ログ、独自のログ ファイルなどに書き込むようにしましょう。

4. SharePoint オブジェクトは確実に破棄しましょう。

これは、ワークフローに限った話ではないのですが、SharePoint オブジェクトモデルを使用した際には、オブジェクトを確実に破棄してください。

ホスト プロセスである w3wp.exe や OWSTIMER.EXE が再起動するまで、これらのメモリが蓄積されて保持されるため、パフォーマンスに影響が出る恐れがあります。

タイトル : ベスト プラクティス : Windows SharePoint Services の破棄可能なオブジェクトを使用する

アドレス : https://msdn.microsoft.com/ja-jp/library/aa973248(v=office.12).aspx