IISのアプリケーションプールやワーカープロセスについて

Question

お世話になっております。

Sharepoint2013で、少しでもパフォーマンスを上げようと思いまして、

以下2点、情報があればご教授頂ければ幸いです。

1.ワーカープロセス数

SP2007の情報ですが、以下にWEBガーデンは使用しない、という情報があります。

2013においても、ワーカープロセス数は１というのが推奨でしょうか。

また、増やすことについて新しい情報はありますでしょうか。

http://technet.microsoft.com/ja-jp/library/cc298550(v=office.12).aspx

2.アプリケーションプールのリサイクル

SPによって自動で構成されたWEBサイトは、リサイクルしない設定となっています。

これについてカスタマイズする場合の注意点や指針なでの情報はありますでしょうか。

よろしくお願いいたします。

Answer 1

SharePoint の知識がない自分がレスするのもなんですが・・・

> Sharepoint2013で、少しでもパフォーマンスを上げようと思いまして、

「パフォーマンスを上げよう」ということが具体的にどういう意味か不明ですが、スループットの向上（スレッドプールの飽和による要求の処理待ちをミニマムにする）ということと理解します。

スループットを向上させるには以下のような方法があります。

(1) スレッドプールのサイズを増やす。

(2) Web ファームにサーバーを追加する。

Web ガーデンがダメと言う理由は知りませんが、Web ファームは SharePoint システムでも利用されているようです。

3 層ファームの複数のサーバーに SharePoint 2013 をインストールする
http://technet.microsoft.com/ja-jp/library/ee805948(v=office.15).aspx

(3) 非同期プログラミングを利用する。

ASP.NET の非同期プログラミングを使ったスケール変換可能なアプリケーション
http://msdn.microsoft.com/ja-jp/magazine/cc163463.aspx

このうち (2) が質問者さんの言われるワーカープロセス数を増やすと言うことと同じになるかと思います。ただ、(3) に紹介した MSDN マガジンの記事によると (1) も (2) も「一時的な救済策にすぎません」と言うことだそうです。

> SPによって自動で構成されたWEBサイトは、リサイクルしない設定となっています。
> これについてカスタマイズする場合の注意点や指針なでの情報はありますでしょうか。

質問者さんが参考にされているページにも「可用性が向上するようにアプリケーション プールのリサイクルを構成する」とか「32 ビット ワーカー プロセスのリサイクルを監視および管理する」という記述がありますし、リサイクルなしでサーバーの正常性が保障できるとは思えないのですが。

逆に質問してすみませんが、そういう MSDN ライブラリの記事などがあれば教えてください。

Answer 2

SharePoint はさっぱりなので、IIS の一般論として。

>1.ワーカープロセス数
Web ガーデン(Web アプリケーションあたりのワーカープロセス数を増やす)については特に情報がありませんね。
ただ、Web ファーム(複数台の Web サーバーで負荷分散)ができるので、1 のまま特に変える必要は無いかと思います。

>2.アプリケーションプールのリサイクル
これはパフォーマンスアップでは無く、可用性の機能ですね。
プロセスが再起動されるので、障害が起きていても一旦リセットされてきれいな状態で再稼働、あるいはメモリが解放されてメモリの断片化率が下がった状態で再稼働、ということになり、これにより長期の安定稼働がはかられます。
障害やメモリの断片化によってパフォーマンスが劣化している状態であればパフォーマンス改善しているとはいえますが、メモリ上のキャッシュが消えますので特に初回アクセス時は非常に遅くなるという、パフォーマンスダウンの側面もある機能です。
以下にも関連する記述があります。
http://technet.microsoft.com/ja-jp/library/hh407293(v=office.15).aspx
なお、リサイクルの設定自体は、可用性も鑑みて適切に設定すべきもののようで、古い記事ですが以下に考え方などが例示されているようです。
http://blogs.msdn.com/b/steveshe/archive/2007/12/23/overlapped-recycling-and-sharepoint-what-are-the-64-bit-settings.aspx

---

MCITP（Database Developer/Database Administrator）

Answer 3

いろいろと情報ありがとうございます。

曖昧な質問で申し訳ありません。

現状、WEBサーバは2台構成にしており、WEBファームの状態にはなっているという認識です。

1.については、

その状態のWEBサーバ2台に対して、それぞれのSharepointのWEBサイトのワーカープロセスを複数にすることについて、

性能向上を図るという案があり、ただSharepointとしては推奨されないような過去の情報があったため、

質問させて頂きました。

ワーカープロセス数をマシンのコア数に合わせることで、ハードのリソースを有効活用できる、

という話しをきいたもので。。。

2.については、

ひとまず頂いた情報を少しだけ見させもらった範囲ですが、

色々な面でリサイクルを適切に行うことが望ましいと思いますので、2台のWEBサーバでタイミングをずらすなど、

少し検討して設定してみようと思います。

どうもありがとうございました。

Answer 4

Web ガーデンについては認識通りだと思いますが、複数プロセスで処理するということは、排他処理がバッティングしたり(ログファイルや OS のリソースの競合)するので Web アプリケーション側が対応している必要がありますし、オンメモリの情報をプロセス毎に持つことになるのでトータルのメモリ使用量が増えたりするといったいくつかネガティブな要素もあります。
ですので、Web ガーデンはパフォーマンスアップとイコールではありませんので、その点ご留意ください。
元々はこちらも可用性(1 つのプロセスが死んでも他のプロセスが処理を継続できる)というところから来ている機能ではないかと個人的には理解しています。
(※パフォーマンスアップがはかれる可能性は確かにあり、そういう用途で使うこと自体は間違いではありません)

調べた限りではやはり最初の質問で記載されたページしかありませんでした。
MSDN サブスクリプションのオンラインチャットでも調べてもらいましたが、関連情報としてこのスレッドが出てきてしまうほど、情報がありませんでした・・・。
アカウントを拝見するにパートナー表示がありますので、パートナーフォーラムの方でお問い合わせされてみてはいかがでしょうか。

---

MCITP（Database Developer/Database Administrator）

Answer 5

自分の勉強も兼ねて確認を。

> 2.アプリケーションプールのリサイクル
> SPによって自動で構成されたWEBサイトは、リサイクルしない設定となっています。

私の認識では、時間指定でリサイクルする設定になっていると思います。
リサイクルする時間は、大抵、深夜時間帯(2:00前後)が設定されており、
naginoさんに記述して頂いた通り、初回アクセス時に非常に重い現象が発生し、
いわゆる、SharePoint構築者の間では知らない人がいないと思われる
「朝一アクセスが重い」が標準で発生する状況となります。

ここからは素人考えですが、WebガーデンがSharePointで推奨されない理由も、
上記に関連してだと思っていました。
Webガーデンを利用するとワーカープロセス数が上限範囲内で増減する認識でおり、
その度に、上記初回アクセス問題が発生すると思っていました。

Answer 6

ググって調べてみると、Web garden を BLOB cache と一緒に使うなという記事は多々見つかりました。例えば下記ページ。

しかし、Web garden と Page cache については、自分が調べた限りですが、結局回りまわって質問者さんが最初の質問で挙げた TechNet のページにたどり着くだけで、「ページ出力のキャッシュに悪影響が出る」という理由は分かりません。

MOSS Server Performance Considerations
http://blogs.technet.com/b/waynemo/archive/2008/03/19/moss-server-performance-considerations.aspx

ちなみに、Web garden を BLOB cache と一緒使うなと言う理由は、上記の記事によれば以下の通りだそうです。

"Because only one process can acquire the lock necessary to manage the cache, successful use the cache depends on which thread services a request.  If a Web garden that does not have the BLOB cache lock services a request, the content it sends in response will not have caching directives associated with it."

キャッシュの場所は BLOB cache の場合は HDD、Page cache の場合はメモリということなので、どうも同じ理由ではなさそうです。

Web Garden の使用は Page cache に悪影響が出るという話は、IIS + ASP.NET ベースの Web アプリでは聞いたことがないです。（自分が知らないだけと言う可能性は否定できませんが）

なので、SharePoint が拡張した部分の特殊事情があるのか、TechNet の記事が間違っている（Page cache ではなくて BLOB cache）のではないかと想像しているのですが、どうなんでしょう？

なぜ「ページ出力のキャッシュに悪影響が出る」のか、ご存知の方は教えていただけると幸いです。

Answer 7

そうなんですよね、この件、理由や背景に関する情報が皆無なんですよね。
SharePoint の内部実装の話になると思うので有償サポートでもたぶん対応範囲外とされる気がしますし、どうしたものやら。
SharePoint の詳しい会社さんはいくつかありますが、そちらは飯のタネですので無償で公開して頂けるハズも無く・・・。
この件は残念ながらこのあたりが限界な印象です・・・。

---

MCITP（Database Developer/Database Administrator）

Answer 8

みなさまありがとうございます。

パートナーフォーラムでも質問させて頂きました。情報頂けたらこちらにも展開したいと思います。

また、アプリケーションプールのリサイクルによる初期起動が遅い件について、

これの対応として、

・アプリケーションプールの「開始モード」を「AlwaysRunning」する

・WEBサイトの「有効化されたプリロード」を「True」にする

というのはどうなんでしょうか。

一般的なWEBサイトの考え方としては、まさにそのためにあるような設定かと思いましたが、

sharepointとしてどうなのか、というところが判断つきません。

Sharepointが自動作成するIISのサイト等の設定、明確な根拠がないと変更するのが怖いため、

なかなか難しいです。

テスト環境を構築して検証して、実際の結果を見ていくしかないですかね。。。

参考

http://blogs.msdn.com/b/chack/archive/2013/09/25/using-aspnet-iis-auto-start-on-windows-azure-cloud-services.aspx

Answer 9

> これの対応として、
> ・アプリケーションプールの「開始モード」を「AlwaysRunning」する
> ・WEBサイトの「有効化されたプリロード」を「True」にする
> というのはどうなんでしょうか。

そのあたりは最初の質問の主旨とはちょっと違う内容ですので、新たに別のスレッドを立てて違う質問として質問することをお勧めします。

その方が閲覧者の目に付きやすいので回答を得られるチャンスが増えると思います。

また、一つのスレッドで複数の問題の Q&A があると、検索などで調べごとをしていて後からここを訪問する閲覧者にわかりにくいという問題もありますので。

Answer 10

ページ出力キャッシュへの悪影響については、前に何かで読んだ記憶では、引退エンジニアさんが書かれていることに近いですが、オンメモリキャッシュがプロセス毎に独立する＝無駄になる、という非常に単純な話だった気がします。

※ただ、何で読んだのか、あるいはそう推測した（それくらいしか思い当たらなかった）だけだったかも思い出せません。

BLOBキャッシュの方は逆にディスク上で共有することによる、プロセス間でのリソース競合絡みの問題ですね。