- - PR -
ASP.NET worker processのprocessModel
1
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-09-19 00:57
ASP.NET worker process（aspnet_wp.exe）に関する質問です。
ASP.NETでは、クライアントからの要求を受け付けるとASP.NET worker process（以後、worker processと呼びます）中のスレッドが処理を担当します。 worker process中にスレッドをいくつまで作成できるは、machine.config構成FILE中の<processModel>要素のmaxWorkerThreadsとmaxIoThreadsに指定した値で制限されるようです。 この「WorkerThreads」と「IoThreads」の違いがわかりません。 どなたかご存知の方がいらっしゃいましたら、教えていただけないでしょうか。 さらに、クライアントからの大量の要求を同時に受信した場合、スレッドの上限を超えることがあります。 そのような場合、処理しきれない要求については、クライアントに"503 - Server Too Busy"の応答コードを返します。 但し、大量の要求は一度ASP.NETが用意するQUEに保管されるようです。 そのQUEに格納できる要求の最大数というのもmachine.cofigに指定できるようです。 このQUEに関する指定も２種類存在します。 <processModel>要素のrequestQueueLimit と <httpRuntime>要素のappRequestQueueLimit です。 この２つのQUEの違いについてもいまいち理解できません。 ご存知の方がいらっしゃいましたら、教えていただけないでしょうか。 最後にこのQUEの機能に関することです。 クライアントからの大量の要求の一部は、ASP.NETが用意するQUEにいったん保管されるようです。 しばらく待ってworker process中のスレッドが利用可能になった場合、QUEに保管されていた要求が取り出されて処理が開始されるように動作しているようです。 このことは、IISのログから判断した要求の受信時刻と、スレッドがその要求を処理開始した時刻をロギングしたものを比べて、数秒の差があることから予想したことです。 なるべくなら要求がこのようにQUE中に滞留してしまわないようにしたいと考えています。 クライアントに対する応答時間を重視したいからです。 タスクマネージャでworker process中のスレッド数を監視すると、大量の要求を受け付けてからスレッドが増えていく過程が確認できます。 その増え方が非常に遅いのです。 これが要求がQUEに滞留する時間を長くする原因ではないかと考えていますが、このような現象を抑えるためにできることは何かないでしょうか？ 以上です。 私の説明がわかりにくいところもあるかと思いますが、ご存知の情報がありましたらお知らせください。 よろしくお願いします。 | ||||||||||||
|
投稿日時: 2002-09-20 22:36
両者はともに、CLRがWin32プロセスごとに用意するスレッドプール内のスレッドの数です。.NET Framework 1.0のデフォルト値は共に25です（この数字はv1.1では変更されるでしょう）。 WorkerThreadsのほうは、ThreadPool.QueueUserWorkItemを呼び出したときなどに使われるスレッドの数です。Ioのほうは、Win32の「IO Completion Port」に待機しているスレッドです。たとえばNetworkStreamの非同期機能を利用するときに使われます。 この25という値は、アンマネージコードでICorThreadPoolというCOMのインターフェイスを操作するコードを書けば変更できます。おそらくaspnet_isapi.dllが、machine.configの設定を見て、このスレッドプールをセットアップしているものと思われます。
推測ですが、<processModel>の値は、aspnet_wp.exe全体でのリミットで、<httpRuntime>のほうはそれぞれのWebアプリケーションごとのリミットということではないでしょうか？つまり、localhost/WebApp1とlocalhost/WebApp2があったときに、WebApp1が503を返しても、WebApp2は動作し続けられるような構成ができるのではないか、と。
それこそ、appRequestQueueLimitを調整すればいいのではないでしょうか？ | ||||||||||||
|
投稿日時: 2002-09-24 12:33
NothingBut.NETFXさん。
情報ありがとうございました。 worker process内のスレッド管理は、ThreadPoolクラスにより行われているということですね。 このクラスの存在をこれまで知りませんでした。 さて、前回の書き込みからテストを繰り返し、多少は状況がつかめてきました。 もう少し私の作成しているアプリケーションについて説明しておきます。 サーバーはWebサービスで構成しています。 実際の実行環境では、クライアントは8000程度存在することになります。 Webサーバは3台用意し、ロードバランサーによりクライアントからの要求を振り分けます。 クライアントからは頻繁にアクセスがあるわけではないので、せいぜい分間300くらいの処理能力があればよいということになっています。 とはいえ、アクセスが集中したときのことを踏まえて、性能テストを繰り返しているわけです。 テスト環境ではWebサーバーは1台、ロードバランサーは使用していません。 テストでは、クライアントから1000リクエストを同時に送信しています。 そのリクエストのうち9割以上が503のエラーで失敗します。 だいたい20リクエストくらいがWebサービスの呼出しに成功します。 応答時間が長くならなければよいので、エラーになってしまうこと自体は問題ありません。 そして、エラーになるものについては、それほど応答時間は問題ではないことがわかっています。 問題は、正常に処理されるリクエストです。 テストでは、appRequestQueueLimit を 1 に設定しています。 最初は、0 に設定してみましたが、どうも動作に不具合が起きてしまいました。 Webサービスが呼び出された時間をログに書き出すようにしているのですが、正常に処理されるもののうち最後の１つだけが他のものに比べて開始時間が7〜10秒も遅くなっています。 これは、リクエストがQUEに滞留していることが原因だと考えています。 できればこの滞留をなくしたいと考えているのですが、それを制御する方法がわかりません。 また、maxWorkerThreadsとmaxIoThreadsの値を大きくしていくと、正常に処理されるリクエスト数は増えていきます。 しかし、Webサービスの処理開始時間のばらつきもまた大きくなる傾向があります。 スレッドを増やす処理で秒単位でコストがかかっているようです。 このような状況です。 今後テストをさらに繰り返し実施して、理想的な設定を探っていきたいと思います。 | ||||||||||||
|
投稿日時: 2002-09-26 16:19
追記：
現在の自分が作成したWebサービスのラッシュ時性能を調査しています。 ----（以前の投稿を引用）----- Webサービスが呼び出された時間をログに書き出すようにしているのですが、正常に処理されるもののうち最後の１つだけが他のものに比べて開始時間が7〜10秒も遅くなっています。 これは、リクエストがQUEに滞留していることが原因だと考えています。 ----（以前の投稿を引用）----- つまり、クライアント側では一斉にリクエストを送信しているにも関わらず、実際にWebサービスの処理が開始される時間にばらつきがあるのはASP.NETが用意するQUEにリクエストが滞留するからだと推測していました。 しかし考えてみると、IISが最初にリクエストを受け取っているわけで、送信されてきた大量のリクエストをREADし、その内容をworker processに通知して・・・といったような処理をIISが行っているわけです。 IIS内部でもマルチスレッドでこれらの処理を行っていると思いますが、大量のリクエストを一斉に処理しているわけで、ここでも滞留することが考えられるのではないかと考え直したのです。 要するにIISのラッシュ時の処理性能がネックになっているのではないかと。 .NETの話題からはずれてしまいました。 ただ、もしこの件についてご意見のある方がいらっしゃいましたら、情報を提供していただけませんか。 よろしくお願いします。 | ||||||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。