レス数が1000を超えています。残念ながら全部は表示しません。

[深刻] ２ｃｈ負荷問題ふたたび勃発

1 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:05

８・２６問題が再浮上かも。
http://teri.2ch.net/test/read.cgi/accuse/1011385033/
「いよいよ　何らかの手を打たなきゃどうにもならん状態になってきたようです」

関連ネタ
http://pc.2ch.net/test/read.cgi/tech/1002820903/360

89 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:21

>>86
けど実際問題コードチューニングするのも限界があるし、
まして今安定稼動してるシステムに手を入れる暴挙なんて極力避けたいしなぁ。
負荷問題の解決方法は結局のところマシンのリプレースしかないと俺は思うんだけど。

90 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:24

SE or コンサル感覚でいくと、
結局ビジネス・モデルの確立が、
問題の根っこにあるとは思う。

３リオで、ギコネコ・キャラクター商品売って見るとか...

91 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:26

>>80,88
なんか自慢げな書き方だなあ。お前が2ch救えるわけでもないだろうに。
技術的に興味のある話題ってだけでいいだろ。

92 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:27

>88
>つか、２ちゃん救うことに意義が見つけられない・・・
そう考えずに、こういうケースが目の前で動いてるって
考えればいいんでは？

こういう状況ってなかなか作れるものではないと思うのだが。

93 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:31

まずは性能モデルでもつくってのんびり眺めてみては？
構成が見えんのがツライところだが。

94 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:36

>89
確かに。
でもまだやれることは本当に無いのだろうか。
インタラプタ言語をやめるとか、プログラムで無意味なループの
処理を最適化するとか、不必要なデータファイルを消去または、
DATテープに移すとか．．ｅｔｃ．

95 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:38

だいたい、半年前と状況は変わってなくて、
対策打ってその効果が目減りしただけ。

そろそろ技術うんぬんの話でもなくなってきた模様と思うが・・・

96 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:39

>44のとかどうよ。forkが1/40になったら、だいぶん効くと
おもわないか？

97 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:39

>>74 感謝!!

あと、こっちも参考になりました。
ttp://home.att.ne.jp/wind/monsta/ga/2ch_kiki.htm

98 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:41

>>95
やっぱりそうなんだろうか･･･。
俺もずっと考えてたんだけど、俺の頭じゃ･･･。

2chうんぬんはまあ、いろいろあるけど、
純粋に技術的におもしろいと思ってみてたんだけど。

99 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:41

>>94
それやっても通信データ量は削減されない それも半年前と同じ。
CPU使用量とDASD使用量をさげても問題は解決されないのです。
データそのものの大きさを減らす→利用者数が増加している局面では
　　　　　　　　　　　　　　　　効力に限りあり
データそのものの入出力回数を減らす→キャッシュされにくいデータを
　　　　　　　　　　　　　　　　　　扱う場合、あまり減らせないことが多い

100 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:42

>>96
効いてしまってますますデータ転送量が多くならないか？

101 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:44

read.cgiをmodにする。ってのはやっちゃいけないのか。。
apache捨ててhttpdを自前で作るってのは？

102 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:44

とりあえずLinuxやめてSolarisにでもしてみい。
元々Linuxは限界付近の挙動が怪しげな上に、kernel 2.2.20じゃSMP
マシン使ってる意味が無い(全部では無かったかもしれんが)。
2.4系はもっと怪しげだし。

103 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:45

過去ログへのアクセスは
googleのキャッシュ/web.archive.orgに転送。

104 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:46

そうなるとこのケースはサーバと回線を増やす以外方法がないのでしょうか？

105 ：102 ：02/01/20 03:46

あ、転送量の方も問題なのか。しつれい。

106 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:46

CGIでの要求応答で、2〜4回に1回、1秒ほどsleepするのはどーだろう。
毎回sleepされたらレスポンス問題になるが、
2〜4回に一回、ちょっと遅くなる程度であれば
案外人間気にしないんじゃないか？

107 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:47

で、プロセスが爆発して、メモリは足りなくなり、apacheはあっというまに
MAX_CONNECTIONまでいって、接続を待たされる、と。

108 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:49

>>106
レスポンス落とす系の案は前回の時にも出たが、夜勤に却下されてる。

109 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:50

半年前に削減したときよりも転送量が多くなってるということは・・・

半年前のサーバには、少なくともCPU高負荷が問題ではなかったはず。
（問題だったらそこが処理上のボトルネックなのだから、
　転送量が増加してまた問題にならないよね？）

110 ：山師 ：02/01/20 03:50

>>101
TUXとかかい？
http://ns1.php.gr.jp/pipermail/php-users/2001-September/002301.html
動的なページに効くかどうか知らんが･･･。

111 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:50

Linuxなら、RedHatのTUXとかいいんでないかい？（既出？）

112 ：山師 ：02/01/20 03:51

げ、かぶった

113 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:52

>106
アクセスピーク時には結構響きそうだな．．
＃CONNECTできない言いそう。

114 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:56

>>107
vmstatのreが増加してプロセスが増える分にはいんでない？
それにhttpd自体そんなにでかくないし、
あれってa.outのプロセスじゃないんでしょ？メモリは大丈夫。

が、httpdのプロセス数上限にひっかかるので、そこはそのとおり。

そういえば半年前はクライアント側の接続待ちもダメつってたね、
夜勤さん。。。

1. 転送データ量を減らす
2. その対処の結果、
　　ブラウザ側でがタイムアウトになったり、
　　レスポンスが顕著に遅くなったりしてはならない
3. 利用者数は月日とともに一様増加するので、
　　スループットも同様に一様増加する。

　　

115 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:58

>>110
PHPってすげー便利そうですが、本当にベンチマークいいんだろうか？
www.SourceForge.org とか、自前のUltra-10 にSourceForge 入れた
感想として、「レスポンス悪い」って印象持ったんですが。

TUX+PHPとか使うと違うのかなぁー。

116 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:04

DiskAccessをいかに減らすかって重要ですね。
Memoryをいっぱい積んでmfsって可能かなあ。

117 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:08

ピークになったら、106で書いてるsleepの代わりに、
「ごめんよ〜いま大変込んでるの・・・」
ってhtml返答してあげるつーのもだめ？
その返答が妙に短い時間で処理できてしまうと
その返答が数多く発生してナニかと思うのでnanosleepでms単位に調整とるとか。

したらブラウザで「接続できないぞ」「タイムアウトがでるぞ」ってのはないし、
サーバレンタル屋の気持ちになって考えてみても、
http的には問題なく伝送できているからウチのマシンのせいじゃないもんね
ってことでタテマエ上問題にはならんはず。

118 ：山師 ：02/01/20 04:13

>>115
PHPそこそこ早いよ。特にPHP4になってから劇的に早くなった印象がある
TUXもちょっと試したところじゃ確かに早い
でもTUX+PHPってどうかな？　安定性も未知数だし

その前に鯖屋（HE）が嫌がると思うけど

119 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:17

＞117
そんなものが宣伝になるか。

120 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:20

>117
>ピークになったら、106で書いてるsleepの代わりに、
>「ごめんよ〜いま大変込んでるの・・・」
>ってhtml返答してあげるつーのもだめ？
これを実現するにはやはり負荷分散装置が必要かなあ。

これは要するにサーバの状態を監視してて、いっぱいいっぱいならば、
違うサーバが「大変混んでるの」ページで応答することだけど．．う〜ん。

＃２ｃｈねら〜がそれで納得するかは疑問。

121 ：山師 ：02/01/20 04:22

>>106,>>120
リロードが多発して大して変わらないと思われ

122 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:26

リロード対処には、やはりキャッシュサーバしかないのでしょうかね？

123 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:32

>>72 パケット・シェイパー (帯域制限する機械)
と sleep 入れる方式と、どうちがうだろーか？

124 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:33

>>122 書き込みが頻発せず、
かつアクセスが一部のスレへ集中していれば、
効果あると思います。>>キャッシュサーバ

125 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:44

・・・

126 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 04:55

>>123
全然違う。sleep入れたってhttpが走ってる間は全速力でパケット流れるでしょ。
帯域制限なら、50Mbpsまでと決めれば、RWINサイズとか動的に変化させて
ほぼそれに落ち着くと思われ。

大体、sleep 1秒入れて何がどれだけ減るのさ？
httpdのプロセスは複数起動してると思うし。

127 ：名無しさん＠お腹いっぱい。 ：02/01/20 05:05

ぁそゆこと？

転送量増減に合わせて、動的にsleepの確率＆時間とか調整するのかと思った...

sleepの確率＆時間が固定では、ほとんど効果ないんではないかいな？

128 ：名無しさん＠お腹いっぱい。 ：02/01/20 05:23

そんぢゃー、パケット・シェイパー ﾏﾝｾｰ

129 ：名無しさん＠お腹いっぱい。 ：02/01/20 06:21

結局2chに貸してるとこだって自前の鯖じゃないんだから
小手先の対策しかできないんじゃないかなと。

130 ：名無しさん＠お腹いっぱい。 ：02/01/20 08:22

提案

１．PerlでCGIではなく、mod_perlにする。（CPUネックの場合）

PHPにするという手もあるが、急ぐ場合はmod_perlでいいのでは？

２．datファイルを見直す。

datファイルって読むときflockかかるんでしょ？このLockの粒度を小さくするためにRDBMSやDBMをいれて、１メッセージ単位でLockをかけるようにする。

131 ：御伝言 ：02/01/20 08:52

>>81 参照

ついでに、
>>67, >>73, >51, >>78 のあたりもおねげーします。

132 ：名無しさん＠お腹いっぱい。 ：02/01/20 08:57

ぅあ、2. は
どっか(fj?)でdbm+Perl掲示板を嘲笑する記事読んだ覚えあり。

つか、dbmベースじゃ、お祭り状態の2チャンネルは実現できないっしょ？
＃濁流のように書き込まれて、あっという間に1000スレになる(藁

133 ：名無しさん＠お腹いっぱい。 ：02/01/20 09:12

>>126

ちょっと違っている。sleep入れるとパケットの受信が遅くなるから、正常なTCPの実装なら自律的にRWINサイズは小さくなる。
ただ、帯域制限だと、どの程度の帯域かを指定できる。

134 ：名無しさん＠お腹いっぱい。 ：02/01/20 10:09

鯖側ばっかだけどクライアント側(操作)に制限(リロードタイムインターバル)
とか　ちゃちゃってかけることできないの？

135 ：名無しさん＠お腹いっぱい。 ：02/01/20 11:00

それって、HTTP標準にあるの?

136 ：名無しさん＠お腹いっぱい。 ：02/01/20 11:26

まず過去ログを2chの外に出そう。
MXで交換すればいいだろ。2chにsum置いといて偽造防止。

137 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:03

>132

＞どっか(fj?)でdbm+Perl掲示板を嘲笑する記事読んだ覚えあり。

どんな骨子なの？
<>をデリミタにして1000件ものデータを読み書きするのとどれがどうだっていうのか気になるところ(笑)

138 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:27

デリミタはtabに変更しよう。
または固定レコードにするとか。

139 ：132 ：02/01/20 12:47

>>137 元ネタは検索中. 元CSL現琉球大あたりの「有名人」の、1997年頃の発言。

骨子は、というと、
(1) 近頃Web掲示板とか立てている人多いけど、
　　NNTPプロトコルで負荷問題扱ってた人から見ると、
　　まじめにパフォーマンス考えてるのか？と突っ込みたくなる。

(2) たとえば、CGI+dbm+flock で実装している場合、
　　毎回dbmロードして、flockで排他制御かけてりゃ、
　　パフォーマンス悪くて当然。

(3) 通の選択は、DB管理専用デーモン立てといて、
　複数のHTTPリクエストを複数のCGIで受けて、一つのDBデーモンに処理依頼する。
　CGI-デーモン間の通信は、共有メモリ＆排他制御(か、ソケット)を使う。
　これが常識。

てな感じでした。

140 ：もなー君@お腹いっぱい ：02/01/20 12:52

>29
Linux板の住人に頼んだら、Win板とUNIX板を
閉鎖することによって負荷を軽減させると思われ｡

141 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:53

木形式のクライアントサーバモデルって感じ？

１つデータベースを用意して第１〜第８2chで共有みたいな。

142 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:55

>139
ありがとう。
んーでも、それも一長一短だよね(笑)

143 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:58

>>139

ドテ。プレインファイルよりdbmの方が効率が悪いってリンクが張られるのかと期待していたんだけど。
デーモン用意してそこで集中制御した方がパフォーマンスいいの、そんなの当たり前じゃん。（ぷ

そんなややこしいことするより、きちんと行LOCKされるRDBMSを使った方がいいのでは？

144 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:01

いっそ独自プロトコルを作る。
これなら圧縮し放題。
かちゅ〜しゃの様なクライアントを作って希望者はそちらを使う。
httpと平行させても多少は軽くなるのではないか？

145 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:06

RDBMSに一票

146 ：139 ：02/01/20 13:06

ウチが数年前に作ったBBSですと、Oracle WGS＋RMIサーバ＋Servletですが何か？

147 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:15

問題点を整理しましょうよ。

1) 転送量が大きくて困る
2) CPU 負荷が高くて困る
3) どっちもで困っている

前回は 1) が問題で、CPU 負荷はどうでもいいから転送量を下げることを目標にしたんだよね。

148 ：139 ：02/01/20 13:16

一応マジレスしておきますと、

>>142 Perl+dbmの方がステップ・アップする良い指針だと思ったのですが、
短所はどういう所でしょうか？
＃DBデーモンの数は複数、forkして処理、readは排他しない、とします。

>>143 現在の２チャンネルは、デーモン方式なのでしょうか？
あと、RDBMS使うのは良いとして、
大きなテキストの格納とか、検索性能とか、全文検索とか考慮した場合、
２チャンネルの場合どのRDBMSを使うのがよいでしょうか？

XML-DBとか出てますが(藁

149 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:16

>>147
2)フルアセンブラとか？安易だが。

150 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:17

>>146 負荷問題なら Servlet という手もあるかもしれない。
でも夜勤さんがオッケーしないかもしれない。

151 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:18

>>147
0) ビジネス・モデルが確立していないので、費用負担に限界がある.

152 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:21

データベースサーバ（夜勤さん）−複数の低負荷CGI（有志）

153 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:24

>>147
1),2),3) 負荷テスト・ツールを使って、
テスト系で性能測定＆パフォーマンスチューニングすべき＞＞夜勤さん、ＨＥさん

速度パフォーマンスを売りにするなら、
回線帯域幅とサーバ数だけじゃまずいんじゃないかなー

154 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:26

CPU負荷を下げる場合でも、まずは、何がCPUに負担をかけているかを分析した方がいいのでは？
たとえば、祭り状態のとき、

1.一つのdatファイルに集中してアクセスされる。
2.datファイルを得るのは1プロセスで、他は当然に待ち状態になる。
3.forkがいっぱいおきる。
4.メモリの使用率が増え、PAGINGが増す。

なんてことも仮定できる。

155 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:27

ここってSolaris？

156 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:28

>>155
IIS

157 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:30

>>155
まじ．．．？

158 ：名有りさん＠お腹へった ◆fSunOs.U ：02/01/20 13:32

現行HTTPの状態でも　まだある程度転送量削減の余地はあると思うんだよね
去年８月の騒動の時にも指摘していたのに　放置されたままだったんだけど......

それは　read.cgiは"Last-Modified"吐くようになったけど　各板の*.htmlは吐いてない
ということなんだよね　恐らく*.htmlが"server-parsed"になってるためだと思うんだけど
なので

・　"server-parsed"の必要がなければ切る
・　広告の挿入等のため"server-parsed"の必要があるのなら　.htaccessで
　　　XBitHack full
　と指定した上で　各*.htmlファイルのパーミッションを"g+x"にしておく

という対処で　*.htmlでも"Last-Modified"吐かせることができるはずなんだけど


あと　OSの入れ替えというのは困難かも知れないけど　もし可能であって
マシン負荷が問題というのなら　Linuxから*BSD or Solarisに入れ替えると
いうのも考えられるけども......

159 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:38

>>152 2ch.netの外に、キャッシュ・サーバ作るという感覚で、いいんでないかい？

160 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:44

>>154-158
たしか2chはLinux+Apacheだったはず
で、夜勤さんのレス見る限りでは現在問題になっているのは転送量だけ
みたいだね。
loadavg見た訳じゃないけど、恐らくCPUはかなーり暇してるんじゃないかな？

161 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:47

2chの運営で利益がでるのって広告収入だけだよね？
とりあえず、広告をなんとかした方がいいかと
あんなんじゃ誰も見ないし、常に右端に表示されるとかでないと・・・

現状の方法では、どんな頑張っても何ヶ月も持たないと思う
ビジネス・モデルをなんとかせんことにはいかんともし難い

162 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:50

転送量って言っても、これ以上の圧縮は難しそうだな。

163 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:52

とりあえず、事業化の方向だそうだ。
http://yasai.2ch.net/test/read.cgi/event/1011398301/

今回の騒動は事業化への布石（ｼﾞｻｸｼﾞｴﾝ）かもしれない。

164 ：転送料金 ：02/01/20 13:55

>>161
2ch_browser + Web < Web広告収入
まで持っていかないと2ch_browserに移行した際にWebビュー数と
広告収入が減少してかなーりヤヴァイ状態に成るんじゃないかな？
だから
2ch_browser + Web < 2ch_browser広告収入 + Web広告収入
という図式が確立出来れば良いんだけどね。。。
でもオープンソースソフトに広告を載せるのは難しいよねぇ。。。

165 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:57

htmlやめて、curlでも使えば？(藁
http://www.curl.com/html/

166 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:58

>>164
2PL(GPL)みたいなの作ってここからの広告表示を必ず表示。
・・・無理かなぁ。

今でもカチューシャ分は食いっぱぐれてるんだよね。

167 ：sage ：02/01/20 14:04

とりあえず、無駄な画像（背景画像など）を消すとか、htmlコードを最適化するだけでずいぶん違いそうな気がするのだが。

168 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:08

>>167
ローカルホストにsquidを入れるとか(藁
でもsquidってせいぜい20%程度なんだよね。。。

169 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:09

ようは事業化のためで、既に決定されていたことみたいだね

206　切込隊長 ★　sage 　Date:02/01/20 09:48
>>204

　現実面では、とりあえずマニア店、広告あたりがデフォルトスタート
ですね。発表のタイミング次第では、交渉がまとまったものも同時に
告知できるかもしれません。

　まあ・・・法人化という意味では、２ちゃんねるを法人化せずに、
２ちゃんねるの外部に会社を作ると言うコミケ方式でいこうかと考えて
ます。ともあれ、俺はひろゆき抜きの事業化は考えないので、立ち上げ
て軌道に乗るまでのお付き合いかと思います。

>>205

　ある程度決まってから意見を聞かないと無責任かなと。
　あれいいね、これいいねでは何も進まないのを恐れていました。

　それと、少人数で事業化を進めてきたので、取りこぼしたアイデア
やリスクを考える意味でも広く意見を引き続き伺いたいと思っている
ところです。というのも、寄付の議論でもありましたように、やはり
規模がまだそれほど大きくなければ寄付でいくのがベストだというのは
早期から分かっていたことで、今できないのはやっぱり後悔してる
部分でもあるんで。

　あと、夜勤さんの負担の問題や、削除人の皆さんへの還元などを
どうするかということですかねぇ。まだこの辺は詰め切れてない部分
ではあるのですが。

　ともあれ、転送量問題から半年で事業化のめどを立てるという
目標は達成したので、後は収益性、採算性の検算をどうするかに
頭が逝ってます。

170 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:11

転送量

http://www.yakin.cc/

171 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:19

そろそろJava使いにサーブレットで作ってもらうか（藁

172 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:21

>>171
その前にプロトコル考えてくれ！
何で作ろうとHTTPDに乗っかったままじゃあんまりかわらん！

173 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:23

>>172
同意。ボトルネックはhttp+gzip

174 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:24

2chへのアクセスしか許可しない設定でhttp proxyをそこら中にたちあげるってのは？
無料ではやれないか、、

175 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:28

>>174
その串にどう人を分散させるかも考えないとね。
でも、即時性がウリの2chにキャッシュサーバを置くのはどうかと。
結局みんなリロードしまくって・・・。

176 ：宇多田ヒカルさんの将来の旦那ですヽ(`Д´)ﾉｹｯｺﾝｼﾃｸﾀﾞｻｲ ：02/01/20 14:28

http://www2.odn.ne.jp/~aaq77600/unix.swf
　
頑張って
　
癌歯って・・・・・・

177 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:32

やっぱp2pキャッシュかなぁ〜

178 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:33

>>177
デコードプロキシとか。

2ch->超高圧縮ファイル->デコードプロキシ->html->PC

179 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:37

NNTP の実験はどうなったんだっけ。

180 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:44

>>177 p2pキャッシュの動向を教えて！！

181 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:45

>>180
http://pc.2ch.net/test/read.cgi/tech/998915621/l50

182 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:46

>>181
あ、これ次期2chの話だったんだ。

183 ：squid ：02/01/20 14:48

>>175
reload_into_ims on
これだけでリロード対策OK!

184 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:50

>>183
後はどうやってプロキシごとに限りなく最新の情報を得るかだね。
一分ごと更新？

185 ：宇多田ヒカルさんの将来の旦那ですヽ(`Д´)ﾉｹｯｺﾝｼﾃｸﾀﾞｻｲ ：02/01/20 14:54

http://obuchi.naikaku.com/angriff/upred/source/2117.jpg
↑次期主力型２ちゃんねるサーバー状況　FILES　NO.01
　
どうよ？

186 ：squid ：02/01/20 15:02

>>184
reload_into_ims on
にするとsquidが勝手に Pragma: no-cache を If-Modified-Since に
置き換えてくれるから大丈夫だと思うけど。
つーか、read.cgiはそのままでもHITしまくってるので
単に串入れただけでも結構効果有るんじゃないかな。

187 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:04

>>186
なる、納得。おてがるに対応するなら手だね。

188 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:12

専用ツールのみアクセス可とかカードを使った有料化は
存続のためにはやむを得ないのかもしれないが、それを
やった時から2chではなくなってしまうような気がするなあ。

厨だDQNだヒッキーだと罵られつつも、誰でもどこからでも
気軽に参加できる（＝ごく普通のWebブラウザが最低ライン）
というシステムが、常に新しい大量の水（きれいとは限らないがｗ）を
2chの中に流し続けていた。堰を造って治水を始めた瞬間から、
規模だけでかい、生ぬるく腐敗したそこらへんのWeb掲示板に
成り下がってしまうような気がする。
そして最後はfjやNiftyフォーラムと同じ運命を．．．なんてね。

技術系の板で書くことではなかったな。スマソ

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