Softの最近のブログ記事

できないと嘆いていたのだけど、昨日の列車移動中、Windows Server 2008 R2の本を読んでいて、ドメイン環境じゃない場合は、DCOM設定を弄る必要があるとかいう記述を発見。

そうか、何かまだ必要なんだな。

というわけで、検索すると引っかかったのはこのページ。

DCOM設定(リモートクライアント側)と、winrm(サーバ側)の設定をすると、仮想マシンの一覧、出てくるじゃないですか!
歓喜。

ところが、これが、実に不安定。
ちゃんと表示できたのは、同一サブネットからのアクセスで、サーバ再起動直後のみ。
安定するまでしばらく様子見。
内部にドメインつくっちゃえばいいのかなぁ。

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

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

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

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

Hyper-V Server 2008 R2のインストール試行メモ。

• VHDブート可能(2008 R2コアだから当たり前)
• そんなに必要ないはずなのに、パーティションサイズに5GBほど要求される
• インストール中のコマンドプロンプトでキーアサインが英語

気になったのはそのくらい。

VirtualPC上のとあるXP。

デュアルコアだから倍速？

こんなのってはじめて。

そういや、x64CPU使うとx86Dualとして動作するとか広報したOSってあったよな～

休眠中のT61をどうにかしてHyper-Vサーバ化したいと思っていた。
できればServerCoreで。

リベンジ学習のためとか、LAN内にちょっとしたファイルサーバを設置したいとか、そういう理由はさておき、T61を活用せねば、もったいないわけだ。

ServerCoreに関しては、コンポーネント数が少なければ、攻撃を受けにくいというのは分かる。
シンプルイズベストというやつだ。
使用リソースも少なくて済む。
Hyper-Vの親パーティションにするなら確かにServerCoreはベストかも知れない。

だが、こと操作に関してはベストじゃない。

CUIで同じことができるにせよ、GUIの操作性やヘルプの充実度にはそれなりのメリットがある。

そして、ノートPCでHyper-Vを構成した際に、単体でゲストOSの画面参照ができなくなるのは、大きなデメリットだと、常々思ってきた。

smart sizing:i:1

こいつは知らんかった。

個人的に、超便利なのでメモしておく。

XGAノートをQXGAで使えるかも？

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

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

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

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

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

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

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

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

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

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

これが遅かった原因。

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

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

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

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

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

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

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

思われ・・・る・・・