5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :名無しさん@お腹いっぱい。:01/08/26 22:51 ID:eFYpdjAc
結局、2ちゃんは危機を脱していないのでは?

2 :fdf: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は処理系高負荷時の処理遅延を表す係数←経験値)

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

5 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)