index2.html など転送量削減案

転送の帯域を抑えるため、各htmlコンテンツをgzipで提供するに当たり、
gzip対応しているブラウザにはgzip版を、非対応ブラウザにはテキスト版を
送信するcgiを挟みます。
このことにより、ブラウザのトラブルを回避し、圧縮された各コンテンツを
配給できます。

実装は以下の通り(index2.htmlの場合)

index2.cgi導入 → cgi内部でgzip対応を判断 → 適切な内容を表示 → (ﾟдﾟ)ｳﾏｰ

>>2 に必要なファイル一覧と概要

>>3 にインストール方法

ftp://210.170.170.118/incoming/index/bbsmenu.html
ftp://210.170.170.118/incoming/index/bbsmenu.cgi
ftp://210.170.170.118/incoming/index/bbstable.html
ftp://210.170.170.118/incoming/index/bbstable.cgi
ftp://210.170.170.118/incoming/index/index2.html
ftp://210.170.170.118/incoming/index/index2.cgi
ftp://210.170.170.118/incoming/index/subback.html
ftp://210.170.170.118/incoming/index/subback.cgi

bbsmenu.html bbstable.html は www.2ch.net/ におけば、そのまま使えます。
index2.html subback.html は /板名/に置きます。

*.cgi は、すべてそのまま使えます。

最終的にブラウザに表示される「実ファイル」は、xxxxx_r.html xxxxx_r.html.gz です。
index2.html -> index2_r.html
index2.htm -> index2_r.html.gz
subback.html -> subback_r.html
のようにリネームしてください。

<index2>
１）bbs.cgiをとめる
２）既存のファイル名を変更する
　mv index2.htm index2_r.html.gz
mv index2.html index2_r.html
３）bbs.cgiが出力するファイル名を変更する（bbs.cgi内で指定されているファイル名）
　index2.htm -> index2_r.html.gz
　index2.html -> index2_r.html
４）復帰スクリプトが出力するファイル名も、同様に変える
５）ftp://210.170.170.118/incoming/index/index2.html をダウンロードし、設置する。
６）ftp://210.170.170.118/incoming/index/index2.cgi をダウンロードし、設置する
７）bbs.cgiを稼働状態に戻す

<subback>
１）bbs.cgiをとめる
２）既存のファイル名を変更する
　mv subback.html subback2.html
３）bbs.cgi が出力するファイル名を変更する（bbs.cgi内で指定されているファイル名）
　subback.html -> subback_r.html
４）bbs.cgi が subback_r.html を gzip圧縮した subback_r.html.gz も作るようにする
５）復帰スクリプトが出力するファイル名も、同様に変える（ subback_r.html.gz は作らなくてよい）
６）ftp://210.170.170.118/incoming/index/subback.html をダウンロードし、
　"xxx" を鯖名に、"yyy" を板名にそれぞれ置換し、設置する。
７）ftp://210.170.170.118/incoming/index/subback.cgi をダウンロードし、設置する
８）bbs.cgiを稼働状態に戻す

<bbsmenu.html/bbstable.html>
１）既存のファイル名を変更する
　mv bbsmenu.html bbsmenu_r.html
　mv bbstable.html bbstable_r.html
２）それぞれを gzip 圧縮したファイル（bbsmenu_r.html.gz bbstable_r.gz）を作る
３）ftp://210.170.170.118/incoming/index/bbsmenu.html
　　ftp://210.170.170.118/incoming/index/bbsmenu.cgi
　　ftp://210.170.170.118/incoming/index/bbstable.html
　　ftp://210.170.170.118/incoming/index/bbstable.cgi
　をダウンロードし、設置する。

以上です。

「CSSを利用した２ちゃんねるのデザイン」
ttp://natto.2ch.net/test/read.cgi?bbs=hp&key=998851406

でWeb制作板のindex2をCSSに対応したサンプルを作りました。
CSSがある場合の表示結果
ttp://isweb3.infoseek.co.jp/play/teess/2ch-index2-133.html

CSSが無い場合の表示結果
ttp://isweb3.infoseek.co.jp/play/teess/2ch-index2-133noncss.html

＄です。呼ばれて飛び出ました。

ブラウザチェックで圧縮・非圧縮のＨＴＭＬへ飛ばすスクリプトですけど、
プロセス起動数が半端じゃないことになりそうです。
対・効果としては利便性の向上ぐらいしかあがらないだけに、導入はつらいかも。。。

subbackを圧縮するのは良い案ですね。

www.2ch.netはphpサポートしてるので　それでやったら?

なるほど、プロセス起動数かぁ。
＄さん、いま瞬間最大アクセス数って、どのくらいを記録しているのでしょう？

gzip accept encoding だったら　location発行するだけ であれば
どんなバージョンの PHPでも出来るでしょ。

>>8
ＰＨＰ使っちゃうと一撃でサーバがお逝きになられる可能性もありますです。
>>9
ちょっとしらべてみまーす。

>>9
鯖やら時期によって違うとは思うですが、祭りやら何やらを考えた場合の最大は50/秒ぐらいかと。。。

subbackって、既にGZIP化してあるようですね。

httpd.confでも判別できるのですが、
httpd.confはいじれるのでしょうか?

>>12
なるほど。そんなに多いと確かにプロセス増えるのは危ないですね。
mod_gzip入ればこういう仕組みは不要でしょうけど・・・

ただ、index2.cgi自体はLocation呼ぶわけではなくそのまま要求に応えるんですが、リロードではなく
.htaccessで直接cgi呼ぶのも厳しいでしょうか？

>>14
サーバでフィルタをかますのが一番良いと僕も思ってるんですけど、
サーバの設定をいじるのはＮＧらしく。。。
※そのへんが今回のようなケースへの対応を技術的に難しくしちゃうです。。。

>>15
MOD_PERLの有無に依るんですが、
PERL_CGIはサイズの大小を問わずインタプリタを起こしちゃう…ってのが問題です。

解法としては「ＢＢＳメニュー側をＣＧＩにする」ってのがよいと思うです。
これだと、１ユーザが１度しか呼びませんので。。。

>>18
ああ、そうですね。
Cでのcgi化も可能なんですが(というか、同じもののCソースもあるのですが)、Cでもその辺の事情は変わらないのでしょうか？

>>19
どちらも実行形態は似ています（Perlは「エンジンのロードとコンパイルの２クッションが入ります）が、
ネイティブコードですのでプロセスのサイズは小さくなりますし、コンパイルの手間も省ける分軽いです。
ただ、リクエスト数が膨大になると結果起こることは、Perlと似たり寄ったりになるです。。。

>>13
どうもお疲れさまです。
そうですね。subbackもbbstableも、gzip圧縮されたのと非圧縮のとが
あるようです。
要は、IEとかNNの新しいのを使ってるユーザーの皆さんには、もっと
積極的に .htm のほうを使っていただきたいんですよね。。。
しかし、read.cgiでは一律に .html へのリンクをはって・・・！！
read.cgiスレの方で改善案出してきます(泣

>>12
50ってのの単位は? 素直に 50hit/s と
読んでいいのでしょうか?

>>22 厳密には50Req/sですです。

>>21
そうですね。index2.htmlのリンクはすべてindex2.htmとなっていますので、
使っているうちにindex2.htmへと移動することになりますから、それで良いと思います。
※相変わらず、GZIPに対応できない方は突如文字化けすることになりますが。。。
でも、read.cgiでやるなら（僕もソースみさせて頂きました）GZIP対応か否かの判定は
できているので、htmlかhtmを選別してLocationできると思います。

>>23
２０分で1000Resつくような板(ニュース速報)があることを考えれば、たしかにプロセス圧迫死の恐怖は大きいですね。
ただ、転送料を減らすという視点からいうと、もしgzip化するのであれば、
こういった仕組みをどこかに入れない限り、常にユーザからのクレームが出続けますねぇ。
夜勤さんにお願いして(サーバが死ぬかもしれませんということを)、評価テストとか出来ないでしょうか？

・・・机上で分かり切ってるレベルなのかなぁ？

>>18
bbsmenu.htm[l] を判別させるのも、>>1-3 でできておりますので、
良かったらお使い下さい。
>>24
はい。その通りです。

>>23
50req/sだったら、
楽勝かなと個人的に感じるんですが…

器は河童800が2発、主記憶1GBと
聞いてるんで。

bbsmenu と read.cgi の段階で .htm .html 自動振り分けができるようになれば、
あとは、
「gzip 圧縮対応ブラウザなのに（今までの習慣で）明示的に index2.html を指定してくるユーザー」
だけが残ることになります。
できるだけ .htm を積極的に試してもらえるよう、各板にもっとアナウンスは
できないでしょうか？

>>25
そこは夜勤さんの判断によりますね。
サーバの最大プロセス起動数をいじらなくちゃならないんで。。。

Perlerです。徹夜明けなんで途中で気絶する可能性がありますが参加します。

>>28
その場合、文字化けは解決できますが、Last-Modifiedが出ないので
キャッシュの効果が期待できないんですよね。。。
文字化けしない分現状よりはましになるとは思いますが。

>>27
わたしも、何とかならないのかな？って思います。
ただし、起動しているのがread.cgiだけではないことを考えれば、そう一概に言い切れないんですけれど。
実際、今でも深夜には300復帰がかけられない状況があるわけですから。
>>29
そうですね。
index2.cgiについては、夜勤さんの判断をお聞きしてみたいです。

>>26
これは入れちゃいたいでーす。
>>27
必要なのは「いけますよん」という夜勤さんのＧＯっすね。
転送量事件のみならずプロセス事件まで起こっちゃ、コトです。
>>28
明示的にhtmlを狙ってリロードをかけない限りは大丈夫です。
現在のところ、
html->書き込み(BBS.CGI)時のブラウザ判定->htm[l]
html->リロード->htm
read.cgi->html
…となっているので、htm対応ユーザは自動的にhtmへと意向するようになっています。
※でも、htm対応ユーザには明示的にhtmを呼んでもらうのが一番良いですね。。。

>>32
お願いしますです＞bbsmenu

index2.html に[ブックマーク/お気に入り]してる人が、
結構いると思うんですよね。＞移行

>33
index2.htm に 「こっちにブックマーク夜露死苦！」 とでも書くとか。

すみません、全部のスレの流れが追えないのですが、
index2.cgiとmirror.plと、どちらが開発が急がれていますか?

index2.cgiのほうだと思うんですが、そちらの開発の検討に手をつけてしまって
構わないでしょうか?

>>35
おそらく、index2.cgiのほうだと思いますが、ネックは >>6 とのことで。。。

index2.cgiは設置の可否が微妙なので、mirror.plの方が急がれるかと。。。

>>37
失礼しました。

index2.cgi そのものは、今すぐ動く状態まで開発されています。
あとやるとしたら、C への移植かな。。。 >>19-20 があるけれども。

>>37>>38

了解しました。

今、プロセス起動数について調べていますので、これが済んだらmirror.pl
に移ります。

nph-使うと負荷節約できると思ったのに駄目でした。。。

web制作板有志の方が作ってくれました。
ここ数日何度も推敲され、異論は出てないようです。
こういう感じでも検討お願いします。
http://isweb3.infoseek.co.jp/play/teess/2ch-index2-133.html

>>39
スクリプトの最初の方で、

fork && exit;
Cなら
if(fork())exit(1);

をやって、プロセスをデーモン化させておくと、
親プロセス(httpd)がCGIへのwaitが完了するので、Apacheの同時最大接続数が結構節約
できるような気がするのですが、有効だと思いますか?

>>40のスレ（web制作板で今主流になってるスレ）
http://natto.2ch.net/test/read.cgi?bbs=hp&key=998851406&ls=20

>>38
あれ。Cソースなかったんでしたっけ？私もちょっと混乱気味です。
＄さんのおっしゃるとおり、もし実装するにしてもＣベースになろうかと思いますので、Ｃの開発は、進めた方がよいのではと思います。
すみません。

>>41
ちと調べてみます。
>>43
はじめはCだったのですが、ある事情でわざわざperlに移植したんです（＾＾；
スレを全部読むと見えてくると思います。
結論として、Cの方が良いというのは一致していますので、再移植しましょうか。

index2.cgi、ＯＫみたいなのでいれちゃいまーす。

>>39
Apacheのほうは節約できそうです。
起動プロセスそのものが増えてしまうのは、仕方のないところですが。

>>45
ほにょー（＾＾；
楽しみです。

bbsmenu などもいれていくにあたって、将来的に C の方がよろしければ
移植しておきますが、どうでしょうか？

>>45 別スレでは、
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=999097075&ls=100

>>48 げっコピペミス。おまけに名無しさんだし。

read.cgi改良スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=998997848&ls=100

テストサーバ：saki
http://saki.2ch.net/geino/index2.cgi
http://saki.2ch.net/kouri/index2.cgi

>>46
と私も思ったんですが。。。

現状のApache(1.3.x以降)だと、nph-する、しないに関わらずhttpd側でのバッファリングは一切やらない
(クライアントにリダイレクトしちゃう)みたいなので、昔のApacheで言われていたバッファリングによる
オーバーヘッドの回避はないらしいです。

ヘッダのパースで生じるオーバーヘッドもほとんどないような気がします。

http://saki.2ch.net/geino/index2.cgi に接続。

HTTP/1.1 200 OK
Date: Thu, 30 Aug 2001 14:59:11 GMT
Server: Apache/1.3.6 (Unix) PHP/4.0.3pl1 mod_ssl/2.3.6 OpenSSL/0.9.3a
Content-Encoding: gzip
Content-Length: 14751
Last-Modified: Thu, 30 Aug 2001 14:59:00 GMT
Connection: close
Content-Type: text/html

>>50 >>52
振り分け、こちらでも確認しました。ちゃんと http_encoding みています。
>>51
およよ〜。

sakiサーバでのテスト導入が完了です。
リロード先＆書き込み後のジャンプ先もindex2.cgiとなりました。　　

>>44
そうですよね(笑)
Ｃベースのスタートだったのは記憶していたので。

>>54
index2.htm[l] が更新されない限りリロードにも応じない機能も、
ちゃんと動作しています。

read.cgi の新しいバージョンも、導入できる状態にありますので、
可能なときにお願いしますです。

read.cgiの「掲示板に戻る」もindex2.cgiにしたほうがいいかな。

>>54
書き込み後のジャンプ先、HTTP1.0と1.1で確認しました。
確認に大学受験板を使いましたが、HTTP1.0用のindex2.html、subbackへのリンクがsubback.htm　になっていて、生gzip吐いていますです＞大学受験板。

>>57
そうかもしれないですね。全板、この調子で導入できるのであれば。
>>58
.html -> subback.htm になってますね。全板。
subback.cgi へのリンクにしていただけるとよさそう。

index2.cgiってFORCE_304_TIMEは実装していますか?

>>60
はい。現在は10秒です。

index2.cgiですが、全サーバのプロセス設定と実際の負荷の検証が必要なので、
全体への反映には時間を要します・・・とりあえずsaki鯖のみでちょっとデータとりしてもらいます。

今入っているread.cgiだと、gzipを呼んでるはずなので、
プロセス状況の確認には、不適当じゃないですか。

ftp://210.170.170.118/incoming/index/index2.c
移植してみたので、どなたかご確認下さい。

>>64
# gcc index2.c -o index2.cgi

index2.c: In function `getFileLastmod':
index2.c:30: structure has no member named `st_mtimespec'
無知ですいません。どうしたらいいのでしょうか？

>>65
struct timespec ccc;
if(!stat(file,&CountStat)) ccc = CountStat.st_mtimespec;
return ccc.tv_sec;

となっている部分を、

time_t ccc;
if(!stat(file,&CountStat)) ccc = CountStat.st_mtime;
return ccc;

としてみてください。

>>66
修正前 index2.c.old
修正後 index2.c
としておいておきました。

>>67
/tmp/cc0XN3I3.o: In function `main':
/tmp/cc0XN3I3.o(.text+0x23d): undefined reference to `ap_parseHTTPdate'
collect2: ld returned 1 exit status
ですです。

>>68
Apache必要なのかな。。。

read.cgiの中にあるutil_date.[ch]をいっしょにコンパイルすればOKでは。

>>70
...そのためにわざわざ
ftp://210.170.170.118/incoming/index/
にその2ファイル置いておいたんだった(鬱氏
どなたか Makefile 作ってくだされ。。。逝てきますゆえ(謎

>>71
同じディレクトリに置きました

できたら、index.cgiとindex.cは別ディレクトリにしていただければ、と。

>>72
ありがとうございます。
>>73
ftp://210.170.170.118/incoming/index/c/
に移動したです。

>>74
ワーニング出てましたがコンパイルできましたです。
これから環境整えてみます。

かなり当てずっぽうで書きますが、>>41 をさらに突き詰めて、
index2.cgi が fork して、一方で apache にクライアントへの port forward を
指示させて終了、一方で forward 先の port 開くなり daemon に開かせておくなり
してそちらで出力、ってのは。。。304多い場合は無駄になりそうだ。

.htaccessで「Options +MultiViews」して、
圧縮した「index2.html.gz」と非圧縮の「index2.html.」(←末尾の
ピリオドに注目)を用意したとき、「index2.html」(←ピリオドなし)
へリクエストすると、Accept-Encodingに応じて適切なほうを
自動選択して返してくれます。
mod_negotiatinは標準で入っているはずなので、
これで同時起動プロセス数の問題は解決すると思いますが…。

ニュース速報板がindex2.htmに変わりgzipになりましたね。
ご苦労様です。

これが全部の板に広まって転送量が劇的に減れば
売り出しオークションを途中で止めるかもしれないので
なるべく完成させてください。

>>77
.htaccess のそれらの記述があの鯖ですべて設定可能かどうかがわからないのですが、
できるといいですね。。。

>>78
新cgiの稼働状況によってはオークション中止も有り得るって、、、、、、
それマジ？？

>>79
なんか mod_gzip や zlib のことを考えると、
AllowOverride None になっていそうで怖いですよね。

>>80
そういう話題はこのスレじゃなくて他のスレでやってね。

>>79
でも、kakoにpass掛かってるところをみると一応通るのでは?

>>82
http://www.he.net/~jdoe/info/htaccess/demo.html
http://www.he.net/~jdoe/info/htaccess/htaccess2.txt
これが絶対ではないけれども、無効にされる記述はかなり多いと覚悟した方が
よさそうです。。。

あの、subback ってどこかで改造しましたか？
<BASE> タグがあるのは構わないんですが、
<HEAD>〜</HEAD> の中に入っていないのでうちの browser ではリンクを正常に辿れません。

どれくらい転送量は減ったのら？

あぼーん

>>86
あ…あぼーん？？こんなところで(笑