全開前回の続きです。

前回、セッションIDにAppDomainAppIdの値が付与されるから複数台な環境だとAppDomainAppIdを合わせておかないとセッション共有ができないんじゃね？という話をしました。

理屈上はそうなので、どうしようかと思って実際にWindows Azure上で見てみると…

おや。複数インスタンスでもAppDomainAppId同じですね。Full IISでマルチサイトしてみましたけど、（法則性はよくわかりませんが）全部同じようです。
想像するにWeb Roleを初期化する際、サービス定義ファイル等に基づいてサイトを作成しますがAppDomainAppIdも指定して作成している感じですか。

というわけでセッションIDに関する懸念はWindows Azure上で使う分には気にしなくて良さそうですね。

さて次はパフォーマンスの話。

前回見てみた限りだと明らかにパフォーマンスに問題がありそうな仕組みでした。
ということで実際どれぐらいなんだろう、というのをぱふぉちゅー素人であるおいらが見てみようと思います。
※言うまでもなく実際にASP.NET Univarsal Providersを採用する際はご自身で確認してください。あくまで参考程度に。

さてテストするにあたってASP.NET Univarsal Providers＋SQL Azureを使用してセッション共有するようにしたWebアプリを5インスタンスで動かします。それからWebアプリにアクセスしてセッションを作成したりするWorker Roleを20インスタンスほど。

台数にあまり深い理由はないんですがセッションの応答速度みるのにサーバー自体がネックになってもなぁと思いつつ5インスタンスに。クライアント側は多めにということで20インスタンスにしました。

クライアント側は単純にWebClient使ってページを読み込むだけです。で、前後で時間を計測する感じに。

class Program
{
	static void Main(string[] args)
	{
		System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();

		GetPage();

		int count = int.Parse(args[0]);

		for (int i = 0; i < count; i++)
		{
			sw.Reset();
			sw.Start();
			GetPage();
			sw.Stop();
			Console.WriteLine("{0}\t{1}",DateTime.UtcNow.ToString("yyyy/MM/dd hh:mm:ss.fff"),sw.Elapsed);
		}
	}

	static private void GetPage()
	{
		WebClient wc = new WebClient();
		using (Stream st = wc.OpenRead("http://penguindrum.cloudapp.net/"))
		{
			Encoding enc = Encoding.GetEncoding("UTF-8");
			using (StreamReader sr = new StreamReader(st, enc))
			{
				string html = sr.ReadToEnd();
				sr.Close();
				st.Close();
			}
		}

	}
}

Webアプリ側は前回と同じやつでセッションオブジェクトが無ければ現在時刻を放り込むだけの簡単仕様

とりあえずひたすらセッションを作っていくわけですが、Insert処理だとそんなに(?)重くない感じですね。
2万セッションぐらい作って（ページ取得の）平均応答時間が0.5秒ぐらい、長くて2秒。

さてセッションを作りまくるワーカー走らせてる横で、同じようにセッション作って、再度そのセッションを使って1分おきにアクセスするような（＝DBを更新するような）クライアントで処理時間見てみようと思います。（※WebClientだとCookieセットできなかったのでHttpWebRequestを使用）

適当にクライアントアプリ作った所為で落ちてますが、うまく更新できるケースもあればタイムアウトでちゃんと応答が返ってこないとか、返ってきても6秒かかってるとか。ちょっと不安定。

一番最後の実行結果は、作ったタイムアウトになった2万セッションがDBに残ってる状態で新規アクセスしたときのですが、期限切れセッションを取得して削除処理が入ってるので52秒かかってます。これ他にアクセスが無い状態での結果なので…

同時アクセスがそんなになく、ユーザー数も少ないようなケース、もしくは多少応答が遅くなってもいいケースでは簡単に使えるので便利ですね。
DB側のチューニングでもう少し改善しそうですけど、あまり詳しくないので触れないでおきます。

まぁなんというか、このエントリそのものはあまり役に立たない内容でしたが、捨てるのもあれなので晒してみました。恥じらいとたくし上げ。