netter さんの CGIの動作が遅くなる件、結局未解決で終わりました。
現象としては、AN HTTPD 起動後CGIの動作が遅くなるというもので、初期に0.3秒程度であったものが1週間で1.0秒程度になります。
WindowsNT 4.0 sp6a でメモリは 512MB です。
確認したことは以下の通りです。
（1）サービス、常駐ソフトをすべて停止： 変化なし。
（2）Perl を 5.8 から 5.6 へ： 変化なし。
（3）クリーンインストール(WindowsNT再インストール、＋sp6a、＋ドライバ）： 1週間で0.5秒程度であるが、確実に遅くなっていく。
（4）メモリを 512MBから 256MBへ： 最初と同じペースで遅くなる。
（5）「めもりーくりーなー」でメモリクリーンを実施： 効果なし。
（3）でやや遅くなるペースが下がりましたが、AN HTTPD へのアクセス数が少なかったことによるものと思われ、遅くなることには変わりないと判断しました。
というわけで、残念ながら原因は不明のまま終わりました。
netter さん、
ログのオプションで、「プロセス」と「トレース」にチェックを入れて、counter7.cgi へのアクセスをlocalhostとLAN内から何回かやって、その時にできた process.log と trace.log をメールで送ってください。
中田さん、
メールを送りましたのでよろしくお願いします。
メールにも詳しいことは書きましたが、
他の人に誤解される可能性があるので一応簡単に説明しておきます。
>HP自体は多くの人に見てもらいたいはずですし、
>別にやましいことをしているわけではないので、
私のホームページの場合、扱っている人が少ないというか、特殊というか、
悪いことややましいことを扱っている訳ではないのですが、
バカにしてくるような人が実際にいます。
私のホームページに限らず同じ内容を扱っている他の人のホームページでも同様です。
なので、私の場合、多くの人に見てほしいのはもちろんなのですが、
どんな考えの人でも誰にでも見てほしいホームページではないので、
あまり知られたくありません。
>完全に秘密にしておく方が難しいと思った方がよいと思います。
あえて検索ロボット拒否もしていませんし、インターネット上で普通に公開している訳ですから、
もちろん完全に秘密にするのは難しいと思いますし、その必要もないと思います。
私のホームページで扱っている内容に興味がない人にはなるべく見てほしくないだけです。
netter さん、
netter さんのアドレスを知ろうと思えば知ることは可能です。私もメールで知ったわけではありません。
HP自体は多くの人に見てもらいたいはずですし、一時とはいえ自分の掲示板に関連したことを自分で書いたりしているのですから、完全に秘密にしておく方が難しいと思った方がよいと思います。
それに、別にやましいことをしているわけではないので、アドレスを秘密にする必要もないでしょう。しかしもちろん私から公にすることはありません。
それはともかく、タスクマネージャのメールは送ってくれましたか？
メールを確認したら、次にやってもらいたいことがあります。
netterさん
ご回答ありがとうございます。
そうでしたか、そう言うことがあったのですね。
不躾な質問失礼致しましたm(_ _)m
じぇ〜むすさん、
なんとなく抵抗があるだけです。
まだ私がインターネット初心者だったころ、
悪い人にいたずら（いやがらせ）目的で個人情報を流されてひどい目にあった経験があるので、
それで極端に心配するようになっているのかもしれません。
（中田さんにメールを送っている時点でIPアドレスはバレバレですがw）
IPアドレスやHPアドレスも含め公開は困りますが、
どうしても隠したいプロセス（多分1つ）だけ隠してもよいのでしたら中田さんのみに送付します。
中田さん、
十分ご理解いただいていると思うので大丈夫だとは思うのですが、
IPアドレスやHPアドレスは秘密厳守でお願いします。
HPを特定、またはある程度絞り込めるような情報（取り扱い内容など）も秘密でお願いします。
「調査に協力する」などという人がいても教えないでください。
（「そんなこと分かってるよ！」と怒られそうな気もw 一応念のためですw）
ここの掲示板はIPアドレスがログに残るのかどうかは知りませんが、
IPアドレスが完全に知られるのを承知の上で中田さんにメールを送ったのは
中田さんを信用しているからです。よろしくお願いします。
netter さん
今までの流れの中で、少し(?)本題とはずれてしまうかも知れませんが、疑問に思ったことがあるので、宜しければお答え願えると非常に助かります。
netterさんは、タスクマネージャのスクリーンショットを頑なに控えているようですが、スクリーンショットの公開になにか問題(心配?)があるのでしょうか？
それとも、ただ単にスクリーンショットを公開することになんとなく抵抗(嫌?)があるのでしょうか？
# できれば、そのなんとなくの理由を知りたいです。
私的な話ですが、文章だけより、スクリーンショットを公開することで、問題解決の糸口はグッとつかみ易く、設定違い等の問題も早く解決できると思います。
また、サーバ機の設定や導入ソフト等は皆さん殆ど変わらないと思いますから、スクリーンショットで(私が考える)個人情報と言う個人情報は流出することもないと思いますし、もし、個人情報が書かれているなら、該当部分をペイント等のソフトで削除してあげれば良い問題ではないかと思います。
P.S.
netterさん以外の方でも宜しければ、アドバイス等頂けると、助かります。
また、本題とズレすぎている話題でしたら、すいません。
中田さん、
それで、早速自分なりに8日と21日のスクリーンショットを見比べてみました。
「あたりまえだ」などという点もあるかもしれませんが、
一応自分なりに気づいた点を書いておきます。
この他にも、質問されれば答えられる範囲で答えるようにします。
・プロセスが1つ減っている
8日にはrpcss.exeという、CPU時間0:00:00、メモリ使用量1408KBのプロセスがあったのに、21日にはなくなっていました。
・ほとんどのプロセスのCPU時間が増えている
System Idle Processだけ見ても、8日には240:44:15、21日にでは258:56:24になっていました。0:00:00のプロセスでは比較できませんが、ほとんどのプロセスのCPU時間が増えており、変化の小さいものもありますが、httpd.exeは0:01:09から0:06:33になっていました。
・httpd.exeだけメモリ使用量が増えている
まったく変わらないプロセスもあれば、少しだけ増えたり減ったりしているプロセスもありますが、httpd.exeは、起動直後の覚えでは3600KB程度、8日には5660KB、21日には6592KBと、少しずつですが確実に増えていっています。
・全体のメモリ使用量はそれほど極端には変動していない
タスクマネージャの右下に表示されている数値ですが、8日には130760KB/1029228KB、21日には少しだけ減って128204KB/1029228KBとなっていました。
中田さん、
>まずは、タスクマネージャのスクリーンショットをメールで送ってください。
これなんですが、以前にも書いたとおりやはり抵抗があります。
プロセスがいくつ動いているのか、httpd.exeはどれくらいメモリを使用しているのかなど、
少しめんどうにはなってしまいますが、ここで答えていくのではだめでしょうか。
動いているプロセスは30くらいですので、
自分ですべてのプロセスを比較することくらいなら可能だと思います。
netter さん、
私の方の計測でもカウンタ単独で 11月8日 約 0.5秒、11月21日 約4秒なので、netter さんの結果と一致しています。
HP上の表示はカウンタが3つと dcw.cgi があるのですからそれだけ余計にかかって当然です。
HP上の表示が遅い原因の話は counter7.cgi が同じファイルをロックをしているということもあるので、また後にしましょう。
dprofpp の結果からいえば、AN HTTPD の処理にかかる時間が増えているということになりますね。
まずは、タスクマネージャのスクリーンショットをメールで送ってください。
中田さん、
返信遅くなりました。
計測しましたので、よろしくお願いします。
見やすいよう、一応前回計測時の結果も添えておきます。
※「秒」は、アクセスしてからカウンタが表示されるまでにかかった時間です。
11月8日の計測（AN HTTPD起動4日後）
LAN上のPC1（WindowsXP Pro SP2）
HP上のカウンタ
1秒以内
カウンタ直接アクセス
1秒以内
サーバ機（WindowsNT WS 4.0 SP6a）
HP上のカウンタ
1秒以内
カウンタ直接アクセス
1秒以内
dprofpp
Total Elapsed Time = 1.852586 Seconds
User+System Time = 0.089586 Seconds
11月10日に誤ってサーバ機の電源を落としてしまい、再起動。
11月21日の計測（AN HTTPD起動11日後）
LAN上のPC1（WindowsXP Pro SP2）
HP上のカウンタ
8秒（場合により最大20秒）
カウンタ直接アクセス
4秒
LAN上のPC2（WindowsXP Pro（SPなし））
HP上のカウンタ
8秒
カウンタ直接アクセス
4秒
サーバ機（WindowsNT WS 4.0 SP6a）
HP上のカウンタ
8秒
カウンタ直接アクセス
4秒
dprofpp
Total Elapsed Time = 2.08256 Seconds
User+System Time = 0.09956 Seconds
dprofpp以外、時計を見ながらでの計測ですので、小数点以下は切り捨てています。
LAN上のPCからは192.168.0.3、サーバ機上からは127.0.0.1でアクセスしています。
タスクマネージャのスクリーンショットは
2回分ともすべてのプロセスが写るよう2枚に分けてとってあります。
dprofppの結果は2回分ともTotal Elapsed Timeから最後までを保存してあります。
LAN上のPC2にXPのSPをあてていない以外、すべてのPCにすべての更新を適用済みです。
今までやったことがなかったために驚いたのが、
直接アクセスだと起動11日後でも4秒程度で表示されていることです。
（それでも遅いですが）
HP上のカウンタの表示の方が直接アクセスと比べて極端に遅いのは、
（勝手な根拠のない推測ですが、）
おそらくアクセス解析CGIも遅くなり、それが影響しているものと思われます。
あと、一つのページで「合計」「今日」「昨日」と3つ同じCGIからカウンタを表示しているので、
それの影響もあるのかもしれません。
計測結果は3つのうち一番最初に表示されたカウンタの結果です。
HP自体少し重くなっているので、すべての読み込みが終わり安定してからアクセスして計測しています。
LAN上のPC1だけ20秒程度かかってしまうことがあるのはSP2の影響でしょうか・・・
今月WindowsをクリーンインストールしたばかりなのでOSが壊れているということはないと思いますが・・・
調査が終わるまで、
AN HTTPDがフリーズしたり、誤ってサーバ機の電源を落としてしまったりしない以上、
この遅くなった状態のままにしておきます。
鷹の巣さん、
dprofpp は、Perlスクリプトの処理時間を示すものだから使うのです。
つまり WebサーバのCGIの応答トータルの時間からPerlの処理時間を引いて、WebサーバのCGI処理時間を見積もるためです。
最近、dprofppなるマニアックなBATコマンドが掲示板に書かれていますので、ActivePerlにおけるdprofpp.batの挙動について、検証して見ました。
●実験環境
Intel Celeron プロセッサ 797MHz 248MB RAMのノートパソコン（クライアント機）
ハードディスクの転送モードは、ウルトラDMAモード4
時間がないので、ハードディスクの回転数やハードディスク側のバッファ容量やシーク速度は未調査。
WindowsXP Home Edition Version 2002 Service Pack 2
ActivePerl v5.8.4 built for MSWin32-x86-multi-thread
Webサーバは未起動。
CGIは、http://sakaguch.com/cgi/bbs/index.cgiに設置しているperlのスクリプトで、文字コードは、utf-8nに改造。
管理者権限で実行し、Shellは、cmd.exe
＃ コマンドプロンプト画面より「SET comspec」を実行した結果は、「ComSpec=C:\WINDOWS\system32\cmd.exe」と表示されました。
index.cgiにあるディレクトリに移動して、dprofpp.batを実行しました。
●実験結果
(1)dprofpp.bat -p index.cgi の1回目の実行結果
Total Elapsed Time = 3.121478 Seconds 、User+System Time = 0.607478 Seconds
(2)dprofpp.bat -p index.cgi > bbs.txtの1回目の実行結果
Total Elapsed Time = 0.487777 Seconds 、User+System Time = 0.477777 Seconds
(3)dprofpp.bat -p index.cgi の2回目の実行結果
Total Elapsed Time = 2.069771 Seconds 、User+System Time = 0.457771 Seconds
(4)dprofpp.bat -p index.cgi > bbs.txtの2回目の実行結果
Total Elapsed Time = 0.49807 Seconds 、User+System Time = 0.49807 Seconds
●実験結果から解ったこと。
(a)Webサーバは未起動だったので、dprofpp.batは、Webサーバを通したCGIの処理時間を示すものではなく、単にperlスクリプトの処理時間を示している。
(b)User+System Timeは、perlスクリプトの処理時間（perlスクリプト内でのファイル入出力時間も含む）を示している。
(c)User+System Timeは、perlスクリプトの処理データ(逆引き出来ないIPアドレスの存在等)と処理内容(プロキシ判定やメールアドレスの実在検査等)によっては、非常に大きく(10秒以上)なり得る。
(d)Total Elapsed Timeは、perlスクリプトの処理時間以外にスクリプト実行前処理時間とShellの標準出力（画面表示出力）時間も含む。
(e)bbs.txtにリダイレクト（転送）した場合は、Total Elapsed Timeにスクリプト実行前処理時間と出力結果をファイルに書き出す時間が含まれる。
(f)初回以降の実行を行うと、一度ファイルの入出力を行っているためか、処理時間が短くなる傾向がある。
(g)サーバ機側のCGI応答時間を見る場合は、最初の(2)のdprofpp.bat -p index.cgi > bbs.txtの実行結果のTotal Elapsed Timeの箇所を見た方が良いと考えます。
何故なら、スクリプトの実行結果を表示したり、レンダリング（描画）するのは、クライアント機の仕事だからです。
しつこい様ですが、(1)のdprofpp.bat -p index.cgiの実行結果を見ると、判断を間違う可能性があります。私も最初は、ハードディスクの転送モードが、PIOモードになっているのかなと思いました。
注）スクリプト実行前処理時間＝スクリプトファイルの読込み時間＋スクリプトのコンパイル時間
dprofpp.batのスクリプトを読めば実験なんかしなくても解るだろうと言われればそれまでですけど、一応実験して見ました。間違いがありましたら、ご指摘して頂くと嬉しいです。
蛇足ですが、counter7.cgiの様な標準出力へ出力するデータが少ない場合は、ファイルにリダイレクト（転送）しても、Total Elapsed TimeとUser+System Timeの差異は、あまりないかもしれません。掲示板の様にhtml出力するCGIの場合にその差異が大きくなると考えられます。
netter さん、
こちらからの couter7.cgi は2秒以上になりました。
localhost と LANからのアクセスを計測してみてください。
それから、
dprofpp -p counter7.cgi
を実行して結果を記録しておいてください。
また、現時点のタスクマネージャのスクリーンショットもとっておいてください。
>> WindowsXP Professional(Service Pack 2 ???)のLAN内のクライアント機のブラウザから、
>> http://192.168.0.3/cgi-bin/counter7/counter7.cgi?total
>> でアクセスしても判断を間違う可能性があると言っているだけです。
> これは、XPだから、またはSP2だから、それともLANだからでしょうか。
> （LAN上からの確認に使用しているPCはWindowsXP Pro SP2です）
> 中田さんからこのようにブラウザから確認するよう言われているのでしています。
WindowsXPのService Pack 2だからです。Professionalは無関係です。
2004/10/16 02:42にnetterさんが
> AN HTTPDの再起動もやってみましたが、
> Windowsを再起動したときと同じように動作が速くなりました。
と書かれているので、問題はnetterさんのサーバ機だけです。それ以外のルータやクライアント機は無関係だと推測しています。但し、netterさんの場合は、WindowsXPのService Pack 2のブラウザを使用して、アクセスしない方が良いと考えます。
後のことは、netterさんが言われていることが正しいので、中田さんのご指示を受けて実施してください。
> 追記2で書かれている内容が原因なら起動直後からある程度の遅さが感じられると思うのですが・・・
これは、良いところに気づかれましたね。但し、そんな単純なことではないと推測しています。netterさんに質問しても定量的な回答が得られないので、推測の一例を挙げますと、アクセスカウンタ等のCGIに限定した筋書きは、
(1)IPアドレスの逆引きが出来ないか処理時間のかかるCGIを実行する。
(2)カウンタ等のCGIの表示が遅い。
(3)クライアント側がアクセスを中断する。
(4)WebサーバとCGIのパイプが壊れる。WebサーバがCGIプロセスを停止できない。
(5)CGIプロセスがゾンビプロセスになる。
(6)長く運用すると、上記のゾンビプロセスが増えてくる。
(7)その結果、Webサーバの応答が遅くなってきたり、最終的には全く応答しなくなる。
他のサイトでしたら、一日で全く応答しなくなる場合が、netterさんのサイトでは、アクセス数が少ない（失礼）ので、そこに行き着くまでに日数を要しているだけかもしれません。
>> http://sakaguch.com/img/Taskmgr/Taskmgr20020915.png
> 参考になります。プロセス数はだいたい私も同じくらいです。
時間がなくて説明不足でした。上記の画面は、2002年9月15日時点の
環境：windows2000 Professional、perl(ActivePerl-5.6.1.633-MSWin32-x86.msi)、AN HTTPD 1.40d
メモリ：主記憶256MB、仮想記憶（ページングファイルサイズ）384MB
です。あくまでタスクマネージャの参考画面として下さい。比較して頂いても何の意味もありません。蛇足ですが、上記のプロセス数と同じくらいでしたら、安定運用は無理かもしれません。もっと少なく出来るはずです。
netterさんへの投稿は、これで終了します。自宅サーバ頑張って下さいね。
いとさん、
>お使いのファイアウォールソフトは何でしょうか？
SygateのFWの最新版です。
これも使っている人はかなり多いので、関係ないと思いますが・・・
以前、AN HTTPD以外のすべての常駐ソフト、サービスを停止させて実験したことがあるので、
たぶん他のソフトは関係ないと思いますが、
実験したのがちょっと前で、そのときはCGIの動作がなんとなく遅い気がしたためにやっただけで、
しかも速度に変化があるかどうかを調べるためだけの短時間の実験だったので、
中田さんから再び同じような実験を長期間にわたり行うよう言われればもう一度やりますが・・・
できればウイルス対策やFWは長い間とめたくないですよねw
netterさん
> 私はNTなのでファイアウォールは付属していなく、
> 海外のフリーソフトで、アプリケーション許可できる他、
> CodeRedウイルスなどの接続を検出して、
> 許可されているアプリケーションでも
> 拒否したりしてくれるものを使っています。
お使いのファイアウォールソフトは何でしょうか？
もし Outpostだとすると以下のような報告もありました。
http://homepage1.nifty.com/yito/namazu/gbook/20031015.0954.html
Outpostを使っているほとんどの人は問題なく使えているでしょうから
外しているとは思いますが。
>WindowsXP Professional(Service Pack 2 ???)のLAN内のクライアント機のブラウザから、
>http://192.168.0.3/cgi-bin/counter7/counter7.cgi?total
>でアクセスしても判断を間違う可能性があると言っているだけです。
これは、XPだから、またはSP2だから、それともLANだからでしょうか。
（LAN上からの確認に使用しているPCはWindowsXP Pro SP2です）
中田さんからこのようにブラウザから確認するよう言われているのでしています。
>中田さんに負担をかけずにご自身で出来ることは、ご自身でやって頂きたいのです。
>Webサーバの応答が悪くなった時点で中田さんにアクセスして見て頂けば良いのではないでしょうか。
すでに書きましたが、私が定期的な外部からの確認をお願いしたということではなく、
中田さんがやってくださっていることですので、この辺は中田さんに伝えてください。
>WebSitePulseからのデータを提示して頂く
私は中田さんに指示されたことをして報告するということをしている状態なので、
指示する人が複数いるとあとで話が厄介になりますし、
申し訳ないのですが、これは中田さんから言われたらやることにします。
>ua.logやprocess.logやisapi.logやtrace.logの全てを採取される方が良いと考えます。
現在はhttpd.logとerrors.logしかとっていませんが、
これも中田さんから言われたらやることにします。
（調べていただいている途中で勝手にいろいろやらない方がよいという考えから）
>これらのCGIは、総合的な応答が10秒を超える場合もあります。
起動直後は即表示されており、数日後に10秒以上かかるようになっています。
（cgiへの直接アクセスではなく、カウンタが表示されるページ上から確認した場合。）
（直接アクセスでは未確認。起動から1週間経過したら確認する予定です。）
追記2で書かれている内容が原因なら起動直後からある程度の遅さが感じられると思うのですが・・・
>http://sakaguch.com/img/Taskmgr/Taskmgr20020915.png
参考になります。プロセス数はだいたい私も同じくらいです。
ただ、この画面ではhttpd.exeが40000KB近くメモリを使用していますが、
私が遅くなっているときに見たときには6000KB未満でした。
バージョン、使用の仕方、HPの規模、アクセス数などによって変動するものだと思いますが、
メモリを使用しすぎて遅くなっているという訳ではないことはこの画面からも分かりました。
速度が遅くなるだけではなく、
「カウンタ画像が×印になっていて表示されない」
「（通常のページが）ページを表示できません」
「（掲示板が）検索中のページには問題があるため表示できません」
「httpd.logに記録されているIPがアクセス解析CGIで記録されていない」
という問題もあり複雑なので、中田さんに任せるしかないと思います。
（最後に書いた4つの現象は起動直後でも発生します。）
netterさんへ
> 記事を途中から読まれたのか、何か勘違いなさっているようです。
現行スレッド
http://homepage1.nifty.com/yito/namazu/gbook/20041011.0234.html
とnetterさんと非常に環境の似ているUMUさんの過去ログ
http://homepage1.nifty.com/yito/namazu/gbook/20040604.0729.html
は、読んでから投稿しました。
> その必要資料としてサーバ機上とLAN上の2種類を確認するように中田さんから言われているので、 両方確認しています。
http://127.0.0.1/cgi-bin/counter7/counter7.cgi?total
でのアクセスは良いとしても、WindowsXP Professional(Service Pack 2 ???)のLAN内のクライアント機のブラウザから、
http://192.168.0.3/cgi-bin/counter7/counter7.cgi?total
でアクセスしても判断を間違う可能性があると言っているだけです。（提示される情報は多い方が良いのですが。）
＃ ネットワーク関係のお仕事をされているということなので、Webサーバへのアクセスは、基本的にtelnetや簡単なソフト（スクリプト）を作成して行うべきです。簡易的には、WebSitePulseでも良いと考えています。
> 中田さん自身に本当に遅くなるという現象を確認していただいたほうが、
> 私が検査して「こうだった」と言うよりも信頼性も高いと思いますし・・・
netterさんがWebSitePulseからのデータを提示して頂くと、そうでもないと考えます。私がnetterさんに特に言いたいのは、中田さんに負担をかけずにご自身で出来ることは、ご自身でやって頂きたいのです。netterさんの場合は、ローカルルータのファームウェアのバージョンアップを行ったりされているので、Webサーバの応答が悪くなった時点で中田さんにアクセスして見て頂けば良いのではないでしょうか。
［追記］
1.多くても30人のご訪問者（ページビューは不明）ということですし、cgiは、perl.exeかPerlIS.dllのどちらを使用されているのかもわからないので、ログは、httpd.logやerrors.logやreferer.log以外にua.logやprocess.logやisapi.logやtrace.logの全てを採取される方が良いと考えます。
2.dprofppでCGIの処理時間の大小は判別出来てもインターネットからアクセスした場合の総合的な応答時間とは異なりますので注意が必要です。例えば、プロキシサーバ経由の投稿を防ぐCGIは、アクセス元のIPアドレスを逆引きしています。また、メールアドレスの整合性を正規表現で検査するだけではなく、メールアドレスの存在をSMTPサーバに問い合わせる様な検査を行うCGIもあるかもしれません。これらのCGIは、総合的な応答が10秒を超える場合もあります。
3.起動しているプロセスがちょっと多いですけど、私も過去にタスクマネージャの画面を提示しておりますので、ご参考まで。
http://sakaguch.com/img/Taskmgr/Taskmgr20020915.png
また、Sygate Personal Firewallの画面を提示しておりますので、ご参考まで。
http://sakaguch.com/img/Taskmgr/SygatePersonalFirewall20020917-139f.png
鷹の巣さん、
初めてサーバを立てようとしたときは鷹の巣さんのHPは大変参考になりました。
設定がよく分からなかったときも鷹の巣さんのHPをよく読んだら理解できたこともありました。
それで本題なのですが、長いやり取りになっているので仕方ないかもしれませんが、
記事を途中から読まれたのか、何か勘違いなさっているようです。
>LAN上のPC機からアクセスすると判断を間違う可能性があるので
現在中田さんが私のサーバ機上で何が起こっているのかを究明するために
いろいろと調べてくださっている途中でして、
その必要資料としてサーバ機上とLAN上の2種類を確認するように中田さんから言われているので、
両方確認しています。
LAN上からのみ遅くなるのとサーバ機上でも遅くなるのとで考えられる原因も変わってくると思いますし・・・
>それから、中田さんに外部よりWebサーバの応答時間を検査して頂かなくても、ご自身で検査されては如何でしょうか。
中田さんがインターネット経由で確認しているのは、
私が外部から確認できないからお願いしたということではなく、
中田さんが、インターネット上からでも同じほど遅いのか、そもそも本当に遅くなるのか、
netter（私）が使っているPCがおかしいだけなのではないか、
その辺を確認してくださっているのだと思います。
中田さん自身に本当に遅くなるという現象を確認していただいたほうが、
私が検査して「こうだった」と言うよりも信頼性も高いと思いますし・・・
中田さんの話によれば今回のような現象の報告は初めてだとのことですので、
1つずつ中田さんの質問に答えていき、調べていただいています。
起動してから1週間待たないと現象を確認できず、この前誤ってサーバ機の電源を落としてしまったので、
まだきちんと現象確認すらできていない状態です。
過去ログのどこかに残っていると思いますが、
以前自分で計測したときは、現在即表示されているアクセスカウンタが、
起動数日後には表示されるまでに10秒以上かかっていました。
ただ遅いだけではなくエラーでページが表示されないようなこともあり、
私1人で解決できるような問題ではないので、
最終的に結局解決できないかもしれないということを私が同意した上で、
中田さんに調べていただいています。
netter netter@hotmail.com 2004/11/11 23:26 さんへ
> もちろん、いつもどおり時計を見ながら表示までに何秒かかるのかを計るつもりでしたが。
> サーバ機上とLAN上のPCで。
netterさんの場合は、LAN上のPC機からアクセスすると判断を間違う可能性があるので、サーバ機上のブラウザから、自己診断用IPアドレスを使用して、
http://127.0.0.1/
でアクセスするだけの方が良いと考えます。
それから、中田さんに外部よりWebサーバの応答時間を検査して頂かなくても、ご自身で検査されては如何でしょうか。
下記にご自身でインターネットからWebサーバの応答時間を測定する方法の一例を示します。
URLを公開出来ないのでしたら、測定値だけでも明示して、この掲示板にご投稿されることを推奨します。
------------------------------------------------------------
インターネットからWebサーバの応答時間を測定する方法の一例
Web server & web site monitoring services by WebSitePulse
http://www.websitepulse.com//tools.php3
の一番上の入力窓(WebSite Test)に「http://netterさんのグローバルアドレス/」と入力すると、netterさんのWebサーバの応答時間が「Response time: ?.???? seconds」と表示されます。
※ 用法と使用上の注意事項
(1)「http://netterさんのホスト名/」と入力すると、DNSサーバの応答時間が加算されてしまいますので、注意して下さい。
(2)WebSitePulseさんのサイトも混んでいる可能性がありますし、Webクライアントは、telnetモドキのCGIですから、5回程測定して、最小値と平均値と最大値辺りを掌握した方が良いと考えます。
(3)念のために、WebSitePulseの下から二番目の入力窓(Traceroute)に「グローバルアドレス」を入力して、WebSitePulseからnetterさんのWebサーバまでのルータの応答時間とハケットの通信時間を測定しておいてください。多分、この時間はWebサーバの応答時間に含まれていると考えるからです。
(4)真のWebサーバの応答時間＝(1)のWebサーバの応答時間 − (3)のRound-trip times
------------------------------------------------------------
中田さんへ
上記の方法でも、Webサーバの応答時間がだんだん長くなっていくという検証が出来るのではないでしょうか？
>どうやって「計測」するつもりだったのでしょうか？
もちろん、いつもどおり時計を見ながら表示までに何秒かかるのかを計るつもりでしたが。
サーバ機上とLAN上のPCで。
実際計らないと、見た目で「だいたい何秒くらい」とか言うと、
遅さにイラついているせいですごくかかっているような気がするだけのときとかありますし。
ということで、また1週間お待たせしてしまうことになって本当に申し訳ないのですが、
ひきつづき電源を落とさないよう要注意しますので、よろしくお願いします。
（AN HTTPDがフリーズするとまたやり直しですが・・・）
それはともかく、
＞日付が10日に変わる少し前頃、結構重くなっていたのを確認しましたが、計測はしませんでした。
とのことですが、どうやって「計測」するつもりだったのでしょうか？
dprofpp による計測では意味がないことはわかっていますよね？
（これには回答してくださいね）
中田さん、
話せば長いのですが、
ルータが突然指定ポートへのアクセスを指定IPアドレスへ回さなくなったので、
ルータはものによっては熱によっておかしくなるものがあると聞いたことがあるのを思い出し、
今までずっとつけっぱなしだったルータの電源をひさしぶりに落として少し休ませてみようと、
ルータにスイッチがないために電源タップのスイッチを切ったのですが、
このタップ、5つスイッチがあり、1つのスイッチが2つのコンセント差込口に対応しているというかなり変わったタイプで、
その切ったスイッチに対応していたもう一つのコンセント差込口にサーバ機のコンセントが！
つまり、簡潔に言うと、誤ってサーバ機の電源を落としてしまいました。すみません。
日付が10日に変わる少し前頃、結構重くなっていたのを確認しましたが、計測はしませんでした。
そろそろ計測して報告しようとしていたのですが・・・
本当に申し訳ないのですが、もう1週間待っていただけないでしょうか。
結局、ルータは休ませた後も回復せず、工場出荷時の状態へのリセット、ファームの再インストール、
WindowsXP SP2のファイアウォールの無効化などを行ったのですが、
LAN上の別のPCからはアクセスでき、インターネット上からのみアクセスできないので、PC上のファイアウォールは関係なく、ルータの異常だと思い込んでいろいろいじっていたのですが、
最終的に、Windowsをシステムの復元を実行して1日前の状態に戻したら解決しました。
おそらく、SP2のファイアウォールの辺が暴走してLAN上以外からのすべての受信を拒否していたのだと思いますが、
今日はほとんどPCをいじっていないのになぜ勝手に壊れたのでしょう・・・
最後の方はAN HTTPDとはまったく関係ない話になってしまいましたがw
netter さん、
counter7.cgi のこちらでの応答時間は、
11月7日 11時 約 0.5 秒
11月8日 21時 約 0.8 秒
11月9日 21時 約 1.0 秒
という経過です。
http://127.0.0.1/cgi-bin/counter7/counter7.cgi はどうですか？
netter さん、
こちらからの時間計測では、0.2秒から0.3秒遅くなっています。
もう少し遅くなってから、いろいろ調べることにしましょう。
dprofpp については、'n' が抜けていましたね。失礼しました。
とりあえず Total Elapsed Time 以下を記録しているのならそれでかまいません。
「文字化け」とか「縮めて実行」とかいうのはまたまたとんでもない誤解なのですが、これも説明は後回しにします。
「表示できません」になるとかいろいろおかしいのは、以前にも書いた通りでこちらでも確認しています。
とりあえず「遅くなる」話と関係はないと思っていますが、関係しているかもしれないので私の頭には入れてありますのでご心配なく。
S さん、ronson さん、
ご心配いただきありがとうございます。
何かがわかっていない場合、その何かがわかっていないのですから、自分がわかっていないことの自覚がないのはやむをえないと思っています。
ちょっと書き間違えました。
>とエラー表示されるのは確認できたでしょうか。
は正しくは、
>とエラー表示されることがあるのは確認できたでしょうか。
です。前の発言だと1回目のアクセスだと必ず起こるように思えますよね。
ごくまれにしか起こりません。
1番多いのはカウンタ、2番目は掲示板、
めったに起こらないがたまに起こるのはページの表示です。
中田さん、
11月8日に入り、まもなく起動から4日間が経過しようとしており、
若干遅くなってきたような気もする（まだ気のせいだとも思える程度）のですが、
午前2時頃、最初のスクリーンショットをとりました。
すべてのプロセスが写るように2枚に分けてとりました。
>dprofpp -p couter7.cgi > counter7.prof.1106
コマンドプロンプトを起動し、
counter7.cgiが置かれているディレクトリまで移動してこのまま貼り付けたのですが、
なぜかエラーが出るのでよく見たら、コピーした中田さんの発言、nが抜けていましたw
それでnを挿入してもう一度やってみたのですが、なぜか「counter7.cgiを開けません（実際は英語表示）」
と表示されてできません。
dprofpp -p counter7.cgiと縮めて実行してみたところ、文字化けした文字がビープ音と共に大量に流れました。
最後の部分だけ文字化けしていなかったので、とりあえずその部分だけをコピーしてテキスト保存したのですが、
この情報だけで大丈夫でしょうか。
文字化けしていなかった、保存した部分は、Total Elapsed Timeのところから最後までです。
他は文字化けしていて解読不能です。
あと、直接アクセスだと確認できないのかもしれませんが、
リンクから別のページを表示したときに「ページを表示できません」、
カウンタが表示されるページのカウンタ画像の部分が×表示、
リンクから掲示板にアクセスすると「検索中のページには問題があるため表示できません」
とエラー表示されるのは確認できたでしょうか。
カウンタ以外はもう一度アクセスし直すとたいてい表示され、
カウンタも何回かアクセスし直すと表示されるのですが・・・
ronsonさん、
>有用な情報をくださる方もいらっしゃるかもしれませんから、
>そう突き放さずにいきましょう。
そうですね。
途中から入ってきて明らかに勘違いしている人や明らかにけんかを売っているような書き方の人に対してのみ、
私が返信しても余計に荒れるだけで他の人の迷惑になるだけだと思いますので、返信を控えるようにします。
netterさん
＞スクリーンショットをとっても、あとでそれを見せてほしいとか、
＞何が動いているのかすべて教えてほしいとか言われてもむずかしい
そういう場合はメールに添付して送信してくれと中田さんも
おっしゃると思いますから、大丈夫だと思いますよ。
＞以降中田さん以外から返信があっても答えないようにします
有用な情報をくださる方もいらっしゃるかもしれませんから、
そう突き放さずにいきましょう。
>ちゃんと読んで理解してから受け答えをしたほうが
>問題の解決が少しでも早まるかもしれませんよ
私の書き方が悪かったようで、すみません。
スクリーンショットをとっても、あとでそれを見せてほしいとか、
何が動いているのかすべて教えてほしいとか言われてもむずかしいということが言いたかっただけです。
自分ではとっておきます。
Sさん、
>作者に自分の環境での解決を強いるやり方は見ていて不快感を感じます。
強いていません。今までのやりとりをすべて読んでから言ってください。
NT未対応ならあきらめるとも書きましたし、
未対応でなくても自分の環境で正常に動いていないのは事実、他のソフトを使うことも困難なので、
あきらめてタスクスケジューラで再起動させながら使うとも書きました。
そこを中田さんがだめもとでも調べてくださると言ってくださったので、調べていただいている途中なんです。
>netterさんはここでどんな参加をしているのでしょう。
NTに対応しているのかいないのか、私だけの例からでは「絶対にNT未対応だ」とは言い切れないと思いますが、
今回中田さんがいろいろ調べてくださっているおかげでどうしても解決できなければその可能性は高くなると思います。
もしNTで正常に動いているという人がいたとしても、正常に動いていない人もいるという情報にはなりますし、
「このソフトと一緒に使うと不安定になる」というような結果が出るのかもしれません。
そのような意味ではAN HTTPDの今後のための参加をしていることになると思いますが。
>手持ちの機器やOSが１種類ではないでしょうから，せめてOSはNTだけしか試せないと頑強に言い張るのではなく，
>他の機器やOSでも試してみますという姿勢を見たいものです。
長いやりとりを全部読んでいないようで、勘違いされているようです。
XPで試したときは問題なかったと以前書きましたが。
NTではすでに2台で同様の現象が確認されていますし。
XPとNTしか持っていないのでこれ以上試せません。
>そう考えると，PC知識や問題解決方法をうんぬんする前に，まず人とのコミュニケーションの取り方を学ぶ方が先のように感じます。
このような書き方をすれば相手を怒らせ、掲示板が荒れるだけだということに気づかないでしょうか。
あちらの掲示板で不快な思いをしたからと言って他のサイトにまで迷惑をかけないでください。
途中から入ってきて何か勘違いされていると無駄に荒れるので、
ここは一番今までの話を分かっている中田さんに任せるべきだと思います。
荒れると他の人にも迷惑なので、これ以降中田さん以外から返信があっても答えないようにします。
netter 2004/11/07 21:36 さん
＞やはり他人に知られるのには抵抗があります
中田さんは以下のようにおっしゃっています。
「別にそれをここに出せと言っているわけではありません」
ちゃんと読んで理解してから受け答えをしたほうが
問題の解決が少しでも早まるかもしれませんよ
中田さん、
>タスクマネージャの画面は全部のプロセスが表示されていなければ意味がありません。
やはり他人に知られるのには抵抗があります。
自分で見た限り、変なプログラムは動いていませんし、問題ないと思うのですが。
現在動いているプロセスの数や、他にどんなソフトをインストールしているのか、
あと、現在のAN HTTPDの使用しているメモリ容量、これだけなら教えられます。
まだWindowsを再インストールして1ヶ月と少しですし、
サーバ専用機のため他の用途には使用していないので、
変なプログラムが勝手に入ったりはしていないはずですが・・・
自分でタスクマネージャを見た限りでは問題なさそうですし・・・
>それから、遅くなった時に勝手に AN HTTPD を再起動しないようにしてくださいね。
原因を究明できるように遅くなるのを待っているので、究明、もしくはあきらめられるまでは再起動しません。
ただ、以前にも書いたとおり、たまにAN HTTPDがアクセスを受信中になったままフリーズしていることがあるので、
そうなったら仕方ないので再起動します。
netterさんと中田さんのやりとりについて，傍観していればいいのでしょうが，中田さんの対応のていねいさに驚くと共に，netterさんの思いこみの激しさにも驚きます。
作者に自分の環境での解決を強いるやり方は見ていて不快感を感じます。むこうの掲示板でも回答者を不快にさせていましたね。
Free版はその開発に参加できるところが魅力です。そのコミュニティから先人たちの智恵を授かることのできるところが魅力です。netterさんはここでどんな参加をしているのでしょう。手持ちの機器やOSが1種類ではないでしょうから，せめてOSはNTだけしか試せないと頑強に言い張るのではなく，他の機器やOSでも試してみますという姿勢を見たいものです。
そう考えると，PC知識や問題解決方法をうんぬんする前に，まず人とのコミュニケーションの取り方を学ぶ方が先のように感じます。
netter さん、
タスクマネージャの画面は全部のプロセスが表示されていなければ意味がありません。
別にそれをここに出せと言っているわけではありません。もちろん、netter さんが自分で比較してもわからない場合は、メールで送ってもらうことになると思いますが。
それから、遅くなった時に勝手に AN HTTPD を再起動しないようにしてくださいね。
遅くなった状態で調べることが出てくると思いますから。
中田さん、
>まだそれほど遅くなっていませんよね（？）。
>今のところ1秒で応答しています。
私の方でも、まだ1秒以内で高速に表示されているのを確認しました。（11月7日現在）
タスクスケジューラが完全に停止していなかった影響もあり、
前回起動は11月4日ですので、まだ3日目です。
5日間過ぎたあたりから遅くなって来るので、いつも通りです。
（もしかしたらアクセス数によっても多少変動するのかも）
>今のうちに一度タスクマネージャのプロセスの画面のスクリーンショットを取っておいてくれませんか？ 遅くなったときに比較するためです。
時間的に、今すぐにはできないので、今夜か明日（なるべく早く）やります。
あと、プロセスのスクリーンショットはhttpd.exeのところだけ写っていれば問題ないですよね？
何が動いているのかを他人に知られるのに少し抵抗があるものでw
（変なものは動いていませんがw）
>dprofpp -p couter7.cgi > counter7.prof.1106
>を実行しておいてください。
これも今夜か明日（なるべく早く）やります。
>c-board.cgi については、「おそらく設定変更か何かで直る問題だと思っている」というのがこれまたとんでもない誤解だと思いますが、
私の知識も完璧ではないので何かを誤解している可能性は高いですが、
あちらの掲示板を見ていただければ分かるとおり、
企業のレンタルサーバスペース上でも複数のCGIのうちC-BOARDだけが非常に遅かったので、
自分の設定が間違っているとしか今の知識では考えられません・・・
netter さん、
まだそれほど遅くなっていませんよね（？）。
私の方でも、counter7.cgi の速度を測っています（ただし1秒単位でですが）。
今のところ1秒で応答しています。
今のうちに一度タスクマネージャのプロセスの画面のスクリーンショットを取っておいてくれませんか？ 遅くなったときに比較するためです。
また、AN HTTPD のCGI処理で時間がかかっているのか、PerlのCGIスクリプトの動作の時間が増えているのか区別するために、
dprofpp -p couter7.cgi > counter7.prof.1106
を実行しておいてください。リダイレクトするファイル名は後でわかればいいのでもちろん何でもかまいません。
c-board.cgi については、「おそらく設定変更か何かで直る問題だと思っている」というのがこれまたとんでもない誤解だと思いますが、これも netter さんに理解してもらえるように説明するには結構時間がかかります。
幸い、遅くなる現象を解決するのにまだだいぶかかるでしょうから、時間がある時にまた説明したいと思います。
中田さん、
>その調子で、何がどうなっているか自分で確認していくのがよいと思います。
とりあえず、現状自分で調べられることは調べつくしたと思うので、
私としてはあとは1週間後の実験結果から中田さんに調べていただくのを待つしかありません。
他アプリケーション停止などのできる実験はすべてやりつくしたと思いますし・・・
>Apacheの誤解の件は、今の段階では背景も含めてかなりの説明が必要になるので、すみませんがちょっと待ってください。
分かりました。説明が大変そうなので、機会があって話がまとまったら教えてください。
>それより、c-board.cgi の動作が遅い原因について、あちらの掲示板で指摘されていることがどういうことなのか、もう少し考えてみてください。
あちらの掲示板で私の発言を読んでおられるのでしたら分かると思いますが、
現段階ではc-board.cgiの動作速度の遅さの原因はまったくつかめません。
また、c-board.cgiは他のCGIとは別に特別遅く、以前レンタルサーバで動かしていたときから遅いので、
AN HTTPDは関係ないと思います。（レンタルサーバはAN HTTPDではなかったですし）
おそらく設定変更か何かで直る問題だと思っていますが・・・
netter さん、
その調子で、何がどうなっているか自分で確認していくのがよいと思います。
Apacheの誤解の件は、今の段階では背景も含めてかなりの説明が必要になるので、すみませんがちょっと待ってください。
それより、c-board.cgi の動作が遅い原因について、あちらの掲示板で指摘されていることがどういうことなのか、もう少し考えてみてください。
中田さん、
AN HTTPD再起動後24時間以内の、まだAN HTTPDの動作が遅くなっていないサーバ機上で、
http://127.0.0.1/cgi-bin/counter7/counter7.cgi?total
にアクセスしてみましたが、肉眼で計測できるほどの待ち時間はなく、即表示されました。
次に、LAN上のPCから、
http://192.168.0.3/cgi-bin/counter7/counter7.cgi?total
にアクセスしてみましたが、こちらも同様です。
>別に一週間後でもかまいません。
タスクスケジューラでスケジュールを停止しました。
前回再起動時間は11月3日午前ですので、11月10日頃に再び報告します。
>Apacheの件はとんでもない誤解をしているようですが、
「とんでもない誤解」とはどういう誤解なのか、少しだけ気になるので、
それほどむずかしくなく簡単に説明できるようでしたら参考までに教えてください。
あと、実験中に気がついたのですが、
LAN上のPCからHPを閲覧するよりもサーバ機上から閲覧した方が、
本当に若干ですが、htmlやCGIの表示（動作）全体が少し速いような気がしました。
LANを経由していればいくらLANが速くても若干は遅くなるものでしょうか。
それとも、この速度の違いが後に影響してくるのでしょうか。
1週間後に再実験してみれば分かることですが・・・
netterさん、
別に一週間後でもかまいません。
ただし、netterさんのページの表示の速度ではなく、先に示したURLで単独のCGIの表示速度をみてください。
netterさんのページはいずれも複数のCGIが同時に起動されるようになっていて、必要以上に重いページなので、その問題と切り分けるためです。複数の同種のCGIが起動するとファイルアクセスの排他制御がからんでくるので、そうすると調べるところが別になるからです。
また、LANからのアクセスで同じかどうかもついでにみてください。どこに問題があるかを調べるために必要なのです。
netterさんの話では「AN HTTPD を起動したあと時間がたつとCGIの動作が遅くなる」ということだったのですが、そういうことではないのだろうと思っています。それを確かめるために、単独のCGIの動作速度を見てほしいと言っているのです。
Apacheの件はとんでもない誤解をしているようですが、いずれにしても netter さんに Apache を使うことはできないでしょうから、これについては特にコメントしません。
中田さん、
現在はタスクスケジューラを使用して毎日定時に再起動させているため、
その現象を再確認するにはタスクスケジューラを停止させて1週間程度待つ必要があります。
前にも書いたと思いますが、LAN経由で閲覧した際、起動5日後では10秒以上かかりました。
サーバ機上から127.0.0.1で試す場合、1週間程度待たないとなりませんが、
それでもよろしいですか？LAN経由でも同じだと思うのですが。
起動直後でも、カウンタが表示されるところに×が表示されて画像が表示されないこともあります。
カウンタ以外にも、アクセス解析CGIにも問題が発生していることが分かりました。
httpd.logに記録されているIPがアクセス解析では記録されていないことが非常に多いです。
おそらく解析に失敗しているものと思われます。
そう考えると、アクセスがあってもカウンタの数字も進んでいないことがあるのかも・・・
ごくたまになのですが、HPが閲覧できなくなっているときがあり、
サーバ機を見てみると、AN HTTPDがアクセスを受信中のアイコンになったままフリーズしていることがあるのですが、
これは誰でも起こる現象なのでしょうか。
AN HTTPDを再起動しないとそのまま元には戻りません。
Apacheについてもう少し調べてみたのですが（移行はむずかしいのでしません）、
Apacheも最近やっとWindowsNTに対応したそうです。
以前までは動作はするが不安定だったりして正常に動作しないためサポート対象外だったそうです。
やはりNTに完全に対応させるということはむずかしいことなのでしょうか・・・
netter さん、
最初の質問ですが、
AN HTTPD が動作しているPCで、
http://127.0.0.1/cgi-bin/counter7/counter7.cgi?total
とした場合の表示速度は AN HTTPD の再起動直後に比べて遅いですか？
遅いとしたら表示にだいたい何秒程度かかりますか？
中田さん、
設定レジストリファイルをメールで送付しましたのでよろしくお願いします。
あと、自分のHP内で特に動作が重い掲示板CGIの作者HPの掲示板で掲示板が重いことも質問してみたのですが、
（掲示板はWindows起動直後でも非常に動作が重い。時間が経つともっと重くなる。）
他の人（レンタルサーバ内で使用）は非常に高速快適に使用できているとのことでした。
やはり、自分が正常に動いていないだけだという可能性が高いようです。
他にAN HTTPDをNTで使用している人、いないですかねえ。
いらっしゃったらぜひお話をお聞きしたいのですが・・・
それでその人が正常に使用できていれば、NTは関係ないということになりますし・・・
netter さん、
了解しました。
まずは、netterさんの AN HTTPD の応答内容に不思議なところがあるので、AN HTTPD の設定内容を確認させてください。
そのために regedit で HKEY_LOCAL_MACHINE\Software\AnHttpd 以下を適当な名前のファイルに書き出して、そのファイルをメールで送ってください。
それを見た上で、いくつかの質問をさせてもらいます。
Zawaja zawaja@mx1.freemail.ne.jp 2004/10/31 19:42 さん
>脆弱性に対するパッチをキチンと入れることができ、また、
>設定ミスで外部に迷惑を掛けるようなことがないようにする設定
その通りですね。もちろん、XPのメリットを認めのご所見と思われますが…。
中田さん、
>どうして AN HTTPD を使い続けるという選択をするのかちょっと不思議です。
作者様に他人のソフトをすすめられるのは少しおどろきです。
とりあえず今は他に手段がなく、私のことを考えてくださってのことだと思うのですが、
AN HTTPDを使い続ける理由は下で説明します。
>以前の
>http://homepage1.nifty.com/yito/namazu/gbook/20040604.0729.html
>の時に、
この過去ログの場合も、やはりWindowsNTですよね？
前にも書いたと思いますが、
AN HTTPDを勉強してサーバ専用機が準備できるまでの間仮にWindowsXP機で動かしていたとき、
1〜2ヶ月ほど何も問題がなかったと思うので、やはりNT5では発生せずNT4でのみ発生する現象の可能性が高いような気が・・・
仮に使用していたPCのスペック
CPU Celeron 866MHz
128MB RAM
WindowsXP Pro
>それからいうと Apache か 04WebServer がいいのではないでしょうか。
ApacheはそもそもはWindows用ではなく、今は一応Windows用もありますが、
全部英語、設定が一部メモ帳でのテキスト編集でユーザインタフェース不十分等、
AN HTTPDよりも設定がむずかしく、今から新しく勉強しなおすには気力も時間もありません。
AN HTTPDを勉強したときは、
・たまたま詳しく説明されているサイトがあった
・設定が比較的簡単だった
・時間的余裕があった
という理由でできたのですが・・・
04WebServerは対応OSがWindowsXP/2000なので、
NTでは動作しない（動作してもサポート対象外）と思います。
>もちろん、なんとか原因をはっきりさせたいということであれば、いくつか思いつくことがないわけではないので、
>結果的に無駄に終わる可能性もあるということを netter さんが承知の上であれば、あらためていくつかお聞きしたいことはあります。
上にも書いたとおり、AN HTTPDを使うしかない状況ですので、私がどれだけ役に立つか分かりませんが、
だめもとでもできる限りお力になりたいので、答えられる質問には答えます。
じぇ〜むすさん、
>フリーソフトの対応表示は、開発言語が対応しているのかどうかでの表示で良いのではないかと思います。
ランタイムを使うソフトの場合はランタイムの動作必須環境でよいかもしれません。
特定の環境下でのみ動かないのならランタイム作者の責任にできますから。
ただ、AN HTTPDは違うんですよね。ボーランドCでしたっけ？
ランタイムを必要とせず、ソフトの作り方によって対応OS等も変わってくるはずです。
Windows9x系対応ソフトでNTでも動くとの報告は受けているがサポート外
などとしているソフトも多数ありますし。
netter さん、
どうして AN HTTPD を使い続けるという選択をするのかちょっと不思議です。
「他のWebサーバ」とは他のソフトのことです。
以前の
http://homepage1.nifty.com/yito/namazu/gbook/20040604.0729.html
の時に、いとさんがいろいろなWebサーバソフトでCGIの動作速度を計測した例を出してくれていますが、それからいうと Apache か 04WebServer がいいのではないでしょうか。
netter さんは、WindowsNTに完全対応していないことが原因と思い込んでしまったようですが、先に書いたように、それが原因かどうか不明です。
過去の例を見ても分る通り、落ちるとか動作しないという話は比較的複数の人の報告が重なります。
もちろんひとりだけの報告の場合もあるのですが、再現手順が示されている場合はこちらでも確認できて、そうすると原因を調べることができて、したがって「直す」ことができます。
最近では、例が適切かどうかわかりませんが、
http://homepage1.nifty.com/yito/namazu/gbook/20041026.1401.html
という例がありました。
このケースなどもあいちゃんが自分で「WindowsMeからWindows2000へのアップグレードが原因」であることをつきとめてくれたので解決したものの、そうでなかったら原因不明で、「Windows2000でCGIが動作しない」という報告で終わってしまったかもしれません。
その場合に「AN HTTPD は Windows2000に完全対応していない」というべきかというとそれはないでしょう。
「WindowsMeからWindows2000へのアップグレード」の場合は、たとえば process.log を調べたりすることによって Comspec がおかしいことに気がついたのですが、最初の頃は質問する方もまさかアップグレードがおかしいなどとは思いませんからそういうアップグレードをしたことさえ自分から言うことはなかったと記憶しています。
つまり、いろいろ現象の内容を調べていくことができるとよいのですが、netterさんの場合には何を調べたらいいかも思いつかないので、残念ながら Webサーバソフトを Apache や 04WebServer にする方がよいだろうと思いました。
netter さんのページで動作が遅くなるほかに、表示がおかしい（ことがある）ことは以前からわかっています。それと遅くなることと関係があるのかないのかわかりませんが、何かしらおかしいとは思っていました。 これも原因がよくわからず、AN HTTPD を使っている他の人のページで気がついたことのない現象なので、私としてもややお手上げ状態でいます。
したがって、そうまでして AN HTTPD を使い続ける理由は特にないのではないでしょうか。
もちろん、なんとか原因をはっきりさせたいということであれば、いくつか思いつくことがないわけではないので、結果的に無駄に終わる可能性もあるということを netter さんが承知の上であれば、あらためていくつかお聞きしたいことはあります。
そんなことはやっていられない、ということでしたら、やはり他のWebサーバソフトを使うことにした方がよいと思います。
2000man さん、
確かにそうですね。考えておきます。
とりあえず、私はNT半対応（完全対応とは言えない？）と思いタスクスケジューラと併用して使い続けますが、
言い忘れていたことがあります。
他のhtmlファイルにハイパーリンクするページを作っておき、そのリンクをクリックすると、
ごくまれに「ページを表示できません」というおなじみのエラーページが出ることがあります。
もう一度クリックすると表示されますが、
対象は掲示板（CGI）でも同じ（むしろCGIの方が起こりやすい）で、
アクセスカウンタ（CGI）が表示されないこともあります。
何度かHDDのパーティションの設定変更等のためにWindowsを再インストールしていますが、
この現象は以前から発生しており、現在でも発生しています。
これも、他の人（OS）は発生しないのでしょうか。
やはり、NT半対応？と思っておくしかないのでしょうか。
ねこっちさん
> ここに来て、皆さんの投稿を参考にしている時
> 次のDOS攻撃ウイルスに遇っています。
> ＝WORM_SQLP1434.A＝
> 「WORM_SQLP1434.A」の活動は Microsoft SQLサーバ2000の脆弱性を利用していますので」ということなので、マシンをわざわざ2000にしなくてもいいんじゃないかと、素人は考えた。
Microsoft SQL Server 2000の脆弱性が原因なのでWindows2000が直接の原因じゃないのでは？
ただ、IISにもどのバージョンのWindowsにも、Linuxですらプログラムミスによる脆弱性はあるので、何かの脆弱性があるからそれを選択しない…ってやってると何も選択できないと思いますよ。
それよりか重要なのは、脆弱性に対するパッチをキチンと入れることができ、また、設定ミスで外部に迷惑を掛けるようなことがないようにする設定が出来ると言うことでしょうか。
netter netter@hotmail.com 2004/10/31 02:39 さん
TREND MICRO情報
ここに来て、皆さんの投稿を参考にしている時
次のDOS攻撃ウイルスに遇っています。
＝WORM_SQLP1434.A＝
「WORM_SQLP1434.A」の活動は Microsoft SQLサーバ2000の脆弱性を利用していますので」ということなので、マシンをわざわざ2000にしなくてもいいんじゃないかと、素人は考えた。
参照先：http://www.trendmicro.co.jp/vinfo/virusencyclo/default5.asp?VName=WORM_SQLP1434.A
> 2000man さんへ
ソフト開発の大変さを知る者として＆フリーソフトを使う者としての私の考え方ですが、フリーソフトの対応表示は、開発言語が対応しているのかどうかでの表示で良いのではないかと思います。
特にネットで公開されているソフトの開発者は、MSや企業の者ではありませんから、全てのPC＆Windowsのバージョンを把握している訳ではありませんし、個々PC
への対応と言う上では、お金を取られている企業と比べれば全然かなうものではありません。
# 肝心のMSの方でもバグ等を把握している訳ではないですしね^^;
では、今回の2000manさんの言われる
>トップで堂々とNT対応と書いているのは問題ないのだろうか。
と言う事ですが、これは前述のとおり対応と書いても問題はないと思います。
>せめて、NTで正常に動作しないという報告も受けているとの注意書きくらいはすべきではないのだろうか。
これは大分意見が分かれてしまうかもしれませんが、動作が遅くなると言う、たった2台の報告ですし、まだ原因がNTにあるのかWebサーバに問題があるのか、はっきり解かっていませんから、注意書きするのは早いのでは？と思います。
> netter さんへ
WindowsNTで、動作が遅くなる(?)問題が出たからと言って、WindowsNT未対応と言うのはどうでしょうか？
Webサーバが起動できないとか、HPが見れないとか言う問題なら、WindowsNT未対応と言うのは解かりますが、現にWindowsNT上では動作しているようですし、
>タスクスケジューラで5日程度置きにAN HTTPDを再起動するようにします。
と 言っておられるように netter さんの環境では、再起動することで動作しているように思えます。
>「他のWebサーバ」とは他のソフトのことでしょうか。
他のサーバとは、おそらく apache 等の他のWebサーバを指しているのでしょう。
今回のWebサーバの動作が遅くなる問題は、中田さんが忙しく、すぐに解決するとこができないために、netter さんの環境で、すぐに問題解決するには、申し訳ないのですが他のWebサーバを使ってください。と言うことだと思います。
以上、長文駄文失礼しましたm(_ _)m
最近の投稿を見て思った。
作者はNTでの動作確認をおこなえず、
さらにNTユーザが正常に動作しない（しかも2台にわたり）と報告しているにもかかわらず、
トップで堂々とNT対応と書いているのは問題ないのだろうか。
せめて、NTで正常に動作しないという報告も受けているとの注意書きくらいはすべきではないのだろうか。
他のフリーソフト作者はたいていそのようにしているが。
まあ、あくまでフリーソフトだしね。
以上、2000manのひとりごとでした。
中田さん、
「他のWebサーバ」とは他のソフトのことでしょうか。
それとも他のPCのことでしょうか。
このPC、わざわざAN HTTPDを使うために
（他の用途にも少し利用していますが、メインはAN HTTPD専用機）
すべて中古でPC本体、キーボード、マウス、OS、増設メモリを準備したので、
とてもPC本体の交換はむずかしいのですが・・・
キーボード、マウス、OSはいいとしても、また中古でPCを探さなければなりませんし、
メモリが少なかった場合、メモリもその機種で動作確認が取れているものを探さなくてはなりませんし、
OSはPC付属品ではないため、NT用の各種ドライバなども探す必要がありますし・・・
以前、これも中古なのですが、もっと古い機種（FUJITSU FMV-DESKPOWER）でAN HTTPDを動かしていたのですが、
これもWindowsNT Workstation 4.0 Service Pack 6aで同様の現象が発生していました。
メモリが32MBしかなく、規格が古すぎて増設も困難だったため、
メモリの容量が足りないためだと思い、新しく現在のものに買い替え、再び環境を整えたのですが、
やはり同じ現象が発生しており、今回はメモリも十分なため、
WindowsNT未対応だとしか思えなくなってくるのですが・・・
できればWindows2000を買いたいのですが、需要が高いためか価格がとても高く、
WindowsNTしか買えません。
未対応だとはっきり言ってもらえればあきらめる（しかない）のですが、
中田さん側にNTでテストできる環境がないようですし、本当にどうしましょう・・・
ちょっと関係ないですけど、どなたかWindows2000を安く譲ってもらえません？w
netter さん、
「WindowsNT未対応」と言うのは変でしょう。WindowsNTだからかどうかも不明ですから。
WindowsNTだとそうなるのかどうかもわかっていませんし。
netterさんの場合は、他のWebサーバを使うというのが簡単な解決法だと思うのですが。。。
README については、次のバージョンアップの時には直します。
中田さん、
以前報告したのですが、まだ直っていないので一応もう一度報告しておきます。
AN HTTPD 1.42nのREADMEに、「httpd13x.zip」や「httpd13x.exe」という表記があります。
この「13x」って「14x」の間違いですよね？
利用者は普通分かると思いますし問題ないとは思うのですが、一応発見したので報告しました。
それに、直さないと、
「1.3からREADME変わってない」＝「1.3も1.4も機能的にほとんど変わらない」＝「1.3でもいいや」
と思うユーザもいると思いますし・・・
中田さん、
そうすると、WindowsNT未対応と考えてよろしいのでしょうか。
MicrosoftのHPだったと思うのですが、そこで、
Windows2000はSP4でメモリをどんどん消費するバグが修正されたというのを見たのですが、
それは関係ないですよね？
もし関係あればWindows2000でもSP3までの利用者は同様の（またはそれに近い）現象が発生すると思うのですが。
WindowsNT利用者が非常に少ないので他の人はどうなのか分からないですが、
もしWindowsNTだと発生する現象だということなら注意書きなどに書いておいていただけるとユーザ側はうれしいです。
※もしWindowsNT利用者でこの掲示板を見ている人がいましたら、同様の現象が発生しているか教えてください。
とりあえず、原因不明、Windows新規購入も資金的に不可能なので、
タスクスケジューラで5日程度置きにAN HTTPDを再起動するようにします。
他のアプリケーションは重くならないのでAN HTTPDも何らかの改良で直るとは思うのですが、
WindowsNTでテストできる環境がないということなので仕方ないと思います。
環境があったら改良してほしいというのが個人的な希望です。
netter さん、
そうするとメモリは関係ないようですが、では何が原因なのかということはわかりません。
同様の症状は netter さんだけのようなので WindowsNT の問題なのかもしれませんが、私も今は WindowsNT を使っていないので調べてみることは難しい状況です。
netter さんには、AN HTTPD 以外の Webサーバを使うことをお勧めせざるを得ません。
中田さん、
（1週間ほど投稿していなかったので、他の人からの質問もあり、忘れているかもしれません。忘れていたら過去ログを見てください。）
それで、1.42nにバージョンアップし、起動したままにしておいて、今日で7日目なのですが、
やはり、起動後5日後くらいからHP閲覧に重さが目立ち始め、特にCGIの動作が非常に重くなります。
7日経った現在、普段は1秒以内に表示されるアクセスカウンタが、
表示されるまでに10秒以上かかり、表示されなかったりもします。
AN HTTPDが使用しているメモリをタスクマネージャで見てみましたが、5888KBでした。
PC全体のメモリ使用量は118MBほどで、Windows起動時とほとんど変わっていません。
やはりAN HTTPDを再起動すると元どおり軽くなり、そのときのメモリ使用量は3640KBでした。
AN HTTPDはWEBサーバなのに起動したままにしておくことはできないのでしょうか。
タスクスケジューラなどを使用して定期的に再起動するしかないのでしょうか。
サーバPCの情報（訪問者数以外前にも書きましたが時間が経ったので念のためにもう一度）
CPU Celeron 500MHz
512MB RAM
WindowsNT Workstation 4.0 Service Pack 6a（その他の更新も完全適用済み）
1日に10〜20人程度のHP訪問者。多くても30人。
netter さん、
申し訳ありませんが、何がどうなったかがよくわからないので問題ないかどうか確たることは言えません。
http://homepage1.nifty.com/yito/anhttpd/faq/index.html#Q36
の追記などもご覧ください。
>1.42n で試してみて、症状が同じかどうかをお知らせください。
で、1.42nにアップグレードしようとして1.42mのファイルをすべて削除して1.42nのファイルを置いたのですが、
1.42nを起動すると以前の設定が保持されていたので、どうしてだろうと思い、
レジストリを削除するのを忘れていたことに気づき、AN HTTPDを終了してから、
レジストリエディタで削除しようとしたのですが、「削除できません」とエラーが出て削除できず、
Windowsを再起動しても同じエラーが出て削除できないのであきらめましたが、
1.42nを再び起動すると設定が初期状態に戻っていたので、一応削除されたのかな？などと思い、
普通に設定しなおして使っているのですが、問題ないですよね？
netter さん、
netter さんの症状の内容がまだよくわからないので、1.42n で解決できるのかどうかはわかりません。
1.42n で試してみて、症状が同じかどうかをお知らせください。
仮想メモリの使用量は見方がよくわからなかったのですが、
物理メモリが400MB以上空いているようですので、メモリ関連は問題ないと思います。
AN HTTPDの再起動もやってみましたが、
Windowsを再起動したときと同じように動作が速くなりました。
やはり、AN HTTPDがメモリをどんどん消費してしまっているということなのでしょうか。
中田さん、
>タスクマネージャで AN HTTPD の「仮想メモリ使用量」はどうなっているか
>Windowsではなく AN HTTPD を再起動した場合はどうか
仮想メモリ使用量はあとで見てみます。
AN HTTPDの再起動もやってみます。
現象をもう少し詳しく書いておくと、
特に、CGIの動作が著しく遅くなって来るようで、ひどいときはCGIがエラーで動作しないことすらあります。
アクセスカウンタも、普段の半分以下しか進まなくなります。
掲示板も、表示するのにかなり時間がかかり、エラーで表示されないこともあります。
すべてはWindowsを再起動すると直るのですが・・・
AN HTTPD 1.42nが公開されたようですが、メモリリーク対策が行われたとありますよね。
これって、やっぱり今までのAN HTTPDにメモリをどんどん消費するバグがあって修正したということなのか、
メモリが少ないユーザ向けに少しでもメモリを消費しないように改良しただけだということなのか、
支障がなければ教えてください。
もしバグが修正されているのだとすれば、私の問題も解決するかもしれませんし、
ここの掲示板の過去ログで同様の現象を報告している人も解決するかもしれません。
あと、一つだけ気になったので報告しておきます。
それほど重要な問題ではないのですが、AN HTTPD 1.42nのREADMEに1.3xとの表記があるのを発見しました。
多分、1.4xの誤りだと思うのですが・・・
netter さん、
もう少し説明してもらわないと何とも言えませんね。
たとえば、
タスクマネージャで AN HTTPD の「仮想メモリ使用量」はどうなっているか
とか、
Windowsではなく AN HTTPD を再起動した場合はどうか
とか、その他、関係がありそうなことを説明してみてください。
AN HTTPD 1.42mを使用して自宅ホームページサーバを運営しています。
Windows起動直後から1〜2日程度は問題ないのですが、
3日目頃からHP閲覧が重く（遅く）なってきます。
Windowsを再起動すると直ります。
これはなぜなのでしょうか。
タスクマネージャを起動して残りメモリ容量を確認してみてもまだまだ余裕なのですが。
WindowsNT 4.0で使用するとなってしまうという、AN HTTPDの仕様なのでしょうか。
以前、サーバ機が決定するまでの間、
仮に別のPC（WindowsXP）でAN HTTPD 1.42hで運営していたときは特に問題なかったような気がするのですが・・・
Celeron 500MHz
512MB RAM
WindowsNT Workstation 4.0 Service Pack 6a
Windows Updateにより提供される更新はすべて適用。
ウイルス対策ソフトウェア、ファイアウォールソフトウェア、どちらも最新版が常駐。
1〜2ヶ月に1度、スパイウェア検索、ウイルス検索、デフラグ、完全チェックディスクを実施。
各種ソフトウェアは自動更新、または定期的に更新を確認。