結局、何も変わっていない！

結局、２ちゃんは危機を脱していないのでは？

変身

>>1
当然だ。何を今更。

またーく。ひとついえることは、2chがつぶれても
Unixは生き残るので問題ない。

ねぇ、ヲレApatchのことあんま良く知らないんだけど、リミッタかければ重くなっても、
とりあえず済む話なんじゃないの？ 実況も居なくなるだろうし。

>>5
「レスポンスが良い」というのがウリなので、そういう選択が出来ない
んだって...

>>5
そういう誰もがすぐ思いつくようなことはみんながいしゅつな。

当面の技術的な打開策はP2Pキャッシュによる方法(プログラム技術板で議論中)かな。
まぁこれもどうなるかはわからないけど。

システム全体の防御としてのリミッター設置はいいんじゃないかな？
無制限であれば、1回の転送量が減った分TPSがあがって、
結局また警告を受けてしまうだけなんじゃないだろうか・・・

>>9
でも、Apache に mod_gzip 入れるだけで揉めちゃうような
状況だからなぁ。cgi レベルではその手のことはどうにも
ならない…。

>>1
じゃあ、危機を脱するってのはどういう状況なんだい？
現状維持は案外簡単にできることじゃないんだぜ。

>>10
なんか銀行のシステム部みたいなこと言われるんですね（笑）
では、CGIでそれをやってみるのも手かもしれない。
受けプロセス数の最大値は制限されていると思うので、
CGI側で「意図的に待つ」ようにして流量をコントロール。
----
・CGI処理開始
・現在の同時実行数を`ps -ef | grep 2ch.net | wc -l`でカウント
・sleep [カウントできた実行数]/[規定の同時実行数]
・CGI実処理
・CGI処理終了
----
てなのどうかな？だめ？

>>12
そういえば、online trading system でも似たようなこと
いわれたりするなぁ:-)

ふむふむ。cgi の proccess 生成の上限は apache の
connection 数で決めて、cgi 側では sleep するわけ
ですか。確かに traffic の制限には有効ですね。

ただ、performance に多大な問題が出そうな気が…

>>13
そりゃ影響は出ます。

なぜなら、全体流量に制限がある以上、
単位時間あたりの処理能力[TPS] = ( 全体流量制限値[bps/日] / 86400秒 ) / 1要求あたりの転送データ量[bit]
となり、1度にさばける要求の数も有界となります。

単位時間あたりの処理能力[TPS]を越えた要求が、
テレホ時間帯などのピーク時に加わると、逆に全体流量が増えますので
「閉鎖するぞｺﾞﾙｧ!!」と相成ります。

そこで、今回は「1要求あたりの転送データ量[bit]」を、
圧縮して小さくした＋送る必要がないときは送らない
とすることで、全体流量を下げました。
（で、同じTPSをなんとか維持）

が、新たな利用者が増えれば増えるほど、TPSは上がります。
TPSが上がれば、また全体流量が増えます。

結局は、また全体流量の問題でｺﾞﾙｧ!!と相成るわけです。
ゆえに、今後は
・もっともっとデータ転送量を小さくする
か
・処理可能なTPSを下げる
の2つしかありません。

処理可能なTPSを下げる＝同時に要求を受けつける数が減る
ということになりますので、その数からあぶれた人は待たなくてはいけません。

無負荷時平均レスポンスを Trip[秒]と置くと、
Trip[秒]×1.5×平均処理待ち回数　これがピーク時平均レスポンスとなります。
（1.5は処理系高負荷時の処理遅延を表す係数←経験値）

なので、どうしてもそれは避けられないことだと思います。