レス数が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

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

ターンアラウンドタイムは落ちるね。

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

>>361
８月危機のときもそうだったけど、始めは詳しい状況がつかめなくて不毛なことを言い合ってた。
夜勤さんがUnix板に現れてmod_gzip導入不可というまでは。

今回も批判要望板で夜勤さんが2ch改造について言っているが技術的に詳しい説明をしていない
のでUnix板でもあまり実のあるやり取りが成されていないのでしょう。

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

ま、とりあえず、夜勤さんがくるまで、またーりしときますか。

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

>>365
　転送量の問題が出てくると思うが…。直感でｽﾏｿ。

>>363
　PHPだと、サーバへの負荷は軽くなるのですか？
　転送量とサーバへの負荷が軽くなるなら、一石二鳥と思うよ。また、別の問題が出てくると思うけど…。

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

PHPは3なら最初っから入ってたはず。8月の過去ログ参照のこと。
PHP4入れさせるのはおそらく無理でしょう。mod_gzipですら
揉めたんだから。

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

>>366
PHPがPerlより有効って言うのはどこから来てるの？
素人発言ですまん。

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

>>280

頼むわ。

いまのＲＤＢって、何ギガとかのデータですら入るんだから、
全部ＲＤＢの２ｃｈって面白いと思うぞ。

たしか、１フィールド１映画でＤＶＤの mpeg データをぶち込んで、
ＶｏＤを実現！、、、みたいな例がどっかにあったような気がする。
だから、１カキコ１フィールドでＲＤＢにぶち込んでいってもいいだろ。
というか、そのほうが、クラスタギャップの存在や管理の都合とか考えれば
ベターじゃないか？。
それに、そうすりゃ、レプリケーション機能を使って分散サーバも簡単にできるだろうし。

ぎゃくに、それじゃ無理という人は、その理由きぼん。

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

ここでPHP言ってるﾔｼは、read.cgiをCからPHPに書き換える、という話
をしているのか？それとも、bbs.cgiとか、削除スクリプトの話を
しているのか？

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

>>368
新参者の参加促進とできうる対応を今の内に話し合っておくのも無駄とは言えない。

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

>>371

>>363 読んでね
PHP4はすでに pc.2ch.net にはインストールされてるよ
他のサーバにはまだインストされてないのかな？

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

>>374
PHPしか知らないんじゃネーノ?

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

PHPだとWebサーバーの内部プロセスとして動作してくれるから
レスポンスとか負荷が多少軽減されるということだと思う。
Perlでもmod_perlというモジュールを使えば同じようにできるけど
PerlよりPHPの方がWebページを目的に作られた言語だから
PHPのほうがメンテしやすい。

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

>>378
違うプロセスを呼び出すオーバーヘッドと一旦HTMLを解析する必要のあるオーバーヘッド。
どっちが不利なんだろう。
Perlのコンパイル考えたら明らかに前者のような気がしてきた・・・。

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

なんつーか，SIの営業スレになってるな…．

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

>>380
逆にこれが成功したら日本の情報インフラが変わるカモよ。
SIとしてもおいしいじゃん。安く納入できるんなら。

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

>>380
ﾜﾗﾀ

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

なんでぇ。PHP入ってるなら、単純にPHPに置き換えればプロセス起動コストが減るやん。

>Server: Apache/1.3.6 (Unix) PHP/4.0.3pl1 mod_gzip/1.3.19.1a mod_ssl/2.3.6 OpenSSL/0.9.3a
mod_gzip も入ってるし、、、

# ポート番号指定するの忘れて、telnet上がってる事にいま気づいた。
#> Linux 2.2.20 (ch2www.he.net) (ttyp0)
#...2.4.10以降にした方がいいのでわ。。。

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

いっそeRuby！

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

この際、mod_2chでも作るか?

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

一番早い案は>44のｼﾞｬﾈｰﾉ

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

>>370
単位時間あたりの転送量は減ると思います。

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

あーもう耳がかゆい！！
まずは要件定義から整理してくれたたのむ！！
でないと、いつまでたっても話がループするだけじゃん！！
向上させなきゃなんないのは累積転送データ量？サーバ負荷平均？ターンアラウンドレスポンス平均？
でもってどこまで向上させりゃいーんだ？

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

デーモンにするなら、
1. デーモンは適当な名前付きパイプでCGIからの要求を待つ。
2. CGIはブラウザからのリクエストをデーモンへ転送。
受け取ったデータをブラウザへ戻す。

。。。CGIのサイズが小さくなると、起動のコストはそんなに減るのか？
httpdごと入れ換えちゃえって話しじゃないよな？

ただ、デーモン側でメッセージをある程度キャッシュできるメリットはあるなぁ。
2chだと、ほとんどミスしそうだけど。。。

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

>383
えらく古いな。＞Apache/1.3.6　Linux 2.2.20

つーても、バージョンageたところで転送量とか負荷が
変わるわけではないけど。

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

>>388
まったくだ。
何がボトルネックなんだ?

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

>>373
8月とは状況が変わっているかもしれないが、moduleを追加できないという前提だと、
RDBへの接続にかかる負荷が大きくなりすぎ。
逆にmoduleが入れられるならばmod_2ch作ればCPU負荷に関しては(apache捨てて
専用httpd作る以外では)最小になると思われ。

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

はっきり言うと金。

394 ：363 ：02/01/20 22:54

>>370

一般論としてはmod_perl を使わないのなら perlよりもPHPの方がサーバ内蔵
である分だけ負荷が低いと聞いています。しかし私は直接比較したことがない
からなんとも言えません。

このスレではサーバの仕様について憶測で話をされている方が
見受けられますのでサーバの情報を提供するため書き込みしました

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

>>365
ソケットをいじるってか。
いいとは思うがそれCGIだけの修正じゃできないと思う。

送るデータ量の削減＋送る回数の低減つのが8月の対策方法で、
前者はgzipで圧縮、後者はhttpヘッダーの活用にて実施。

いじれるところが前と同じ前提なら、
CGIの修正とhttpの活用しか手をいれるところがない・・・

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

いま迫っている問題は、８２６と同じく「転送量」だけだと思うよ。

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

>>388
現状での、運転状況が手に入らないと誰にも答えられる訳ない。
# ってか、本当にやばいのか？

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

>>396
では、取りあえずそれをメインテーマに話しますか。

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

激しく外出だが、ボトルネックは転送量。トラフィック。

CPU負荷ごときはどうにでもなる。速いサーバ、キャッシュ、L4 switch etc.
しかし、HTTPを使う以上、トラフィックの抑制には限界がある。利用者数に応じてリニアに増える。

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

>>388
とりあえず、(金かけずに)削れるもの全部削る。
目標: 出来る限り

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

>>396
　どうだろう…。結局、圧縮転送とかで、鯖にそれなりの負担がかかっていると思うけどなぁ…。

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

っていうか、ひろゆき＋夜勤さんにキャパ管とパフォチューの基礎を教えこんで、
レンタル屋と交渉してもらうしかないんじゃないか・・・？

つか、キャパ管とパフォチューできる奴手あげろ、
漏れは仕事でそれやっとるが、今回については自信がない（汗）

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

＞激しく外出だが、ボトルネックは転送量。トラフィック。
ｿｰｽﾀﾞｾﾔ

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

>390
かといってApache2系を入れるのは時期尚早でわ？
2ch的に魅力的なmodイパーイありそうだけど。
http://httpd.apache.org/docs-2.0/new_features_2_0.html

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

>>396
本当にそうなのか？聞いたのか？

406 ：>397 ：02/01/20 23:00

http://www.yakin.cc/
これが無料で維持されてること自体、通信事業者的に、奇跡。

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

>>401
CPUに負担がかかってれば、そこがボトルネックになるので、
ここから先は転送量の増大が見られないはずだよ。
（かなり高負荷だとは思うけどね・・・wで見てみりゃわかるけど）

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

結局やねぇ、転送量に対しては、やれる手ってのは、
もう８月危機の時にやり尽くしたんやねーの？

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

大学受験板のこの1はカンニングして高得点とったそうです。
しかも、恥というものがなく真面目にやった人間を馬鹿にして
喜んでいます。本当に屑みたいな奴です。許せません。
ＩＰ晒すなり、ウイルスなりどうぞ鉄槌を降してやって下さい。
http://school.2ch.net/test/read.cgi/kouri/1011496243/

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

read.cgiのスクリプトって入手できるのか？

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

今回は転送量ではなくCPU負荷が問題らしい。

---------------------------------------------------------------------
609　夜勤 ★　sage　02/01/19 20:59 ID:???
サーバの負荷が下がるかな?　と思って subject.txt , dat/xxxxxxx.dat の直読みに
制限をかけているのです。

ただし、Monazilla の方面には、それをかいくぐって subject.txt dat/xxxxxxxx.dat を
読める仕組みを説明させていただきました。既に対応しているツールもありますし
今改造をしているツールもあります。　少し待ちましょう。

MAC に関しても、ひろゆきさんがいろいろ手を尽くしてくださっています。
待ちましょう。
---------------------------------------------------------------------

412 ：411 ：02/01/20 23:05

とおもったが、サーバーの負荷 != CPU負荷ではないな。
転送量のもんだいなのか？

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

>>408
あとはもっと細かいレベルでやりつくすくらいか、ないだろうね。

板とスレの特性に応じて有効期限を調整するとか。

gzipよりもLHAの方が圧縮効率いいから、
ブラウザ側にLHA展開プラグインとか埋めこんでみてもらうとか。
（つか、そんなプラグインはおこさにゃないけども）

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

subject.txt
かちゅの自動更新用？

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

>>411
dat直読みは全部取得するから負荷がかかるということじゃねーか?

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

＞４１０
http://www.gedoh.org/aki/2ch/current/bbs/
CのCGIをスクリプトと称するのは激しく違和感あり。
そういう意味でのスクリプトはしらない。

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

>>411
これじゃ、何も言ってないのと同じだよねえ。

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

>>411
そのソースが真だとすると、
CPU負荷さげたら逆にまた転送量問題にならんかい？？
効率よく送出してしまうとこれまた困るはず。。。

マジでキャパ管とパフォチューの基礎を
彼らにたたっこんだ方がいいような気がする。

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

>>416
Perlスクリプトの方だ。スマン

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

サーバへの過負荷で板が開きにくいとかエラーが連発する
という問題は、いまのところなさそうだ。

サーバレンタル料はCPU負荷に応じて払うわけではなく、
グレードと台数と時間。かかる金を減らすには、単に台数を
減らすかプアなマシンにデグレすれば良い。
そしてより多くの板を少ない台数／プアなマシンででまかなう
ためには、今までのＣＧＩ群を軽く動くように改造する必要が
ある「かもしれない」。しかし今のところ、こういった話は
伝わってきてはいない。

つまるところ問題は2ch.netを出入りするデータの量。
転送量（従量課金らしい）をなんとかせいという話。

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

＞大学受験板のこの1はカンニングして高得点とったそうです。
＞しかも、恥というものがなく真面目にやった人間を馬鹿にして
＞喜んでいます。本当に屑みたいな奴です。許せません。
＞ＩＰ晒すなり、ウイルスなりどうぞ鉄槌を降してやって下さい。
＞http://school.2ch.net/test/read.cgi/kouri/1011496243/

こんな奴いるの？じゃぁ、俺も見られてたのかな(Ｗ
馬鹿な野郎だ。試験官に疑われたんなら、報告書があがるのに。

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

仮にPHPやらDBやら導入して10%くらい稼げたとしても，ユーザの
増加で数ヶ月以内にパーになるのは明らかでしょう．

ユーザの増加による転送料の増大，CPU負荷に合わせてシステム全体を
アップグレード出来る仕組みを作れなかった時点で敗北は決まってい
たと言えるでしょう．

おそらくこの時期に目的の不明確な改造を行うというのはビジネスモ
デル云々の話でしょうね．つまりは課金システムと．

2ch首脳陣は広告による収入システムを小馬鹿にしているし，1chがや
ろうとした小額決済に関しても懐疑的でした．今回モナジラ関連にだけ
情報を流し便宜を図ったことから考えても，彼らが狙っているのは
dat直読みリーダーのシェアウェア化でしょう．ベクター等で扱えば
決済のシステムを組む必要も無いし，数ヶ月たつと使えなくなり，有料
バージョンアップを促す仕組みを作れば，継続的な収入も得られます．

826の事件によりヘビーユーザは課金を受け入れる心理的な地盤が出来
上がっており，ライトユーザは今まで通り気軽に書き込むことが出来る，
というなかなか賢いシステムだと思います．

ただ，kageのソースを見るとID+PASSWORDによる管理も考えているよう
な雰囲気なので，その辺の発行システムをどのようにするのかは興味の
あるところです．

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

>415が正しいと思う。
CPUが限界なら転送量の最大値が更新されたりしないだろう。
回線にかかる負荷のことを言っていると思われ。

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

dat直読みのCPU負荷さげるんだったら、
バッファキャッシュ非経由にしてやるといーんだが・・・
マウントオプションは変更できんのだろうね多分

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

＞彼らが狙っているのはdat直読みリーダーのシェアウェア化でしょう
リーダーで2ch読み書きできる権利の販売では？
＃だからリーダーのシェアウエア化とはちょｌっとちがう

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

>>409
　それどころじゃない。

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

>>422
＞決済のシステムを組む必要も無いし，数ヶ月たつと使えなくなり，有料
バージョンアップを促す仕組みを作れば，継続的な収入も得られます．

無料と￥１の溝は限りなく深い・・・。

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

ftp.jp.FreeBSD.org みたくJPIXに直接設置はどうよ。
金払ってまでやってくれる奇特な人がいるかどうか知らんが。
国内trafficが殆んどなんだから、JPIXかNSPIXP2あたりでなんとかできりゃ転送量問題は無くなるんでないの。

ちなみにJPIX全体のtrafficは5Gbps前後。2chのtrafficが100Mbpsでも、誤差の範囲内。

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

HTMLソース眺めてみた。。
固定部分はJavaScriptつかって、クライアント側で展開するってのは昔良くやったけど、
本当に転送量が問題なら、これをやらないのはなんでだろ？
思ったより小さくならなかったとか？

JavaScript を on にさせたくないからかな？でも既に使ってるように見えるし。。。

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

＞金払ってまでやってくれる奇特な人がいるかどうか知らんが。
じゃあ、「漏れはタダでJPIXに1Gbpsくらいを2chの為に用意するぜ」
という香具師をみつけだせや。

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

２ちゃんを国営化する。

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

有料化よりJPIXに相談したほうが案外うまくいったりして(w

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

>>431
日本も安泰だ･･･

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

ftp.jp.FreeBSD.orgはGCTRがタダでやってるんだろ。
ディープな2ちゃんねらーがGCTRにいたら、意外と現実的かも。

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

ソニー板削除の条件でso-netに売り飛ばす．

という情報を日経にリークする．

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

分散処理って発想はないの？　＞ａｌｌ

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

....ちゃんとログ読んだのか？

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

だからここはスキルの高いLinux板にまかせましょう。

彼らの力でwww.linux.or.jpに置かせてもらえるさ（うふ）

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

>>436
8月のころはあったな。キャッシュ型負荷分散。
スレはどこいったかな？

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

>>436
どーやって運営するつもりだ？
無料＋短期間で構築可能か？

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

そうか、www.linux.or.jpがJPIXにあるのか!

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

分散ならだいぶ前から言われてるって

P2Pでサーバに依存しない掲示板を作るの巻
http://pc.2ch.net/test/read.cgi/tech/998915621/

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

つーか、光通ってる奴が鯖立てればそれで済むんじゃないか？

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

>>428
NSPIXP2 ってのはいいかもな。
「実験」っつっててきとーに名目つけて。

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

転送量増加で2ch閉鎖の危機だってよ。
http://pc.2ch.net/test/read.cgi/network/998697428/
でがいしゅつな話だな。

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

>>436
　コストの問題が浮上するのでは？もうちょい、詳細をｷﾎﾞﾝﾇ。

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

>>442
いや、もうちょっと単純に一つの板に複数のサーバを割り当てて同期みたいな小さい話。

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

>>443
じゃない。
上流でつまる。

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

光でも足りなくなり日が近々訪れる予感♪

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

>443 「transit peer」でも検索してからもう一度来い

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

396コの板の転送量の合計が88.9MBytes/Secか・・・
1板平均は230Kbytes/Sec

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

B fletsな有志にcache立ててもらうか…
特典として自串経由でカキコできる。

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

バックボーン寄りに10BASE onlyのブリッジを入れる。

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

>>452
　>>448､>>450の意見を参照せよ。

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

>>454
なんでだよ。bigserverの負荷だけ軽減すりゃいいんだろ。
他が詰まろうが関係ない。

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

>>455
遅かれ早かれ同じ問題が起きるだろ。

457 ：素人口出しｽﾏｿ ：02/01/20 23:44

dat直読みにしてread.cgiは使わない方が
負荷が少ないとばかり思ってたんだが

かちゅーしゃとかからのdat直読み＆連続リロードに対応する
だけなら、datを分割してしまうってのはどうなの？
1-1000を50区切りにして、最新50だけ独立datにさせて
monazillaのツールに対応してもらえば
かちゅでも安心して直読みできるという事になる

gzip効果を減らさないで済むかな
圧縮効率がどうか分からないけど・・・

そうすると普通にブラウザで呼び出すときに
read.cgiが重くなって逆効果とか･･･

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

>>454
同じプロバイダの奴をえらべばプロバイダ内が混むだけですむのでは？

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

小泉さんに頼んで、2chをIPv6 またはIPv6 over IPv4の実験台にしてもらう。
自然にみんなIPv6を使うようになり、日本の未来は・・・。

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

1. dat形式を改良して HTTP/1.1 Range: が有効利用できるようにする
2. 専用のプロトコルを設計し、差分が効率良く転送できるようにする

いずれにせよいつかはbigserverから引っ越す必要があると思われる。

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

>>459
後々しがらみができそう。
「あのときは助けてやっただろう。。。」

462 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 23:52

X-2ch-Range: 100-200
とかでdatの部分転送できるようにするとか。

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

>>461

2chと利権が絡んだりして．ひろゆき、政界目指す、とか。（ｗ

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

>>456
現状回避が最優先。
２ｃｈで増大したトラフィックが行き場を失って非2ch板をつぶし回るのは
目に見えてるからな。

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

readdat.cgiとかいう名前で、
datファイルの何行目から何行目までを取り出せるようにするCGIをつくるとか？

466 ：ヤヴァ！ ：02/01/20 23:56

レコード更新しそう・・・
http://www.yakin.cc/

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