ASP.NET スレッドプール枯渇の再現(5) - "Server too busy" をようやく再現 & 非同期呼び出しの効能

さて、ASP.NET スレッドプール枯渇の再現(5) の続きである。

前回までで、既定の構成では、そうやすやすとは "Server too busy" を再現はできなさそうだ、ということまでわかった。
そこで、ここではあえて構成をいじって、"わざと" "Server too busy" の再現に努めてみる。

まず手始めに、要求キューの容量を減らしてみることにした。
要求キューの容量をいきなり0にしてみたところ、たった1要求でも受け付けてくれなかった。というか、Server too busy ですらなく、コネクションが張れなかったようだ。
ということで、要求キューの容量は 1 とした。これならいちおう正常に要求～応答が返るようになった。

次はワーカースレッドの数。
ワーカースレッド最大数を調整して、同時並行処理可能な要求数を 1 にしてみた。
ところがこれまた、まともな接続が確立しない。
よくわからないが、とりあえず同時並行処理可能な要求数を 2 してみたところ、動作するようになった。
まぁ、なにか実装や設計上の理由や仕組みがあるのでしょう。

とにかく、ここまで調整すると、やっと "Server too busy" にお目にかかることができた。

処理に2秒間かかるWebサービスを呼び出す、前後それぞれ0.5秒ずつ処理時間がかかる(つまりぜんぶで3秒かかる) ASP.NET ページに対して、1秒につき1要求を送ることを繰り返すと、6要求目(6秒目)を送り込んだ時点で、"Server too busy" となるのだ。

これは言葉で説明する方が難しいので、下図を参照してほしい。

どうだろう。
同一時間(縦軸)上に、いちどにオレンジ色のバーは2つまでしか並べられず(つまり、同時並行処理可能数=2)、それ以上同一時間上に並べるには要求キュー=グレーのバーとして待たせなくてはならない。
しかし、グレーのバーも同一時間に並べられるのはひとつまで(要求キューの容量=1)なので、6要求目にはもう限界、ということだ。

さて、ずいぶんと長いことかけてスレッドプールの枯渇の再現にたどり着いたわけだが、そもそもの目的はなんだったのか?

そう、そもそもは、ASP.NET 非同期ページを実装したときに、その実装が正しいかどうか確認するためだ。

ということで、続けて、このテストで作成した ASP.NET ページを非同期ページとして実装しなおしてみた。

実装自体は簡単。
Visual Studio が生成してくれた Web サービス呼び出しのためのプロキシクラスには、同期呼び出しとしての Web サービス呼び出しメソッドだけでなく、その非同期呼び出しバージョンのメソッド(と、非同期呼び出し完了時のコールバックのためのイベント)も用意してくれている。"～Async" と、Async で終わっているメソッド名がそれだ。
ページ側のコードでは、
1. Webサービスに対するプロキシクラスのインスタンスを生成し、
2. 非同期呼び出し完了時に発射されるイベントにイベントハンドラを追加し、
3. 非同期バージョンのメソッドを呼んで、あとはページ側コードから脱出し、
4. イベントが発射されてコールバックされるのを待つだけ
だ。
注意点としては、.aspx ページのページディレクティブに Async="true" 属性の記載が必要な点だろうか(自分はついうっかり忘れることがあるので)。

こうして実装しなおした ASP.NET ページに対して、先と同じように 1 秒 1要求を繰り返し送信し続けてみた。
結果は、すべての要求が3秒後には応答が返ってきた。

図で表すと、下図のとおりか。

そもそも要求キューに溜まることすらないわけだ。

これまでの経過でみてきたとおり、既定の構成で、かつ、同期呼び出しの実装であっても、なかなかそうおいそれとは Server too busy にはならないようだ。
特に要求キューが5,000もある状況ではなおさらである。

しかし、同期バージョンの時の図と見比べるとわかるが、同期バージョンでもどうにかさばききった5要求目の処理完了時間は、非同期バージョンのほうが2秒も速いのだ。

ユーザーに対する応答性能ということも考えると、やはり、非同期呼び出しの実装を前向きに検討する必要があるように思われた。
(もちろん、何事もケースバイケースなので、非同期呼び出ししようがムダなこともあるだろう)