SharePoint 2010: SharePoint ワークスペースのストレージを最適化する
オフラインで作業をしているときにも SharePoint データを使用することができます。この記事では、SharePoint ワークスペースのストレージ アーキテクチャを最適化する方法を紹介します。
Brien Posey
SharePoint に常時接続した状態を維持することはできません。SharePoint に接続していないときに、SharePoint Workspace 2010 を使用すると、オフラインで作業をしているときでも SharePoint データにアクセスできるようになります。ただし、基盤となるストレージ アーキテクチャには、いくつかのパフォーマンスに関する問題があります。この記事では、このような問題が発生する原因と問題を回避する方法を紹介します。
SharePoint ワークスペースは、ワークスペースのデータを格納するのに使用する記憶域です。クライアント ソフトウェアにも SharePoint Workspace という名前が付けられているので、この記事では、区別するために SPW 2010 と呼ぶことにします。この 2 つを考慮すると、SharePoint ワークスペースは Microsoft Groove のワークスペースと似ていると考えることができます。
SharePoint ドキュメント ライブラリ全体または一部をローカル コンピューターの SharePoint ワークスペースと同期できるというのが基本的な考え方です。このようにすると、オフラインで作業をしているときにもライブラリのコンテンツにアクセスできます。実際の同期処理は SPW 2010 を使用して行います。SPW 2010 は、ライブラリ コンテンツの同期処理を設定して、同期を維持するクライアント コンポーネントです。
最適化の必要性
SharePoint ドキュメントを同期すると、ドキュメント自体はローカルの Office ドキュメント キャッシュに格納されます。一方、関連リスト、InfoPath フォーム、スキーマ、およびビューは、SharePoint ワークスペースに格納されます。少数のドキュメントを同期する場合、SharePoint ワークスペースのアーキテクチャは問題なく動作します。ですが、同期する必要があるドキュメントの数が増えるにつれて問題が生じます。
マイクロソフトによると、500 個以下のドキュメントを同期している場合、SPW 2010 は最適に機能します。500 個以上のドキュメントを同期しようとすると、ドキュメントを同期する負荷が高くなるにつれてSPW 2010 のパフォーマンスが低下することを警告するメッセージが表示されます。
1,800 個以上のドキュメントを同期しようとすると、SPW 2010 では、すべてのドキュメントを同期することを断念して、SharePoint ワークスペースにドキュメントのメタデータのみをダウンロードします。このようにメタデータのみがダウンロードされたドキュメントを開こうとすると、そのドキュメントは、その時点で同期されます。
SPW 2010 では、ドキュメント全体を同期するよりもドキュメントのメタデータをダウンロードした方が効率的です。ですが、なぜ常時後者の処理を実行しないのかと言うと、SPW 2010 の第一の目的は、オフラインで作業しているときにも SharePoint データにアクセスできるようにすることだからです。ドキュメントのメタデータしかなければ、ドキュメントで作業をすることはできません。
ワークスペースのストレージを最適化する
現時点では、この制限事項を回避する方法は 2 つしかありません。1 つは、SharePoint ワークスペースの代わりに Groove ワークスペースを作成する方法です。マイクロソフトによると、この同期に関する制限事項は、Office ドキュメント キャッシュにのみ適用されるもので Groove ワークスペースには適用されません (Groove ワークスペースは SPW 2010 で作成してアクセスできます)。
もう 1 つの方法は、同期するドキュメントの数を減らすことです。同期するドキュメントの数を減らす方法は複数あります。
まず、使用していないワークスペースを削除することでドキュメントの数を減らすことができます。同期処理の効率は、すべてのワークスペースに格納されているドキュメントの総数によって決まります。10 個のワークスペースがあって、各ワークスペースに 100 個のドキュメントが格納されている場合、各ワークスペースでは 500 個というしきい値に達していませんが、SPW 2010 では、1,000 個のドキュメントを同期する必要があります。
SPW 2010 では、ライブラリまたはライブラリのフォルダーへの接続ごとに新しいワークスペースが作成されるので、多くの場合、時間の経過と共に、使用していないワークスペースが蓄積します。このようなワークスペースを削除するのは、SPW 2010 で同期しなければならないドキュメントの数を減らす良い方法です。
また、すべてのドキュメントをキャッシュする必要があるかどうかを検討することもできます。多くのモバイル ユーザーは、移動中に SharePoint データにオフラインでアクセスできることを望むでしょう。ですが、オフライン作業時に本当に必要なドキュメントは限られています。もちろん、すべてのドキュメントがオフラインで利用できれば便利ですが、絶対に必要というわけではありません。キャッシュするドキュメントの数を減らすことで、パフォーマンスの問題を解決できます。
SharePoint ドキュメント ライブラリ全体ではなく各フォルダーを同期する方法をユーザーに知らせることで、ユーザーのエクスペリエンスを向上することができます。SharePoint ワークスペースを作成すると、SPW 2010 では、同期するドキュメント ライブラリと関連付けられている URL が求められますが、この URL にはファイルのパスを追加することができます。
たとえば、サーバーの共有ドキュメント ライブラリに、Finance、Marketing、および HR という名前のフォルダーがあるとします。財務部門に所属している場合、Finance 以外のフォルダーは必要ないので、ドキュメント ライブラリ全体を同期しても意味がありません。実際には、Finance 以外のフォルダーにはアクセス許可がないこともあります。
このドキュメント ライブラリにリンクされたワークスペースを作成するには、https://SharePoint/Shared%20Documents/Finance という URL を使用します。この URL を使用すると、Finance フォルダーと Finance フォルダーのコンテンツのみを含むワークスペースを作成できます。ワークスペースには、同じレベルのフォルダー (HR および Marketing) と共有ドキュメント フォルダーにあるドキュメントは、どちらも含まれません。
トラブルシューティングを行う場合は、まずクライアント側から始めます。と言うのも、SPW 2010 では、同期するドキュメントの数が 500 個を超えるとパフォーマンスが低下するので、クライアント側のストレージは最適化する必要があります。ですが、クライアント側の対応が終わっても、トラブルシューティングは半分終わったに過ぎません。パフォーマンスの問題が発生する可能性が高いのは SPW 2010 の方ですが、SharePoint サーバーも過剰な同期要求によってパフォーマンスが低下することがあります。
SQL Server を監視する
SharePoint では、サイト コンテンツを SQL Server データベースに格納しています。そのため、SharePoint ストレージのアーキテクチャを最適化する場合は、SQL Server に照準を合わせる必要があります。さいわい、マイクロソフトでは SQL Server の監視に使用できるパフォーマンス モニターのカウンターがいくつか提供されています。
これらのパフォーマンス モニターのカウンターの値は、SharePoint 2010 で使用される SQL Server 2008 または SQL Server 2008 R2 に固有のものなので、カウンターの値は、他の種類の SQL Server のデータベースには該当しない可能性があります。
マイクロソフトでは、General Statistics オブジェクトの User Connections カウンターを監視することを推奨しています。このカウンターでは SQL Server に接続しているユーザー接続の総数を示します。カウンターの値が基準値の 500% を超えるとパフォーマンスの問題が発生するため、マイクロソフトでは、このカウンターを監視することが推奨されています。
もう 1 つは Databases オブジェクトの Transactions/Sec カウンターです。マイクロソフトでは、このカウンターの推奨値は提示していませんが、サーバーが正常な状態で実行されているときに、このカウンターの値を記録することを推奨しています。このカウンターの値を記録しておくと、パフォーマンスの問題が発生したときに、1 秒間に実行されるトランザクションの数を基準値と比較できます。
サーバーのロック状態を監視することも、SQL Server のパフォーマンスの状態を確認するのに適切な方法です。監視できるロックに関連するカウンターはいくつかありますが、多くの場合、Locks オブジェクトの Lock Waits/Sec カウンターが最も有益な情報を得られるカウンターです。このカウンターでは、すぐに対応できない 1 秒あたりのロック要求の数を示します。
ロックがすぐに行われない場合は、Locks オブジェクトの Average Wait Time (ms) カウンターを監視します。このカウンターは、ロックが行われるまでの平均待機時間を示します。この値が徐々に増加している場合は、SQL Server でパフォーマンスの問題が発生していると考えられます。
ロックの状態を監視すると SQL Server データベースのパフォーマンスがわかるように、ラッチの状態を監視することでも SQL Server データベースのパフォーマンスがわかります。監視すべきラッチに関連するカウンターは Latches オブジェクトの Latch Waits/Sec と Average Latch Wait Time です。1 秒あたりのラッチの待機が徐々に増加するかどうかを確認します。
待機時間が長すぎる場合も気を付ける必要があります。サーバーが正常に実行されているときに基準値を記録しておくと、将来、問題が発生したときに基準値と比較できるので便利です。
SQL Server でユーザーのクエリが処理される速度も監視する必要があります。SQL Statistics オブジェクトの Compilations/Sec と Re-Compilations/Sec カウンターで 1 秒間に行われているコンパイルと再コンパイルの数を確認します。
この 2 つのカウンターは、サーバーが正常に実行されているときに基準値を記録するのに使用していなければ監視する意味がありません。基準値を記録したら、コンパイルまたは再コンパイルされたクエリの数を監視できます。ユーザー負荷が低下していないのに、これらのカウンターの値が低下した場合は、SQL Server が、ユーザーからの要求にタイムリーに対応できていない可能性があります。
パフォーマンス モニターには、SQL Server のパフォーマンス全般の評価に使用できる汎用的な SQL Server 用のカウンターが用意されています。パフォーマンスの問題を検出したら、ハードウェア関連のカウンターを使用して、問題の診断を掘り下げることができます。
.jpg)
Brien Posey は、MVP であり、数千件の記事と数十冊の書籍を執筆した実績のあるフリーランスのテクニカル ライターです。Posey の Web サイトのアドレスは brienposey.com (英語) です。