2010年1月アーカイブ

そうだ、奈良へ行こう。

気付いたら、こんな状態。

なん、だと？

でかい唐揚げとしては、昨年、でからあげランチとして制覇している。

しかし、もっと東にも、やはりでかい唐揚げがあると聞き、行ってきた。

何が起きてるか分からんけど、どうやら、IISワーカープロセスが無応答になるらしい。

ワーカープロセス数を増やせば、ある程度抑制できるが、・・・

やはり、: Stream, IHttpModuleってのがマズイのかも。
と、思って、分離したんだけど、やはりダメ。

だって紙なんだもん。

ちゃんとしてても、さすがに何年も使ってると、手垢か湿気か知らんけど、縁が黒ずんでどうも格好悪い。
おまけに、印刷も掠れ薄れてきたし、今後も使い続けるものならば、何とかせねば。

前々から思っていたのだけれど、やっと決意。

仮に再発行を受けたとしても、対策方法が無いのでは、同じことの繰り返し。
そんなんじゃダメだ。

紙媒体を長持ちさせるには、一番の敵である水分から守るため、ビニール系のもので密封するのが一番。

ラミネーターだ!!

いや、発覚したからといってすぐに改修するわけではないが。

「/」へアクセスすると、何らかの既定ドキュメントを返すのはWWWサーバなら大抵持っている機能だけれど、IIS7.5ではどうやらモジュールがこの役割をしている・・・らしい。
＃そんな名前のモジュールが見えるよね。

で、これ、リダイレクトをさせるのではなく、また、ハンドラのように、自分で何か取ってくるわけでもなく、モジュール内でリクエストを繰り返しているっぽいんですよ。

詳しく調査したわけじゃないから、違うかも知れないけど。

ってか、もう少し早く気付けよってことで。

モジュールで受け取れるリクエスト情報にはクライアントのIPアドレスとそのホスト名があるんだけど、これ通常どちらも同じ情報が含まれている、というか、名前解決のコスト削減ってことなんだけどね。

だから、IPアドレスからホスト名を引っ張ってくる処理を入れてたわけ。

これが遅かった原因。

ログ書きをスレッド化したんだけど、そのスレッドに渡す変数(クラス)オブジェクトを構築する際にDNS引いてたから遅かった。

ログ書きスレッド内でDNS参照を行うよう変更したら、嘘のように軽くなった。
マジで、嘘みたいに軽い。

実際、カウント数集計と、レコード書き込みはどっちが先に行われているかは分からないけれど、あまり気にすることはない。

これなら、twitterの内容埋め込みもできそうな感じ・・・
＃twitter内容を定期的にローカルへ蓄えておく必要がありそうですが。

レスポンスのContent-Typeとステータスから条件判断してから、DBへのLog書きをThreadPoolに委託、フィルタチェイン構成となるよう、モジュールイベントを構成したんだけど、やはり遅い。
＃少しは改善したような気がしなくもないけれど。

さらにDB処理を削っても遅いため、恐らくDB処理は無関係だと思われる。

ならば、残りのフィルタStream自体が問題と思われる。

思われ・・・る・・・

このブログにカウンタを付けてみようかと思っていた。

普通はカウンタって、たとえば、imgタグで動的に画像を返すとか、JavaScript使ったりすると思うんだけど、それは、再リクエストを期待しないと無効なわけだし、レスポンスを返す時点でカウンタ値は決まっているわけで、いろいろと無駄があると常々思っていた。

たとえ、レスポンス一発であっても、CGI使うとか、サーバサイドインクルードとか、静的コンテンツには不向きだったりする。

前記事のとおり、IISならフィルタでレスポンス書き換えできるので、これでやってみようと思ったわけ。

.NET Frameworkでは、IHttpModuleを実装すると、IISを通過するリクエストやレスポンスを操作できるモジュールを作成できます。

たとえば、リクエストに合わせてレスポンス内容を変化させるなんてことも・・・
そう、いつも通り簡単にできるだろうと思っていました。

HttpResponse.OutputStreamの中にはレスポンスコンテンツが蓄えられるはずです。
これを読み取って、書き換えてしまえばよい、そう思っていました・・・