SharePoint Server 2010 でのワークフローのパフォーマンスと容量の計画を見積もる

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

パフォーマンスおよび容量の計画に関するこの記事では、ワークフローの使用が Microsoft SharePoint Server 2010 が実行されているトポロジに対して与える影響についてガイダンスを示します。

SharePoint Server 2010 の容量計画の一般的な情報については、「パフォーマンスと容量の管理 (SharePoint Server 2010)」を参照してください。

内容

• テスト ファームの諸特性

• テスト結果

• 推奨事項

• トラブルシューティング

テスト ファームの諸特性

テスト ファームの特性として、次の項目について説明します。

• データセット

• 負荷

• ハードウェア、設定、およびトポロジ

データセット

ベンチマークを取得するために、大部分のテストは、ファーム内の単一サイト コレクションの既定のチーム サイトで実行しました。手動開始テストでは、8,000 個のアイテムを含むリストを使用してワークフローを開始しました。

負荷

このシナリオのテストは、次のように、さまざまなファーム構成と各種の変数がどのように関係するかを評価するのに役立ちます。

• 複数のコンピューターで宣言型ワークフローを手動で開始する場合のスループットに対する、フロントエンド サーバーの台数の影響

• 複数のコンピューターでアイテムの作成時に宣言型ワークフローを自動的に開始する場合のスループットに対する、フロントエンド サーバーの台数の影響

• 複数のコンピューターでタスクを完了する場合のスループットに対する、フロントエンド サーバーの台数の影響

この記事で示す特定の処理能力とパフォーマンスの数値は、現実の環境における数値とは異なります。ここで示す数値は、ある一定規模の環境を設計する際の出発点を提供することを目的としています。最初のシステム設計が終了したら、実際の環境におけるさまざまな要素にシステムが対応できるかどうかを判断するために構成をテストしてください。

ここではテスト シナリオを定義し、各シナリオで使用されたテスト プロセスについて説明します。テスト結果、特定のパラメーターなどの詳細情報については、後述のテスト結果に関する説明を参照してください。

ハードウェア、設定、およびトポロジ

これらのテストに使用されたトポロジでは、コンテンツ データベース用のコンピューターを 1 台、SharePoint Server 2010 を既定の設定でインストールしたフロントエンド コンピューターを 1 ～ 4 台使用します。これらのテストで使用されたワークフローは Microsoft SharePoint Foundation 2010 では利用できませんが、テスト結果は、このエディションの展開で同様のシナリオを評価する場合にも有効です。これらのテストに使用されたデータセットには、単一のコンテンツ データベース上のチーム サイト テンプレートに基づくサイトを 1 つ含む単一のサイト コレクションが含まれています。

テスト結果の詳細を高いレベルで提供できるように、テストでは複数のファーム構成を使用しました。具体的には、1 ～ 4 台の Web サーバー、および Microsoft SQL Server 2008 が実行されている 1 台のコンピューターでファームを構成しました。テストは 1 台のクライアント コンピューターを使用して実行しました。データベース サーバーおよびすべての Web サーバーは 64 ビットで、クライアント コンピューターは 32 ビットでした。

次の表は、テストで使用されたハードウェアを示しています。

ワークフロー容量計画トポロジ

テスト結果

以下の各表は、SharePoint Server 2010 のワークフローのテスト結果を示しています。テストのグループごとに、特定の変数だけを変えているので、ファームのパフォーマンスに対する漸進的な影響がわかります。

この記事で報告されているすべてのテストは、思考時間 (一連の操作間の自然遅延) なしで実行しました。現実の環境では、ユーザーがタスクの次のステップを実行するので、各操作の後に遅延が発生します。それに対して、このテストでは、各操作の後に次の操作を即座に実行して、ファームに負荷をかけ続けました。このような負荷により、データベース競合など、パフォーマンスに悪影響を及ぼす可能性がある要因が発生することもあります。

スループットに対する Web サーバーのスケーリングの影響

以下のスループット テストは、SharePoint Server 2010 に付属する承認ワークフローを使用して実行されました。ワークフローの関連付けによって 1 つのタスクが割り当てられ、すべてのインスタンスが 1 つのリストに対して実行されます。このワークフローの各インスタンスでは、次の要素がコンテンツ データベースに作成されます。

• ワークフローの状態を格納するワークフロー テーブルの 1 個のエントリ

• 5 個のセカンダリ リスト アイテム (1 個のタスクと 4 個の履歴アイテム)

• ワークフローの親アイテムとタスクのイベントを処理する 4 個のイベント レシーバー

ワークフロー操作がキューに入れられることのないように、ワークフローの延期のしきい値を非常に大きい値に設定しました。各テストを 5 回実行し、それぞれ 5 分間実行しました。

手動開始のスループット

次の表のテストは、フロントエンド サーバーを増やすと、Web サービスによってワークフローを同時に開始する場合のスループットにどのように影響するかを示しています。このテストは、Workflow.asmx の StartWorkflow メソッドを同時に 25 人のユーザーが呼び出し続けるユーザー負荷のみをファームにかけて実行されました。ドロップされる Web 要求が発生するまでは、ユーザー負荷は最適負荷でした。リストには最大 8,000 個のアイテムがあらかじめ入力されています。

次のグラフはスループットの変化を示しています。フロントエンド サーバーを増やしても、ファームのスループットに比例的に影響するわけではなく、3 台から 4 台のフロントエンド サーバーでほぼ頭打ちになります。つまり、ワークフローを手動で開始する場合の最大スループットは約 30 ワークフロー/秒であり、フロントエンド サーバーを 5 台以上に増やしても大きな効果はないと考えられます。

手動開始のスループット

アイテムの作成時にワークフローを自動的に開始する場合のスループット

次の表のテストは、フロントエンド サーバーを増やすと、アイテムの作成時にワークフローを自動的に開始する場合のスループットにどのように影響するかを示しています。このテストは、単一のリストに新しいリスト アイテムを作成するリスト Web サービスを同時に 150 人のユーザーが呼び出し続けるユーザー負荷のみをかけて実行されました。リストは空の状態から始めました。

次のグラフはスループットの変化を示しています。スループットは手動開始操作とよく似ています。手動開始テストと同様に、スループットは 3 台または 4 台のフロントエンド サーバーで最大 (約 32 ワークフロー/秒) になっています。フロントエンド サーバーを 4 台以上に増やしても大きな効果はありません。

自動開始ワークフローのスループット

タスク完了のスループット

次の表のテストは、フロントエンド サーバーを増やすと、ワークフロー タスクを完了する場合のスループットにどのように影響するかを示しています。タスクを完了するのに使ったリストは、前のテストの自動開始ワークフローで使用したタスク リストです。このテストは、Workflow.asmx の AlterToDo メソッドを同時に 25 人のユーザーが呼び出し続けるユーザー負荷のみをかけて実行されました。リストは空の状態から始めました。

次のグラフはスループットの変化を示しています。手動開始テストと同様に、スループットは 3 台または 4 台のフロントエンド サーバーで最大 (約 32 ワークフロー/秒) になっています。フロントエンド サーバーを 4 台以上に増やしても大きな効果はありません。

タスク完了のスループット

スループットに対するリスト サイズとワークフロー インスタンス数の影響

次の表のテストは、リスト サイズとワークフロー数の増加に応じてスループットがどのように変化するかを示しています。データを生成するために、リスト内に 100 万個のアイテムが作成されるまで自動開始ワークフロー テストを連続して実行しました。その際、主要なスループット テストの場合と同様に、スループットを測定するために各チェックポイントで一時停止しました。テストは 4x1 トポロジで実行しました。

データ生成時の信頼性を維持するために、データベース サーバーの最大接続数に到達しないようにワークフロー キューを有効にしておく必要がありました。使用できる接続がなく、ワークフロー操作がコンテンツ データベースに接続できない場合、その操作は実行できません。ワークフロー キューの詳細については、「推奨事項」を参照してください。

アイテム数の増加に応じた自動開始のスループット

単一のリスト、単一のタスク、および履歴リストの場合、アイテム数が 1,000 ～ 100,000 個の間ではスループットが低下し続けます。ただし、それ以降は低下の割合が小さくなります。スループットが低下する要因は複数あります。

1 つの要因は、インスタンスごとにコンテンツ データベース内の多数のテーブルに追加される行の数です。前述のとおり、ワークフローでは、各ワークフロー インスタンスで登録されるイベント レシーバーに加えて複数のリスト アイテムが作成されます。さまざまな領域でテーブル サイズが大きくなるにつれ、行の追加が遅くなり、この追加の遅れが合わさることでリスト アイテムの作成のみに伴う低下よりも低下の割合が大きくなります。

タスク リストのサイズはオーバーヘッドが増加する一因となります。新しいリストに対して実行されるワークフローと新しいタスク リストに対して実行されるワークフローのスループットの比較では、タスク リストの方がパフォーマンスに大きく影響しました。これは、タスク リストでは親リスト アイテムよりも多くのイベント レシーバーが登録されるためです。次の表にこの違いを示します。

大きなリストに対して多数のワークフローを実行する必要があり、テストで示されている以上のスループットが必要な場合は、ワークフローの関連付けの間でタスク リストを分けることが可能かどうかを検討してください。

推奨事項

ここでは、パフォーマンスおよび容量に関する全般的な推奨事項を説明します。これらの推奨事項から、作成した開始トポロジの容量およびパフォーマンスの特性を確認して、開始トポロジのスケール アウトとスケール アップのどちらが必要かを判断することができます。

システムの最小要件と推奨要件の詳細については、「ハードウェア要件およびソフトウェア要件 (SharePoint Server 2010)」を参照してください。

スケール アウトしたトポロジ

最大 4 台の Web サーバーにスケール アウトすることで、ワークフローのスループットを向上できます。それ以上サーバーを増やしても、大きく向上することはありません。ワークフローのスループットは、パフォーマンス関連のワークフロー設定によって制限できます。これらの設定の詳細については、「ワークフロー キューとパフォーマンス関連の設定」を参照してください。

スループット目標の見積もり

多くの要因がスループットに影響します。たとえば、ユーザー数、ユーザー操作の種類、複雑さ、頻度などが要因として挙げられます。コンテンツ データベースに対して実行する操作が増えたり、登録するイベントが増えたりして、ワークフローが複雑になるほど、他のワークフローよりも実行が遅くなり、消費するリソースが増加します。

このテストで使用されたワークフローでは、タスク アクティビティに組み込まれる複数のエントリがコンテンツ データベースに作成されます。使用するワークフローに含まれるタスクが少数である場合は、同じようなスループットの特性になると予想できます。大部分のワークフローに含まれる操作が非常に軽量である場合は、スループットが向上する可能性があります。ワークフローが多数のタスクや集中的なバックエンド操作で構成される場合や、処理能力を必要とする場合は、スループットが低下すると予想できます。

ワークフローの操作内容を把握するだけでなく、ワークフローの実行場所や、ワークフローの実行対象が大きなリストであるかどうかも考慮してください (大きなリストではスループットが経時的に低下します)。

SharePoint Server 2010 はさまざまな方法で展開および構成できます。そのため、特定のサーバー数でサポートできるユーザー数を簡単に見積もる方法はありません。したがって、SharePoint Server 2010 を運用環境に展開する前に必ず独自の環境でテストを実施してください。

ワークフロー キューとパフォーマンス関連の設定

ワークフローでは、キュー システムを使用して、ファーム リソースおよびコンテンツ データベースに対するワークフロー関連の負荷を制御します。このシステムを使用すると、データベースに対して実行中のワークフロー数が管理者により構成されたしきい値に達した場合に、後続のワークフロー操作が Workflow Timer Service によって実行されるようにキューに追加されます。既定では、このサービスは、1 分間隔でタイマー ジョブを通じてワークフローの作業アイテムのバッチを受け取ります。

キューのメカニズムに直接的および間接的に関連する複数のファーム管理者設定が、ワークフローのパフォーマンスおよびスケーリングに影響します。この後では、これらの設定の動作およびパフォーマンス要件に合わせて設定を調整する方法について説明します。

基本的なキュー設定について

ファーム管理者は、次の設定を調整してキュー システムの基本的な特性を構成できます。

• ワークフローの延期のしきい値 (Set-SPFarmConfig –WorkflowPostponeThreshold <整数値>)

  1 つのコンテンツ データベースに対して実行できるワークフローの最大数。この値を超えた場合、追加の要求および操作はキューに入れられます。キューに入れられたワークフローの状態は "開始処理中" になります。これはファーム全体の設定で、既定値は 15 です。この値が示すのは、一度に処理されるワークフロー操作の数であり、進行中にすることができるワークフローの最大数ではありません。ワークフロー操作が完了すると、後続の操作を実行できるようになります。

• ワークフローのイベント配信のバッチ サイズ (Set-SPWorkflow –BatchSize <整数値>)

  Workflow Timer Service は延期のしきい値の対象外であり、キューからアイテムのバッチを取得し、それらのバッチを 1 つずつ実行します。バッチは延期のしきい値よりも大きくすることができます。このサービスが受け取る実行あたりの作業アイテム数は BatchSize プロパティで設定します。BatchSize プロパティはサービス インスタンスごとに 1 回設定でき、既定値は 100 です。フロントエンド サーバーとして構成されていないアプリケーション サーバーで実行する場合、Workflow Timer Service を使用するには、Web.config のワークフロー構成設定を構成データベースに設定する必要があります。これを行うには、Web.config 設定をフロントエンド サーバーからコピーする SPWebApplication オブジェクトの UpdateWorkflowConfigurationSettings() を呼び出すスクリプトを使用する必要があります。

• ワークフロー タイマー ジョブの頻度 (Set-SPTimerJob job-workflow –schedule <文字列>)

  Workflow Timer Service の実行頻度はタイマー ジョブ設定によって調整できます。既定では、5 分間隔で実行するように設定されています。つまり、既定値の場合、キューの先頭にある作業アイテムが処理されるまでに 5 分間の遅延が発生する可能性があります。

  注意

  タスクの有効期限など、スケジュールされた作業アイテムも同じタイマー メカニズムによって処理されます。したがって、同じ間隔で遅延が発生します。

Workflow Timer Service は、サーバーの全体管理の共有サービス管理を使用してサーバーごとに無効にすることができます。既定では、ファーム内のすべてのフロントエンド サーバーで実行されます。各ジョブは、ファーム内のすべての Web アプリケーションおよびコンテンツ データベースの繰り返し処理を行います。

延期のしきい値、バッチ サイズ、およびタイマーの頻度を組み合わせて使用することで、データベースに対するワークフロー操作を制限できます。最大スループットに対しては、操作がキューに入れられてキューから処理されるのにかかる時間が影響します。

たとえば、既定の設定、単一のタイマー サービス、単一のコンテンツ データベースでは、1,000 個のアイテムがキューにある場合、それらをすべて実行するには 10 個のタイマー ジョブが必要であり、実行には 50 分かかります。しかし、バッチ サイズを 1,000 に設定し、1 分間隔で実行するようにタイマー ジョブを設定すると、1 分後にはすべての操作の実行が開始されます。延期のしきい値を大きくすると、同時に実行できる操作が増え、キューに入れられる要求数が減り、それらのワークフローの処理にかかる合計時間が短くなります。

ワークフローをフロントエンド サーバーでは実行せず、操作を直ちに処理する必要もない場合には、指定したアプリケーション サーバーのみで Workflow Timer Service を実行するようにし、延期のしきい値を非常に小さい数に設定してワークフローが通常はタイマー サービスで実行されるようにし、バッチ サイズを大きい値に設定してアイテムをより迅速かつ短い間隔で受け取るようにすることができます。システムで同時に実行されるワークフロー数を増やす必要がある場合は、延期のしきい値をより大きい値に設定します。これにより、ワークフローが延期される頻度が減り、より迅速に反映されるようになります。

これらの設定を変更してワークフローの運用方法に合わせて最適化します。さまざまな設定をテストして、環境や要件に合うように最適化することをお勧めします。

キュー設定の調整

ファームで大規模のワークフローを長時間にわたって処理する場合や、システムにおいてワークフローからキューに入れられる遅延イベントが多数ある場合は、キューに入れられるワークフロー操作の数が増加します。キューを正常な状態に保つためには、基本的なキュー設定に加えて、次の設定を調整することが必要になる場合があります。

• 作業アイテムのイベント配信のバッチ サイズ

  キューに入れられたイベント用にワークフローで使用されるテーブルは、SharePoint Server 2010 のワークフロー以外の他の機能 と共有する汎用の作業アイテム テーブルです。そのため、ワークフロー以外の作業アイテムをキューから削除する別のタイマー ジョブがあります。ワークフローのイベント配信のバッチ サイズと同様に、作業アイテムのイベント配信のバッチ サイズは、一度にキューから削除されるワークフロー以外の作業アイテム数を指定します。

• ワークフロー フェールオーバー タイマー ジョブの頻度

  まれですが、ワークフロー イベントをワークフロー インスタンスに配信できない場合、イベント配信は、後で再試行するためにフェールオーバー作業アイテムとしてキューにスケジュールされます (最初は 5 分後、再度失敗した場合は 10 分後、その次は 20 分後のようになります)。ワークフロー フェールオーバー タイマー ジョブはフェールオーバー作業アイテムをキューから削除します。この設定はフェールオーバー タイマーの実行頻度を調整します。既定では、15 分間隔で実行されます。

• ワークフロー フェールオーバーのバッチ サイズ

  ワークフローのバッチ サイズ設定および作業アイテムのバッチ サイズ設定と同様に、この設定は、各フェールオーバー タイマー ジョブによってキューから削除されるフェールオーバー イベント数を制御します。

  同じテーブル上で動作するタイマー ジョブが多数あるため、キューに入れられた大量のアイテムによってデータベース競合が発生し、スループットや信頼性が低下する場合があります。競合を減らすためには、次のことを推奨します。

  • 延期のしきい値とワークフローのバッチ サイズを調整します。具体的には、完了できずに並行して実行されるタイマー ジョブが増え続けるのを避けるために、次のタイマー ジョブが開始される前にタイマー ジョブを完了できるようにバッチ サイズを小さくするか、タイマー ジョブの頻度を上げます。

  • テーブル ロックを避けるには、両方のバッチ サイズの設定を 5,000 以下にしてください。

タスク リストと履歴リストのスケーリングの強化

ワークフローでは、インスタンスごとに多数のタスクと履歴アイテムが生成されます。既定では、スケーリングに役立つようにこれらのリストにはインデックスが設定されますが、リストが大きくなると、必ずパフォーマンスも低下します。低下の割合を小さくするには、ワークフローの関連付けごとに別々の履歴リストとタスク リストを保持し、リストの増大に合わせてワークフローの関連付け設定でリストを定期的に変更します。

ワークフローには、ワークフロー インスタンスと完了後 60 日経過したインスタンスのタスクを自動的に削除する日次タイマー ジョブ (job-workflow-autoclean) もあります。タスク リストとタスク リスト上のイベントについてできる限り不要なデータがない状態に保つには、このタイマー ジョブを有効にしておきます。データを維持する必要がある場合は、他のリストやアーカイブ用の場所にデータを書き込んでください。このタイマー ジョブでは、ワークフローの履歴アイテムは削除されません。これらのデータをクリーンアップする必要がある場合は、スクリプトで実行するか、リスト ユーザー インターフェイスから手動で実行する必要があります。

その他の考慮事項

リストの列を削除すると、リスト内のアイテム数に比例してデータベース操作が発生します。ワークフローの関連付けを削除すると、リストからワークフローの状態列が削除されます。したがって、大きなリストでは多数の操作が発生します。リストに大量のアイテムがあるとわかっている場合は、ワークフローを削除するのではなく、ワークフローを [新しいインスタンスの開始を許可しない] に設定してください。

トラブルシューティング

Web サーバー

次の表に、ファーム内の Web サーバーを監視するためのパフォーマンス カウンターおよびプロセスを示します。

データベース サーバー

次の表に、ファーム内のデータベース サーバーを監視するためのパフォーマンス カウンターおよびプロセスを示します。

See Also

Other Resources

Workflow Scalability and Performance in Windows SharePoint Services 3.0 (https://go.microsoft.com/fwlink/?linkid=207353&clcid=0x411) (英語)