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

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

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

2 ：ｆｄｆ ：01/08/26 22:53 ID:SdwXxj1A

変身

3 ：ていうか ：01/08/26 22:58 ID:QPwK/Rro

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

4 ：原住民 ：01/08/26 22:59 ID:Q.qAg7pg

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

5 ：名無し娘。 ：01/08/26 23:00 ID:twz4Cz0U

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

6 ：名無しさん＠お腹いっぱい ：01/08/26 23:07 ID:vmFgMi8s

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

7 ：名無しさん＠お腹いっぱい。 ：01/08/26 23:11 ID:T95KUHcw

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

8 ：名無しさん＠お腹いっぱい。 ：01/08/26 23:14 ID:A2H50SWY

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

9 ：名無しさん＠お腹いっぱい。 ：01/08/26 23:34 ID:BTalp81I

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

10 ：名無しさん＠お腹いっぱい。 ：01/08/26 23:36 ID:iy09H5/E

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

11 ：　fgh ：01/08/26 23:42 ID:ZpbZ8tZM

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

12 ：名無しさん＠お腹いっぱい。 ：01/08/26 23:53 ID:BTalp81I

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

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

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

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

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

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-)