おっと！SharePointのキャパシティープランニングを忘れていた

キャッチーな表題ですが、実はとても有益な記事が掲載されていましたのでご紹介します。

TechTarget
パフォーマンス低下を招く前に おっと！SharePointのキャパシティープランニングを忘れていた

実際問題として、SharePointのチューニングは難事です。記事にもあるように関連技術があまりに多岐に渡るのが原因です。

SharePointは多階層型アプリケーションであるため、キャパシティープランニングが非常に複雑になることがある。Windowsファイルシステム、Active Directory（以下、AD）、.NET Framework、Internet Information Services、SQL Serverのさまざまなキャパシティー制限に関する知識も不可欠だ。

また、これに加えて、Microsoft社のドキュメントの難読性も大きな阻害要因でしょう。そのため「リストには2000アイテムまでしか登録できない」といった不正確な情報が都市伝説的に吹聴されたりします。この記事のように、具体的指標とその技術的裏付けが明記された情報はとても希少です。

ただ、一方で、この記事にも「あれ？」と思う部分がありました。

リストには500万項目を含めることができるが、そのデータのビューのパフォーマンスは200項目で低下し始め、2000項目で動作が停止する。これは、ベースとなるSQLクエリのページングやフィルタリングが行われなくなるからだ。

なるほど、そうなのか、と納得しかけましたが、厳密にはこれは間違いだと思います。実際に10000アイテムが登録されたリストを作成し、3列×3000行を表示してみましたが、非常に処理が重いものの、きちんとデータが表示されました。少なくとも「動作が停止」するということは無いようです。

グループ化されたビューの場合、この点に特に注意する必要がある。カテゴリーを展開するまで一部のデータしか表示されなくても、すべてのデータがロードされるからだ。

これも誤解だと思います。SharePoint 2003 ではそうでしたが、SharePoint 2007 では、グループは（閉じている場合）ヘッダと件数だけが読み込まれ、実際にアイテムがロードされるのはグループを展開したタイミングの筈です。
これも、前出の巨大リストで、全アイテムをA～Zの25項目で分類し、ビューにグループ化して全項目を表示してみましたが、レスポンスにも問題なくきちんと表示されました。

別に筆者を批判したい訳ではないので誤解なく。もしかすれば、筆者ではなく翻訳者の間違いかもしれませんしね。

むしろ、この記事で重要なのは、ADの限界値に関する部分だと思います。

SharePointに影響するADの制約というのは、個々のセキュリティ対象オブジェクトのセキュリティプリンシパルに適用されるキャパシティー制限だ。サイト、ライブラリ、リスト項目に関連付けることができるユーザーとグループの数には制限があり、これを超えると正しくインデックス化が行われない。この制限は約2000ユーザーとなっている。これは、ADのAccess Control List（ACL）のサイズが64Kバイトに制限されており、1ユーザーあるいは1グループのサイズが約32バイトであるからだ。
SharePointが項目をインデックス化するときに64Kバイトの制限に到達すれば、その項目とそれ以下のすべての項目のインデックス化が失敗する。つまりACLは64Kバイトを超えても構わないが、ACLのインデックス化が行われないということだ。
ADの1つのグループは1つのセキュリティプリンシパルとしてカウントされ、1つのADグループには10万ユーザーを含めることができる。つまり、1つのドキュメントに2000以上のユーザーを関連付けるには、ADグループメンバーシップを通じた間接的な方法でしか行えないということだ。また、1人のユーザーを1015以上のグループに含めることができないことにも注意が必要だ。

原文を読んでみたいのですが、見つけられませんでした。
どなたかご存知でしたら教えてください…

SPSFAQ SharePoint Server Frequently Asked Questions
TechTarget
パフォーマンス低下を招く前に おっと！SharePointのキャパシティープランニングを忘れていた