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

41 ：35 ：02/01/20 01:15

ﾁｮﾄすまん。

read.cgi改良スレッド３
http://pc.2ch.net/test/read.cgi/tech/1002820903/

と話が錯綜して、よく把握できないっす。

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

有料化したら無料の所のドミノ倒しが再現するだけでは？

dat読み制限ってことは、
2ch依存症のヘビーヲタのリロードがかなりの割合を
占めてるんだろうね。
という漏れもxyzzy+2ch-mode中毒者（汗

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

>>40
非営利なサイトで88.9Mb/sは尋常ではないわな。
下手なサーチエンジン系サイトより多いかも。
クラスタリングや負荷分散が必要なレベルに
なってきてるっていることは間違いない。

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

いや、アレだろ。read.cが単独でlistenして、1プロセス毎に
30クライアントくらいずつまとめて面倒みるのが‥‥

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

dat読み課金だってyo!

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

1ch有料化と時期同じく2chも有料化。
あぶれた難民は在野に下るなんてシナリオどう？

ちたぁ粛清されんじゃねえか？

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

＞dat読み課金だってyo!
ブラウザで見れば関係ありませんね : )

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

>>43 キャッシュ・サーバも有効そうです。>>再読み込み方面

まっとうな専用キャッシュ・サーバは、
結構古めのHWに専用OS使っていて、スループットが高そう。
だけど、むちゃくちゃ高価。

っつうわけで、安くて高性能なキャッシュサーバを立てる
方法はないのでしょうか？

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

どれだけ負荷分散しようが、
同じサーバー群からデータが出ていくわけだから意味ないのでは？
それより、2ch専用のcacheサーバプログラムをつくって配布するべきだろう。

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

あと、祭り発生時、読み書きが激流のように発生している時、
サーバ←→キャッシュ・サーバ間のトラフィックを押さえる
方法はないのでしょうか？
HTTPの範囲指定GETを使うとか、専用プロトコルを使うとか..

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

>>49
ユーザ側に配布するのですか？
あるいは、ミラー・サイトやアクセス・ポイントみたいな話ですか？

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

カキコできるスレ →無料 誰でも読める
DAT落ちのスレ →有料、monazilla系のツールでしか読めない。IDとパスが必要
html化した過去ログ →無料 誰でも読める

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

！！！＞http://teri.2ch.net/test/read.cgi/accuse/1011457309/

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

>>40
1/14〜15のレコードは明らかに稲垣祭りだね。
冬厨時期と少しずれていたのが幸いだったかもしれない。
これが１週間早かったらと思うとゾッとする。

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

>>50
read.cgi側で、response headerに付けるキャッシュ有効期限を長くしたらいいんじゃないの。

>>52
「dat落ちのスレ」の何が問題なんだろう???
(「dat直読み」自体が問題なのかな。広告が出ないので)

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

>>55
> 「dat落ちのスレ」の何が問題なんだろう???
この課金法だとブラウザの人にとってはいままでどおりってことじゃない？

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

88.9MB/Secの転送量・・・
サーバ→クライアントの下りだけ考えてみると、

・http://pc.2ch.net/unix/のリロード(HTML部のみ) 76KB
　→約1198回/Secの転送

・このスレの最新50リロード(HTML部のみ) 14KB
　→約6503回/Secの転送

BIGIPだのキャッシュ鯖だの要るな確かに。

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

どっかのベンチャーからキャッシュサーバと回線を無償で貸してくれないかな。
あの2chの負荷に耐えたとなれば宣伝効果はあるだろう。
f4

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

>>56
そりゃそうなんだけど、
「専用ブラウザの人の『dat落ちスレ』負荷」なんて問題になる?

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

＞どっかのベンチャーからキャッシュサーバと回線を無償で貸してくれないかな。
＞あの2chの負荷に耐えたとなれば宣伝効果はあるだろう。
それってまさしく、８月破綻まえのモデルでは‥‥

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

>>55 キャッシュ有効期限を長くする
最新情報が見えなくなる→リロード→負荷増大

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

>>19

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

>>19がどうした?

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

UNIX板の面目を果たすために、
安価かつ高性能なキャッシュ・サーバの
構築方法を提案できたらいーな。

レンタル鯖 or WebProg板方面逝った方が、情報収集しやすいのかな？

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

トリップ持ってる2ch.netの人間が、要件を整理して提示しないと何ともならんな。
どこかにあるのかね。

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

＞64
行くなら通信技術板じゃないの？

でも正直今の2chはロードバランサやキャッシュサーバで
なんとかなるレベルを超えてる気がする…。
Big-serverも変なプライド捨てて素直に制限かけるべきと思う。

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

いずれにせよ対策方法自体を2ch.netの外にもっていかんと
前の破綻前と同じ路線の対策しか打てない
↓
今すでにキャッシュの有効期限決め＋データ圧縮をやってるものが
こうして動いている
↓
httpdとOSに手入れず、
gzip以上に転送データを小さくする方法があればいいけど。
↓
ロードバランサーでは2ch.netの出入りパケットが減るわけがない
（特定の板の処理負荷を減らすことができるだけ）
↓
キャッシュサーバを置いてもクライアントへ出ていくデータが減るわけではない
（httpdの処理負荷減らすだけになる）
↓
あぼーん

68 ：sage ：02/01/20 02:37

>>57,>>66
祭り発生状態の板/スレだけ、
ピンポイントで制限 or キャッシュ＋負荷分散できたら、
他の板の住人はちったーしやわせになれるんでわ？

69 ：sage ：02/01/20 02:38

>>67 回線占有幅が問題なのですか？

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

主に汎用ブラウザ(IE,NN)方面について、
HTTP圧縮はサポートしていないのでしょうか？

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

＞70
その話は5ヶ月前に既出。
すでにread.cgiが実装してる

72 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 02:47

パケットシェーパー入れるのが手っ取り早いんじゃない。

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

ひろゆき曰く、祭り自体は大した問題ではない。
その後に新参者が定着し転送量が高値安定するのが問題。

gzip化で時間稼ぎの間にP2P実用化、のシナリオ通りには
やっぱ行かなかったね。半年しか持たんとは。

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

とりあえず、ここいらみて8月危機を復習しとけ。
http://hpcgi1.nifty.com/BWP/diary.cgi?action=view&date=20010830

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

しかし逆に考えれば
これだけの巨大な情報システムが
草の根ネット的に無料で運営されてきた
というのもすごいような

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

結局今回問題なのは転送量かサーバ負荷かどっち？
サーバ負荷ならあの人の言うとおり mod_perl 入れれば少しは
マシになるのでは。

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

つーかさ，寒波募集したら？

78 ：49 ：02/01/20 02:57

>>51
後者です。
だれか作ってみない？

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

「転送量」は単なる指標に使っているだけなのか、
それとも「通信回線の帯域圧迫」>>「サーバのCPU、I/O負荷増大」と理解していいのか?

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

UNIX板で2chの問題を解決しようというのは反対。
また変な感謝age荒らしが来たらたまらん。

81 ：山師 ：02/01/20 03:01

CPU足すわけにもいかんし
エンタープライズ系が使えるわけでもないし
サーバー増やすのは限界だし
modぶち込むには、HE社の技術を説得せんといかんらしいし（できるかもしれないけど、交渉が必要　すぐにはできないらしい）

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

>80
おまえ一人の殻に閉じこもってろよ。
他人とコミュニケーション取ろうとするな。

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

>>80
今回はまだ何もしてないのに感謝age荒らしの心配なんかするな。

84 ：呼んだ？ ：02/01/20 03:10

感謝age

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

こういう２ｃｈの状態はインターネット業界みんな起こりうる状態で
あって、注目に値すると思うぞ。

ただ単純にサーバ増やしたり、回線を増やすことを考えるのではなくて
少ない資源でどう対処するかを考える事も技術の進歩になるのだから。

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

ITバブルの頃って、
取らぬ狸の皮算用で過剰投資が問題になったが、
現実にビジネス・モデル＆負荷問題が起きている例で、
どうやって問題解決していくか、
漏れもケース・スタディーとしてすごく興味がある。

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

あのflashでいってた、「いつか限界がくる」の
その限界が来そう、って事だろ。
鯖の力を増やせば、その分帯域も喰うから、
いっぱいいっぱいの状態にしてある、って話も
きいたぞ。

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

つか、２ちゃん救うことに意義が見つけられない・・・

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板を
閉鎖することによって負荷を軽減させると思われ｡

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