Hobby::.NETの最近のブログ記事

前の10件 1  2  3  4  5  6  7

カウンタ少々変更

| コメント(0) | トラックバック(0)

このサイトのカウンタは、IIS用マネージモジュールを使用している。
IHttpModuleを実装し、text/htmlで200レスポンスの場合だけカウンタログに入れて、クローラーかどうかを判断しつつ、カウンタログを書きだしているのは既出のとおり。

でも、どう考えてもクローラーっぽいアクセスログがあるんだけど、排除する判断が難しい。
判断が難しいのは、情報不足の気がしている。

そこで、リクエストメソッドとその他ヘッダも一緒に書きだせるように、データベーステーブルを拡張。
併せてモジュールも変更。
表示も少し変えて、過去24時間内のアクセスも併記できるようにした。

しばらくまた様子を見ることにする。

プロセス情報を操作する時例外出る場合があるようなので抑制。
ダウンロード

#そうそう、しきい値10000ってのは結構妥当っぽい(http://technet.microsoft.com/ja-jp/windows/ee787049.aspx)のでそのまま。
##曰く、「特定の時点で 1 万個を超えるハンドルを開いているプロセスは設計がよくないか、ハンドル リークが発生しているかのいずれかである~」だそうな。

当然、まだ回答は無い。

「いましばらく」という言葉は使用者や受け手、場面により、その示すであろう期間が異なる曖昧な言葉であるため、回答で使用すべきじゃないよな。

「○日までに再度ご連絡致します」って書けば、その日までは待とうと思うじゃん。

だめだよ、あの会社。

激しく表示制御をすると落ちるのは、タスクバー表示制御で何らかの問題が発生するからのようだということで、少し修正。

で、ドライバ側にも問題があるのか知らんけど、SEG CLIPの終了に失敗する場合がある。
そのときは、処理を中断する。
#本当にどうにかしろっつうの>IO。

で、そうなっちまった時にはデバイスを抜いて再挿入すれば、復活するっぽい。
手作業ウザし。

合法ダウンロードはこちらから。
書き忘れてたけど動作確認はXPのみ。
要.NET Framework 3.5。

記事へのIOデータからのアクセスを確認!
その後の、リファラ無しの石川県(*.infoweb.ne.jp)からのアクセスも、無関係ではないだろうと思いつつ。

既出の対策ツール、ウィンドウをそのまま出してるのもどうかと思ったので、タスクトレイに入れてみた。
単なる監視だけでタスクバーを圧迫するのもどうかと思ったし。

ダウンロードしたけりゃすればいいじゃない!

タスクトレイのアイコンをクリックするとウィンドウ表示・非表示されるはず。
#初期値の設定が難しいので、最初のクリックがノーカウントになるようですが。
#あと、あまり激しくクリックすると、落ちるようなので、注意。

終了はウィンドウを[X]で終了するか、タスクトレイアイコンを右クリックして「終了」。

最小化で隠す処理は未実装。

そんなことより、しきい値を変更できるようにしたほうがいいかもね。
#予約録画時抑制もできればいいんだけど。

ハンドルリークを仕様とか言っちゃうダメなサポートのある会社の続き。
#もう、伏せない。

サポートがダメだから、個人的に何とかしないとならん。
「ハンドルリークは仕様だから適宜再起動してください」では、何のサポートにもなっていないことを、IOデータは自覚すべき。
#ま、自覚できてりゃもう少しマシな回答するんだろうけどな。

と、言ってもはじまらん。

とりあえず、再起動しないわけにはいかない。
しかし、いちいち、ハンドルカウントを確認して、再起動するのは面倒この上ない。

カウンタフィルタ不調?

| コメント(0)

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

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

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

二重カウント発覚

| コメント(0) | トラックバック(0)

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

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

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

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

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

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

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

これが遅かった原因。

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

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

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

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

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

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

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

思われ・・・る・・・

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

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

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

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

前の10件 1  2  3  4  5  6  7

サイトカウンタ

Total: 211,632 Hits, (Recent24Hours: 0 Hits)
~ Since 2010/01 ~

埋め込みツイッター

取得失敗;;
Now: 2019/03/19 19:47:32 JST

このアーカイブについて

このページには、過去に書かれたブログ記事のうちHobby::.NETカテゴリに属しているものが含まれています。

次のカテゴリはHobby::C++です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

2019年3月

 日   月   火   水   木   金   土 
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

埋め込みQRコード