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

1 ：名無しさん＠お腹いっぱい。 ：01/08/26 22:51 ID:eFYpdjAc

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

14 ：名無しさん＠お腹いっぱい。 ：01/08/27 00:13 ID:gI46IMVY

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

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

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

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

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

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

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

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

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

read.cgi ver5.26+ (01/10/21-)