鷹の巣です。いつもお世話になっております。
鷹の巣 webmaster@sakaguch.com 2004/07/19 09:05 のまた続きです。
「可能な限りgzipで応答する」だけにチェックを入れていて、AN HTTPD 1.42kが、2004年7月23日00:23にやっと（失礼）落ちました。
＃ 文字コードは、utf-8です。
trace.logを取っていますので、メールにて拝送させて頂きました。
「可能な限りgzipで応答する」が犯人かどうかは不明ですが、ご解析方よろしくお願いします。
現在は、1.42kで、「可能な限りgzipで応答する」のチェックを外しました。
この状態で、またしばらくtrace.logを採取することにします。
私のサイトでは、1.42kの使用メモリが増大するようなことは、起こっておりません。数ヶ月起動したままです。
ただし、夜中にバックアップ等の定時処理を行っていますので、この時はPerlの全プロセスをkillしています。
鷹の巣です。いつもお世話になっております。
鷹の巣 webmaster@sakaguch.com 2004/06/09 01:20 の続きです。
2004年6月9日より1.42mで、「可能な限りgzipで応答する」だけにチェックを入れてtrace.logを取っていましたが、6月19日までにAN HTTPDは一度も落ちませんでした。
前回は1.42hで、ここにチェックを入れて5日程で落ちたものですから、てっきりこれを犯人扱いしてしまいました。お騒がせして申し訳ありませんでした。
＃ CGIにも、open ( STDOUT , "| D:/WWW/himitsu/binary/gzip.exe -1 -c" ); は現在も入ったままです。
trace.logは、現在、ログファイルサイズの制限方法
http://sakaguch.com/SetAnhttpdSec.html#LimitSize
のスクリプトで実施しています。
中田昭雄 nakata@st.rim.or.jp 2004/02/04 20:45 様
鷹の巣です。ご無沙汰しております。
鷹の巣＠松阪 webmaster@sakaguch.com 2004/02/04 20:14より
> trace.logを取れるようになりましたら、再度「可能な限りgzipで応答する」だけにチェックを入れて
> 再挑戦して見ようと考えています。
> ＃ 荒っぽいですが、webサーバが稼動しているという条件下で、trace.log容量が一定値以上あれば、
> ＃ ロックをかけずに一定時間毎にtrace.logをクリヤしようと考えています。
> ＃ 運が悪ければ、webサーバが停止した場合にログが残らないということになりますが。
私のサイトでは、trace.logが5分間で1.5MBになります。遅くなりましたが、以下のような手抜きperlスクリプトで肥大化対策を取って、休日にtrace.logを取ろうと考えています。
#!D:/Perl/bin/perl.exe私のサイトは、namazuのhtml出力を除いて、全ページがShift_JISコードからUTF-8コードに変わったりと、以前の環境とは違ってしまいました。ゆっくりで申し訳ありませんが、ログが取れましたら、報告に参ります。
# trace.logのサイズを約1MByteに抑えるperlスクリプト
print "trace.logのサイズを1MByteに抑えています。\n";
while () { # 無限ループ
# trace.logの古いファイル名と2つ存在したら、古いファイルを削除する。
if ( ( -e "trace.log" ) and ( -e "trace.old.log" ) ) { unlink( "trace.old.log" ); }
# trace.logが1MBを超えたら、ファイル名を変える。
if ( ( -s "trace.log" ) > 1000000 ) { rename ( "trace.log" , "trace.old.log" ); }
# 60秒処理を休む。
sleep (60);
}
exit;
鷹の巣さん、
中間報告、了解しました。
再挑戦の後、何か判明したらまたよろしく。
中田昭雄 nakata@st.rim.or.jp 2003/10/29 20:47 さん
いつもお世話になっております。
>とりあえず、「可能な限りgzipで応答する」だけにチェックをいれて動作を確認してみてください。
12月に一度、落ちてしまいました。チェックを外すと、落ちなくなりました。
鷹の巣 webmaster@sakaguch.com 2003/10/26 17:11 で投稿致しましたCGIは、現在も入ったままなのですが、なぜか
open ( STDOUT , "| D:/WWW/himitsu/binary/gzip.exe -1 -c" );
では、落ちないのです。
trace.logは、私自身でまだ、肥大化対策が出来ていないので、取っておりません。
申し訳ありませんが、これで中間報告とさせて頂きます。
trace.logを取れるようになりましたら、再度「可能な限りgzipで応答する」だけにチェックを入れて
再挑戦して見ようと考えています。
＃ 荒っぽいですが、webサーバが稼動しているという条件下で、trace.log容量が一定値以上あれば、
＃ ロックをかけずに一定時間毎にtrace.logをクリヤしようと考えています。
＃ 運が悪ければ、webサーバが停止した場合にログが残らないということになりますが。
追記）perlも5.6より5.8に移行させました。＃ namazuも5.8で、検索キーを作成しています。
これが原因かどうかは、全く不明ですが、500番のエラーが発生しても
perl.exeのゾンビプロセスが一度も発生しなくなりました。
perl5.8になって、時間切れの処理もうまくいけるようになったと思いますので、
念のために全てのperlスクリプトに時間切れの処理を追加しようと考えています。
# 時間切れの処理のperlスクリプト例(ActivePerl 5.8を使用のこと)
# プログラムの先頭で実行して、3秒で終了する例
# 参考URL http://www.aka.ne.jp/~deguchi/hobby/iden/cgi.html#timeout
alarm(3);
$SIG{'ALRM'} = 'kill_process';
while(){ # 無限ループ
print "*";
}
exit;
#サブルーチン
sub kill_process {
# …適切な終了処理…
exit;
}
いとさん、
そのリクエストで落ちることを確認しました。
できるだけ早く対処します。
中田さん
どちらも落ちます。
GET /gz/index HTTP/1.1
Host: 192.168.0.2
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.0.2) Gecko/20030208 Netscape/7.02
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: ja
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: Shift_JIS, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
GET /gz/index HTTP/1.1
Host: 192.168.0.2
User-Agent: Mozilla/5.0 (Windows; U; Win98; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: ja
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
いとさん、
そうすると、原因はリクエスト（ヘッダ）の違いくらいではないかと思います。
Netscape 7 のリクエストのトレースをお知らせ下さい。
鷹の巣さん、
そうですね。なかなか説明しずらい内容なので、少し調べもらう方がよいでしょう。
中田さん
コンテントネゴシエーションのときに
Netscape7 からアクセス(…/index)すると100% 落ちるようです。
IE6, Netscape4.78では問題ありません。
index.html は BODYの中身が英字数文字だけの単純な内容です。
アクセスの後、Keep-Aliveの時間経過後にエラーダイアログが出ます。
鷹の巣さんのケースもこれかどうかは分かりませんが。
中田さん、いとさん、ご回答ありがとうございました。
> 中田昭雄 nakata@st.rim.or.jp 2003/10/29 20:47
中田さんのご指示通りにやってみて、報告させて頂きます。
＃ 出張中のため、来年に実機（サーバ機）で試します。
> いと gfh05223@nifty.com 2003/10/30 00:20
理路整然とわかりやすく、まとめられていて、大変助かりました。ありがとうございました。
自宅サーバとしては、Webページの容量を気にしなくてよいので、
1.全ての静的htmlファイルに対して、html.gzを用意しておいて、コンテントネゴシエーションでgzip圧縮ファイルを送出するようにしたい。
＃ Webサーバの負担を軽くしたい。
2.動的ファイルは、Webサーバがgzip圧縮を行なう。
というのが、私の理想です。
CGIについては、鷹の巣 webmaster@sakaguch.com 2003/10/26 17:11に書きましたスクリプトで、
CGI側でgzip圧縮するようにして、試してみます。
＃ open ( STDOUT , "| D:/WWW/himitsu/binary/gzip.exe -1 -c" ); というようにパイプで
＃ 繋ぐと呼び出す側と違うPID（プロセスのID番号）で起動されるのが、ちょっと気になりますけど。
＃ ブラウザがアクセスを中断→ゾンビプロセスの発生→500エラーの発生
＃ といった心配をしております。
いとさん、
現状ではそのような動作かもしれません。
6つの項目についてはすべて意図した動作ではありません。
特に Win98での動作はちょっと不可解ですが、6つとも見直してみます。
AN HTTPDのコンテントネゴシエーション(エンコーディング関係)の動作を調べました。
そもそもの仕様がよく分からないところもあるので、間違っていれば指摘を
お願いします。＞中田さん
コンテントネゴシエーションでは、ファイル filename.ext(extは拡張子)に対して
ユーザが予め filename.ext.gz を用意しておく。
アクセスする URLは extを省略した
http://www.example.com/path/filename
である。このとき filename.ext.gz が返る。
ファイルが index.htmlの場合にも
http://www.example.com/path/index
のように書く。もし index を省略して
http://www.example.com/path/
としてしまうとデフォルトインデックスが利き、
gz の付かない index.html が返る？
http://www.example.com/path/filename.ext
のようにファイル名をフル指定でアクセスしても
コンテントネゴシエーションは働くはず？
以下は実際に index.htmlと index.html.gz で試行した結果である。
どちらのファイルが返るかを示している。
--------------------------------------------------------------------------上記の結果に対して以下は正常な動作かどうか不明な点
URL: …/index URL: …/index.html URL: …/
--------------------------------------------------------------------------
両ファイル有(Win2000) index.html.gz index.html.gz index.html(*4)
index.htmlのみ index.html(*6) index.html index.html(*4)
index.html.gzのみ index.html.gz Error 404(*5) Error 403/404
両ファイル有(Win98) index.html.gz index.html(*3) index.html(*4)
Doc.Root直下(両方有) Error 404(*1) index.html(*2) index.html(*4)
------------------------------------------------------------ーー-----------
鷹の巣さん、
「コンテントネゴシエーションを有効にする」と「可能な限りgzipで応答する」とは別の機能だとお考え下さい。
つまりどちらかだけにチェックを入れるようにしてください。
いずれの場合も、CGIやSSIなど動的出力の場合には対応していません。
とりあえず、「可能な限りgzipで応答する」だけにチェックをいれて動作を確認してみてください。
確認には trace.log をとるようにして、応答ヘッダを見るのがよいと思います。
「可能な限りgzipで応答する」の場合は、.gz のファイルを用意する必要はありません。
その後で、「コンテントネゴシエーションを有効にする」にチェックを入れ「可能な限りgzipで応答する」のチェックははずして、動作を確認してみてください。
この場合も trace.log でどのアクセスの場合にどのファイルを使うかはわかると思います。
こちらの場合は、それぞれのファイルに .gz のファイルを用意しておく必要があります。
ただし、http://www.example.com/ のようなアクセスの場合（ファイルのパスを指定しない場合）、うまく動作しないかもしれません。
あとは、このあたりでは落ちることもありそうです。どのような場合に落ちるのかわかりましたらお知らせ下さい。
鷹の巣です。いつもAN HTTPDには、お世話になっております。
初心者が作成しているWebページでありながら、お蔭様で最近は、月間100万頁配送に迫っています。
http://sakaguch.com/log/2003/200309.html
現在、出張中でインターネットへは、64kbpsでアクセスしているため、
Webサーバ側のgzip圧縮に興味を持つようになりました。
ところで、この2003年10月11日〜16日にかけて、ホームページ開設以来初めて、
AN HTTPD が稼動中に5回落ちました。（Windows2000 professional のAN HTTPD 1.42h です。）
＃ DNSサーバの不具合で、アクセス出来ないことは、度々ありましたが。
出先で、調査ができないので、推測ですが、
コンテントネゴシエーションタブの内容を設定したのがいけなかったようです。
現在は、「コンテントネゴシエーションを有効にする」と「可能な限りgzipで応答する」
のチェックをリモート操作で外しましたら、落ちなくなりました。
＃ リモート操作とは、電話で家の婆さん（敬愛する母親）をテレコン操作。
落ちる件は、Windows2000の動作権限の問題もあって、後日調べることにしますが、
クライアント機のWindowsXP Home Editionの管理者権限で、AN HTTPD 1.42h を動作させてみることにしました。
そこで、コンテントネゴシエーションタブの設定のAN HTTPD の挙動を教えて下さい。
エンコーディングの(identity)を削除して、タイプgzipの拡張子gzをデフォルトにし、
HTTP /1.1に対応したブラウザでアクセスする場合に、
1.「コンテントネゴシエーションを有効にする」にチェックを入れ、
イ）index.htmlファイルが存在し、index.html.gzファイルが存在する場合。
ロ）index.htmlファイルのみが存在する場合。
ハ）index.html.gzファイルのみが存在する場合。
http://www.example.com/でアクセスすると、どの場合もWebページが表示されるのでしょうか？
ハ）の場合は、404エラー（ファイルが存在しない）になってしまいます。
＃ バチャルホストを使用しない様にしても同じですし、SSIが無効なWebページでも同様です。
2.「可能な限りgzipで応答する」にチェックを入れ、
イ）index.htmlファイルが存在し、index.html.gzファイルが存在する場合。
ロ）index.htmlファイルのみが存在する場合。
ハ）index.html.gzファイルのみが存在する場合。
http://www.example.com/でアクセスすると、どの場合もgzip圧縮されたWebページが表示されるのでしょうか？
また、イ）とハ）のindex.html.gzファイルが存在する場合、Webサーバは、このファイルを使用するのでしょうか？
それとも、Webサーバ側で、index.htmlのファイルがgzip圧縮されるのでしょうか？
また、CGIの標準出力もWebサーバ側で、gzip圧縮されてブラウザに出力されるのでしょうか？
＃ CGI(perl)側は、print "Content-type: text/html\n\n";でもgzip圧縮されてブラウザに出力されるのでしょうか？
http://homepage1.nifty.com/yito/namazu/gbook/20020412.0228.html
http://homepage1.nifty.com/yito/namazu/gbook/20021026.0610.html
を読みましたが、今ひとつ理解出来ませんでした。
尚、ブラウザがHTTP /1.1に対応していて、gzip圧縮に対応しているのは、以下のperlスクリプトで確認いたしました。
#!D:/Perl/bin/perl.exe
# CGIでのgzip圧縮の試験 2003.10.26 鷹の巣
# gzip.exeの入手先 http://www.gzip.org/gzip124xN.zip
# 解凍後、D:\WWW\himitsu\binary\gzip.exeにコピーして設置する。
# 参考サイト(スクリプトの配布元)
# http://www.ibport.ne.jp/~yui/cgiwork/tech/src/gzip_cgi.txt
# http://www.oersted.co.jp/~emk/dhtml/nocompgif.html#gzip
$| = 1; # バッファリングしない
if ( $ENV{'HTTP_ACCEPT_ENCODING'} =~ /gzip/ ){
print "Content-type: text/html\n";
if ( $ENV{'HTTP_ACCEPT_ENCODING'} =~ /x-gzip/ ){
print "Content-encoding: x-gzip\n\n";
} else {
print "Content-encoding: gzip\n\n";
}
# gzip.exeの引数の1 は、圧縮レベルで1(低圧縮)〜9(高圧縮)、c は、圧縮結果を標準出力
open ( STDOUT , "| D:/WWW/himitsu/binary/gzip.exe -1 -c" );
} else {
print "Content-type: text/html\n\n";
}
if( $ENV{'HTTP_ACCEPT_ENCODING'} =~ /gzip/ ){
print "ブラウザがNN 4.06以降/WindowsのIE 4.0以降のため、gzip圧縮して送信中。\n";
} else {
print "ブラウザがNN 4.06以前/WindowsのIE 4.0以前のため、gzip圧縮せずに送信中。\n";
}
# 一応書いておこうっと。
$| = 0;
close ( STDOUT );
exit;