■新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!? Part1(2ちゃんねる)

FTP、CGI、SSI、telnetが自由に使える超高速レンタルサーバ。
工夫しだいで、楽しさ100倍。 www.binboserver.com
月額千円サーバ | サブドメインコース | BIGなサーバ

サブドメインコース:CGIやFTPが使いたい・お金を掛けたくない人のために。
 *****.syo-ten.com *****.gasuki.com *****.zansu.com
 お好きな名前を無料で使えます。早い者勝ち。

人気サイト 月額千円サーバ:.com .net .org で取得できます。.JPドメイン大歓迎!
 超高速・高機能サーバを1000円で!使ってみれば、分かります。

BIGなサーバ:Big なBig なサーバー。充実したサポートをお求めの方へ。
 インターネットでご活躍の皆様へ、そしてご活躍予定の皆様へ。
2ちゃんねるは、このサーバを使っているです。

■掲示板に戻る■ ■過去ログ倉庫めにゅーに戻る■

■新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!? Part1
1 名前: FOX ★ 投稿日: 05/01/07 03:19:00 ID:???
■ 新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!?

巨大Live専用サーバの構築

live系のサーバは台数投入したところで、ほとんど遊んでいる
サーバ + 一台の負荷が高くてアクセスできないサーバという
悲惨な状況になっちゃうので、複数のサーバを巨大な一台と見立てて
なんとかならんものなのかを模索するー。

【Step1】四台のbananaサーバで 現 live8/live16/live18 を全部収容する。



2 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 03:19:16 ID:hq0BGd3C

         |三|
       /■ \
       |´∀`  | オニギリュキダルマガ2ゲト
   ★   ヽ__ノ   ★
     \ ミ≡≡彡 /
     /    巛  ヽ
      |         |
      丶        ノ
      \___/
⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒



3 名前: その他 ★ 投稿日: 05/01/07 03:19:27 ID:???



4 名前: 南アルプス ◆98YENoslbU 投稿日: 05/01/07 03:20:14 ID:HlCyIUwW
今ここに醜い自演を見た。


5 名前: ひろゆき@どうやら管理人 ★ 投稿日: 05/01/07 03:20:37 ID:???
mysqlがクラスタリングのモデルだしましたけど、
あれはどうなんでしょう?



6 名前: その他 ★ 投稿日: 05/01/07 03:22:19 ID:???
汎用は所詮汎用だと思うなぁ、、、


7 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 03:23:06 ?# ID:???
(n‘∀‘)η


8 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 03:26:35 ID:pqmq0YTE
誰も言ってあげないみたいだから言ってあげよう。






>>1


9 名前: じじぃ その4 ◆HETAREzfq. 投稿日: 05/01/07 03:28:06 ID:CcqiS2fj
とりあえずbbs.cgiのsubject関係とdat関係の処理を明示的に分離しるんけ?
ようワカランけんども


10 名前: root▲ ★ 投稿日: 05/01/07 03:28:46 ID:???
いきなり第一ステップから「全部収容」すかぁ。
さて、どの持ち駒をどう使っていこうかなと。

>>3
さすが、流行に敏感。


11 名前: マァヴ ★ 投稿日: 05/01/07 03:31:43 ID:???
あー、3年くらい前に構造を色々考えたことがあった気がする(^_^;)
あの頃とはかなり様相が変わったんだよね・・・・
能力を分割するとしたら
・bbs.cgi
・disk I/O
・read.cgi
の3つかな?


12 名前: その他 ★ 投稿日: 05/01/07 03:34:35 ID:???
banana227 を bqckend にして
live14/live18 あたりを front にしてbasicなものを組んで
試行錯誤してみようかな、、

banana227 の root pw を明日になったら送りまーす >>10
banana386 と
banana613 は最初は単に virtualhost 作ってラウンドロビンしてみよう


13 名前: マァヴ ★ 投稿日: 05/01/07 03:37:07 ID:???
bサーバ、dサーバ、rサーバと仮に名前をつけると味気ないので
弘法・聖徳・空海と名づけるとしよう(^_^;)

まず聖徳の仕事
 弘法から投げられた書き込みをひたすらメモリーに書き込む
 空海から呼びだしを受けたら、どんどんdatを投げる
 1000に達したスレッドはガンガンディスクに書き込んで、メモリ上から消す

こんなかんじ?


14 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 03:39:27 ID:7j1zguJR

cgiはそれぞれのサーバーに
datは4台のサーバーにRAID5(6?)の様な感じで格納ってなるの?
>>1を見るだけでは良く分からないけど

って書いていたら>>11-13が書き込まれたけど....俺の脳みそではヨクワカラン


15 名前: root▲ ★ 投稿日: 05/01/07 03:40:58 ID:???
基本コンセプトは
「読み手担当と書き手担当を完全に分離することにより、効率をアップする」です。
すべては、ここから。

>>12
了解。


16 名前: マァヴ ★ 投稿日: 05/01/07 03:43:38 ID:???
弘法の仕事(^_^;)
 ラウンドロビンでたくさんたてて、どこに書き込みが来ても適切な聖徳に渡す
 やってきた書き込みが正当かどうかのチェックをする(聖徳は書き込む以外やらないですむように)

空海の仕事
 ラウンドロビンでたくさん立てて、どこに読み出しが来ても適切な聖徳からdatを取得する
 読み出しの要求に対して、聖徳からdatを引っ張ってきて、htmlに変換して吐き出す
 一定時間(10秒程度?)はキャッシュして、聖徳への呼びだし回数を減らす

こんな感じ?(^_^;)


17 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 03:44:11 ID:pqmq0YTE
root ★タンの説明は分かりやすいなぁ


18 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 03:45:18 ID:pqmq0YTE
>>17
ありゃ▲抜けてた。


19 名前: マァヴ ★ 投稿日: 05/01/07 03:45:29 ID:???
>15
bbs.cgiとread.cgiの分割だけでも充分かもしれないですね(^_^;)
弘法と聖徳は一体化・・・・
ただ、そうするとbbs.cgiにスケールメリットが取れなくなるけど


20 名前: root▲ ★ 投稿日: 05/01/07 03:47:09 ID:???
で、読み手担当は、read.cgiサービスと、datファイル直読みサービスを提供します。
bbs.cgiのフロントエンド(と仮に名づけよう)も、担当するかな。
つまり、お客さんの相手に専念する。

で、bbs.cgiフロントエンドは、いろんなチェックしたら、
datファイルやらリモホ情報やらを、書き手担当に何らかの方法で通信して伝えます。

書き手担当は、ひたすらI/Oする。
datちょうだい、と読み手担当に言われれば渡すし、
これ処理しといて、と読み手担当に言われたら、たんたんと処理する。
でも、お客さんの相手は基本的にしない。

削除とか芋堀とか、いわゆる保守系は、書き手担当が受け付けるのかな。
あくまで、保守系だけね。お客さんは受付へどうぞ。


21 名前: マァヴ ★ 投稿日: 05/01/07 03:50:45 ID:???
>20
read.cgiとbbs.cgiだと、負荷総量ではreadのほうが圧倒的にでかいんじゃなかったっけ?(^_^;)
readを分離したほうがいいと思うんだけど。


22 名前: ▲ 某ソレ511 投稿日: 05/01/07 03:53:56 ID:T/3Yj/xH
live系だとbbs.cgiのほうの負荷で重い場合が多いんですよね、、たしか。
ラピュタの時は読み込みが多くてだったけど。


23 名前: じじぃ その4 ◆HETAREzfq. 投稿日: 05/01/07 03:55:48 ID:CcqiS2fj
負荷がたかくなるとsubject.txtがまず壊れる場合が多いんじゃが
read.cgiサービスとbbs.cgiサービスを分けることでコレは改善しるのけ?

ようワカランなりにおらが理解してたのでは
agesageの処理もかなりきつかったような気がしるんじゃが


24 名前: マァヴ ★ 投稿日: 05/01/07 03:56:49 ID:???
>23
改善はしないと思う(^_^;)


25 名前: マァヴ ★ 投稿日: 05/01/07 03:57:39 ID:???
http://kobodaishi.xrea.jp/
ふはははは(^_^;)


26 名前: root▲ ★ 投稿日: 05/01/07 03:57:46 ID:???
>>21
bbs.cgiの方が圧倒的にでかいですね。
特にread.cgiはdso化して起動コストがなくなったので。

bbs.cgi(のフロントエンド)ができるだけブロックしないようにしたいですね。
重い処理(ディスクI/O関連)を、後ろに回すのが、たぶん第一段階の最初かと。

で、後ろに回した処理がボトルネックになるようなら、最初は成功。
あとは、後ろ側の処理の効率を上げる方向で、チューニングしていくと。


27 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 03:58:50 ID:lOoHJK9M
>>13
弘法と空海は同一人物では・・・


28 名前: root▲ ★ 投稿日: 05/01/07 03:59:41 ID:???
もちろん、前と後ろの通信をうまくやってできるだけブロックしないようにするとか、
そういう方向でのプログラミング的手法も、必要になりそうかな。

いずれにせよ、またお風呂にでも入りながら、
ちょっと脳内で絵を描いてみようかと。


29 名前: マァヴ ★ 投稿日: 05/01/07 04:00:19 ID:???
>26
なるほど(^_^;)
まずはbbs.cgiの分離ですね


30 名前: 通行人 投稿日: 05/01/07 04:06:28 ID:98B+xnhu
実況系はagesageの処理を無くしてもいいんじゃないかと思ったり・・・


31 名前: その他 ★ 投稿日: 05/01/07 04:07:54 ID:???
1) 机上の空論
2) それに基づいた絵
3) 絵を描く
4) 実験する
5) 1)が合っていたかどうかの検証

これをひたすら繰り返すと、


32 名前: じじぃ その4 ◆HETAREzfq. 投稿日: 05/01/07 04:11:11 ID:CcqiS2fj
コレを機会に負荷が高くなった時に起きる不可視やら板とびやらの
主だった仕組み(原因)をご教授願いたいものじゃ

datを更新しました⇒(伝達)⇒subjectを書き換えます
のどっちかが溢れてしまうからこういうことになるんじゃとおもうんじゃが
どっちが溢れることが多いんじゃ?

subject生成の工程に伝わった時点でそこが溢れておるのか、
dat更新の段階で溢れてしまってsubjec生成tの工程に伝わってないのか、


33 名前: その他 ★ 投稿日: 05/01/07 04:11:44 ID:???
んで
現状は bbs.cgi が律速であると解かっている

bbs.cgi を動かすサーバを二台にしてみる
ただしdatは一箇所に書かなきゃ意味が無いので
backendにdat処理用一台と、

これでやって、 subject.txt や 規制系やその他もろもろが
使い物になるのかどうか、、、
特に規制系はsambaにしても連投規制にしても、かなり手ごわいかと、
あきらめるのも一手ですが、


34 名前: ひろゆき@どうやら管理人 ★ 投稿日: 05/01/07 04:12:49 ID:???
readがいくらでも分散できるのは
blackgoatで証明済みなような。


35 名前: その他 ★ 投稿日: 05/01/07 04:13:02 ID:???
>>32
「壊れてもいいや直せば」という前提で
ファルロックを一切行っていない、つまり排他制御していない

なので壊れるのです。


36 名前: FOX ★ 投稿日: 05/01/07 04:15:04 ID:???
>>34

そですねぇ
delay値をどれくらいにすれば体感上違和感がなくなるか、
それとトラフィックのボリューム(頻度?)との兼ね合い、せめぎあい
なのかなぁと


37 名前: root▲ ★ 投稿日: 05/01/07 04:15:29 ID:???
で、最近のことをちょっと書いておくと、、、。

特にlive16とかはread.cgiやdat直読みの人が待たないようにするために、
ほんとはもっとhttpdの数を増やしたいわけです。

しかし昔は、起動数をむげに増やすと、「どーん」とbbs.cgiが同時に100個以上
起動された時に(例: 西部警察で導火線爆弾が出る等)、もう即死するしかなかった。

で、昨年bbs.cgiをSpeedyCGIにすることで、
最大並列処理数(バックエンドの最大起動数)を制限することができるようになり、
即死のリスクをとても減少させることができました。

でもこの場合、bbs.cgiの実際の処理をしている人がおなかいっぱいになると、
こんどはフロントエンドがバックエンドの処理終了を待ってしまって、
結局httpdを埋めていってしまうことになります。
つまり、流入は制限されるのですが、「終了に時間がかかって、窓口人員が不足がちになる」
ことに変わりはないわけです。

また、バルスとかマツケンサンバとか、超人気番組の場合、
おそろしい勢いで読み手が攻めてきて、httpdが売り切れになってしまい、
サーバは負荷が低いのに、誰も書き込みができないし、
読むのも難しい、という状態になったりします。
これも、窓口の人手が足りない状態。

ということで、
・窓口の人手を増やして
・お客をできるだけ待たせないようにしながら
・でも、サーバにはやさしい方法で処理する

ような手法はないだろうか、というのが、今回の試みなのではないかなと。


38 名前: マァヴ ★ 投稿日: 05/01/07 04:17:25 ID:???
>33
sambaや連投規制は、frontendが今まで通りにやればいいんでないかな?(^_^;)
ラウンドロビンしてるとはいえ、短期的には同じサーバにアクセスするわけだし。

ほかにどういう規制があるんだろう・・・・
まずそのリストアップしないと(^_^;)


39 名前: root▲ ★ 投稿日: 05/01/07 04:17:35 ID:???
>>34
そうですね。読ませるほうは、比較的楽なのですよ。
Apacheのリバースプロキシとか、blackgoatみたいにsquid使うとか、
結構いろいろな手法があります。

問題は、書かせるほうをいかに処理するか。
従来の、bbs.cgiによる簡便なインタフェースをできるだけ残しつつ、
いかに中身をうまく効率化するか、なのかなと。


40 名前: FOX ★ 投稿日: 05/01/07 04:22:41 ID:???
ラウンドロビン (←弱そうな名前であまり好きでないのだが)
を使うのであれば、

Samba24 は、うまく行くか、
連投規制は、どうなるかな?
スレ立て規制は元々スレ立てやすい設定だから
あんまり気にする事無いか、トカゲの尻尾もあるし
あと・・・ 何あったっけ?


41 名前: root▲ ★ 投稿日: 05/01/07 04:24:42 ID:???
個人的には、NFS経由での書き込みはあまり使いたくないな、
と思っています。トラブルの元。

読むほうでのNFSの利用は、うまくやればありかもですね。


42 名前: root▲ ★ 投稿日: 05/01/07 04:26:36 ID:???
datは、キャッシングかなと思っているです。
フロントにもdatプールみたいなのを作って、キャッシュできないかなと。

で、どっかで話が出ましたが、SolarisだとCacheFSという仕組みがあって、
このへんが結構うまく動くです。
FreeBSDでは、どうするか。フロント側でもsquidみたいなの使ってみるかなぁ。


43 名前: マァヴ ★ 投稿日: 05/01/07 04:26:37 ID:???
http://info.2ch.net/wiki/pukiwiki.php?%BD%F1%A4%AD%B9%FE%A4%E1%A4%CA%A4%A4%BB%FE%A4%CE%C1%E1%B8%AB%C9%BD

アクセス規制・プロキシ−規制・Rock54
 BBQなど外部問い合わせ型は問題なし
 内部問い合わせ型も、それぞれがテーブルを持っていれば問題なし
 (つまり従来通り)

samba24・二重書き込み・連続投稿
 フロントエンド単位で規制。
 ラウンドロビンしていても、短期的には同じサーバで書き込みチェックを行うので。
 (つまり従来どおり)

ブラウザ情報規制
 従来通り

スレ立て規制
 これは微妙(^_^;)どうやればいいんだ
 あるいは別な手法を考える?
 バーボンハウスって同じ機能?


44 名前: マァヴ ★ 投稿日: 05/01/07 04:28:30 ID:???
お茶飲み規制・落ち着け規制・とかげの尻尾
 仕組みがよーわからん(^_^;)

その他
 従来通り


45 名前: FOX ★ 投稿日: 05/01/07 04:29:58 ID:???
お茶飲み規制・落ち着け規制 <- 現在これらはないはず
とかげの尻尾 <- BBQ のように外部経由です


46 名前: root▲ ★ 投稿日: 05/01/07 04:32:11 ID:???
最初の段階でのイメージとしては、bbs.cgi(フロント)が、バックにあるbbs-back.cgi(仮称)を叩く、
という、きわめて単純なイメージを考えています。

dat書き込み、リモホ記録といった「書き込み系」をbbs-back.cgiがやると。

で、書いたデータを読みたい時(例えばSambaとか)は、
例えば一番どろくさいやり方するなら、単純にNFSのread onlyで
フロントのbbs.cgiがバックのファイルを直読みするかんじかなと。

かしこいやり方するなら、プロセス間通信でやるとか、
あるいはmysqlみたいなのを使うとか、そういうかんじですかね。
(これらは第2段階以降だと思っています)


47 名前: じじぃ その4 ◆HETAREzfq. 投稿日: 05/01/07 04:32:40 ID:CcqiS2fj
live系の即死はほぼ一律じゃしねぃ

>>35
そうかー


48 名前: マァヴ ★ 投稿日: 05/01/07 04:33:45 ID:???
スレ立て規制以外の規制は、同じ機能をほとんどいじらずに使えそうですな(^_^;)
>samba24・二重書き込み・連続投稿
 ラウンドロビンでサーバが切り替わるタイミング(DNSのTTL単位かな?)ごとに
 新しいフロントエンドサーバに割り当て直しが起こるので
 今までより多少甘くなるかも・・・・

>スレたて規制
 BBQみたいな仕組みに置き換え?
 あるいは廃止?
 あるいは全然別の仕組み?


49 名前: root▲ ★ 投稿日: 05/01/07 04:36:35 ID:???
>>48
そうはならないようにしたいなと、思っていたりします。
つまり、別のフロントエンドサーバにあたっても、従来通りそのへんは効くようにしたいなと。


50 名前: root▲ ★ 投稿日: 05/01/07 04:38:54 ID:???
なんにせよ、明日以降まずは土地を整地して、
器の構築をやるです。

I/O屋さんに仕立て上げる方向で。
blackgoatみたいにccdを使ってみるか。


51 名前: マァヴ ★ 投稿日: 05/01/07 04:39:30 ID:???
>49
つまり「samba24・二重書き込み・連続投稿」は要改良という方向で(^_^;)
どれも(スレたて規制もふくめて)トカゲの尻尾にまとめちゃうっていう手はあるなぁ・・・・


52 名前: じじぃ その4 ◆HETAREzfq. 投稿日: 05/01/07 04:39:34 ID:CcqiS2fj
ん?
規制といえば
SETTING.TXTで定める値が必然的に各板共通になるのけ?


53 名前: マァヴ ★ 投稿日: 05/01/07 04:40:47 ID:???
subcakはbackendのお仕事になるのかな?(^_^;)やはり


54 名前: マァヴ ★ 投稿日: 05/01/07 04:41:37 ID:???
subbackじゃないや(^_^;)subjectだ


55 名前: root▲ ★ 投稿日: 05/01/07 04:43:19 ID:???
>>53
subject.txt / subback.html は、後ろの仕事になるですね。たぶん。

さすがにねむいす。そろそろまけぐみへと。


56 名前: マァヴ ★ 投稿日: 05/01/07 04:49:16 ID:???
おつかれさまです(^_^;)おやすみなさい
おいらもそろそろ寝る〜


57 名前: ひろゆき@どうやら管理人 ★ 投稿日: 05/01/07 04:58:46 ?## ID:8lHk00Ge
ディスクI/Oの分散化じゃないすかね?
dat番号で保存するサーバを切り分けるとか。



58 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 05:38:24 ID:qLUZud1A
>>27
read.cgiのサーバとbbs.cgiのサーバは同一にするという計画だったんだよ!
な、なんだってー>ΩΩ Ω


59 名前: 桶屋 投稿日: 05/01/07 08:15:26 ID:FthWzdgq
>>37>>57
これを読むと、それはありかもしれない。
datの末尾番号で保存サーバを振り分けるようにするとか。

Googleのようにデータを分散化してもつ考えですね。



60 名前: FOX ★ 投稿日: 05/01/07 13:44:12 ID:???
うーん 逆なんだけどなぁ
フロント複数で datサーバは一台でとうぶん間に合うんだけど、
たぶん 一台で 1,000万post/day くらい処理できそうなんだが、


61 名前: root▲ ★ 投稿日: 05/01/07 14:13:19 ID:???
私も、そう思ってますです。
datのマスターを管理するのは、1台でいけるんではないかと。

フロントエンドがdatファイルをキャッシュするイメージを想定しています。
で、read.cgiは、そのキャッシュを読む。
そのあたりにおいて、携帯サーバとは、ちょっとだけ路線が違うのかなと。

1000万posts/dayという値は例の「おじさんの動物的直感(これが意外とあてになるんだ)」としても、
当面の路線として「必要以上には処理を複雑にしない」で、できるだけいきたいなと。


62 名前: root▲ ★ 投稿日: 05/01/07 14:19:44 ID:???
>>61 のキャッシュは、ライブdatはメモリディスク利用かな。
で、過去ログ(●)はNFS経由か、バックエンドに丸投げ。

Sambaはあのディレクトリをフロントエンドで共有すればいいはずだから、NFSなんじゃないかなぁ。
削除系はバックエンド直叩きすね。

bbs.cgiは最初は単純に後ろに渡すだけのシンプルなもので、いいかも。


63 名前: FOX ★ 投稿日: 05/01/07 14:26:44 ID:???
>>62
banana227 の情報メールしましたー



64 名前: FOX ★ 投稿日: 05/01/07 14:33:59 ID:???
bbs-back.cgi は bbs-back.so でやりますんで
dso 化お願いします < banana227


65 名前: root▲ ★ 投稿日: 05/01/07 14:39:19 ID:???
>>63
受け取り&確認しました。
今夜あたりからぼちぼちと。


66 名前: root▲ ★ 投稿日: 05/01/07 14:39:35 ID:???
>>64
Ack.


67 名前: FOX ★ 投稿日: 05/01/07 14:40:52 ID:???
banana227.maido3.com
liveb1.2ch.net
ch2b1

んで 私が遊ぶとこ作ってくださいー


68 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 15:11:40 ID:cevNcrZr
http://www.sankei.co.jp/news/050107/sha048.htm
「雪まつり」の作業も本格化
運用開始目標は2月7日という感じでしょうか


69 名前: root▲ ★ 投稿日: 05/01/07 15:41:23 ID:???
OS上げて整地してごそごそして、、、。
週末作業ってかんじで。


70 名前: ひろゆき@どうやら管理人 ★ 投稿日: 05/01/07 17:23:21 ?## ID:8lHk00Ge
>>61
そうすると、read.cgiは分散化できていて、datは分散の必要ないと。
あとは、bbs.cgiが分散化できればOKですか?



71 名前: ひろゆき@どうやら管理人 ★ 投稿日: 05/01/07 17:26:28 ?## ID:8lHk00Ge
bbs.cgiの分散化って昔、sp.2ch.netでテストして
出来た気がする。。


72 名前: /usr/local/bin/ch2 -o i686 ◆P8fXJj6wwo 投稿日: 05/01/07 17:36:11 ID:8sspz10K
>>70-71
ここまでの方針を見る限りは、bbs.cgiの分散化というよりは
ディスクへの書き込みをいかにして均すかということでしょう。
bbs.cgiのコストの最たる部分ですし。

そのうえで受付をふやせればいうことなし。


73 名前: root▲ ★ 投稿日: 05/01/07 17:51:30 ID:???
>>70
read.cgiは比較的分散化しやすいんじゃないかな、ってことです。
bbs.cgiの分散化(たぶん機能を分ける)は、たぶんここでぼちぼちと。

>>71
sp.2ch.net(newsplusの分散化だったかな)って、どうやってやったんでしたっけ。


74 名前: ひろゆき@どうやら管理人 ★ 投稿日: 05/01/07 18:14:08 ?## ID:8lHk00Ge
たんにsquidの透過プロキシーでした。
ネットワーク周りの負荷をとりもって、
本体はbbs.cgiの処理に集中って感じでした。



75 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 18:27:33 ID:taUVfEqj
以前話が出ていたことがあるけど、
bbs.cgiから.dat,subject.txt,subback.htmlにアクセスする部分を別サーバーにして
.datの読み書きをバックエンドにしつつ、subject.txtは
オンメモリで保持するのが良いかと思ってたりします。
で、同じサーバーでread.cgiのバックエンドも動かして、キャッシュを持つと。

フロントではbbs.cgiの処理として
index.htmlや書き込みログやBBxの対処を担当して
実際の書き込みはバックエンドが行うと。
フロント側では、.dat/read.cgi/subject.txt/subback.htmlに対するリクエストは
そのままバックエンド側に回す。

バックエンドでは、bbs.cgiの求める書き込みが妥当かどうかをチェックして
実際に書き込み、フロント側の求めに応じて.datのイメージ等を渡すみたいな。
必要なら、1スレッドでキューに入れながらの非同期書き込みも視野に入れて。


76 名前: root▲ ★ 投稿日: 05/01/07 18:37:52 ID:???
>>74
シンプルすね(私も原案はそれです)
リモホ渡すところとか、そのへんの問題はありますが、
現在でもじゅうぶんに有力な策のひとつかと。


77 名前: root▲ ★ 投稿日: 05/01/07 18:38:30 ID:???
>>75
いいかんじですね。


78 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 19:51:33 ? ID:???
む、、、この作戦が成功すると
地震板がまともに機能するようになるのかな?


79 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 20:06:47 ID:cQJBfLAp
臨時板がまともを期待してはいけません(す


80 名前: FOX ★ 投稿日: 05/01/07 20:09:49 ID:???
>>78
その予定なんですけどねぇ
壁は高く、幾重にも


81 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/07 20:23:46 ID:pqmq0YTE
>>80
積み重ねていくしかないわけですな。
まさに雪だるま。


82 名前: あぼーん 投稿日: あぼーん
あぼーん


83 名前: 桃太郎 ★ 投稿日: 05/01/08 00:12:40 ID:???
地震板、電話の輻輳みたく、「お掛けになった方面の鯖は、ただ今大変込み合ってつながりにくくなっています」
なんてメッセージ画面表示したら、起こられるんだろうな・・・


84 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/08 00:34:09 ID:P9MZ8Rfx
>>83
そのメッセージに、落ちる寸前のレスをいくつか(あとスレタイ)を
表示させるようにすれば、とりあえず何が原因で落ちたかは、分かる気がします。


85 名前:P061198142013.ppp.prin.ne.jp 投稿日: 05/01/08 00:39:09 ID:FPGcP1MY
それって、一昔前にあった、お茶飲め規制なんすよね。
つまり、掲示板みたいなメディアだと、あんまり効果なかったりするです。


86 名前: root▲ ★ 投稿日: 05/01/08 07:16:04 ID:???
banana227 概ねセットアップ完了。

FreeBSD 5.3R-p4に更新済み。
カーネル的にNFS関連有効に設定。実際の設定はまだ。

ディスクI/O重視セッティング。
・/homeはccdを利用し、ソフトウェアでストライピング(ad0とad1)
・/homeのnewfsパラメータは newfs -U -b 65536 -f 8192 /dev/ccd0
・/homeはnoatime有効(以前から)

ネットワーク周りは、とりあえず携帯フロントエンドサーバ並みのチューニング。


87 名前: root▲ ★ 投稿日: 05/01/08 07:26:31 ID:???
これから >>67 のアカウント情報メールして、
pekoサーバスレでDNSの儀式依頼します。


88 名前: root▲ ★ 投稿日: 05/01/08 07:45:36 ID:???
ということで、
.so という拡張子のファイルは、dso風味で動くようにしてあります。(>>64)


89 名前: root▲ ★ 投稿日: 05/01/08 07:56:24 ID:???
ということで、作業はとりあえずここまで。

ネットワーク帯域どうしましょうか。
現状のMAX10Mbpsだと、
今回の用途からして、キャパ的にどきどきかも。


90 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/09 19:04:22 ID:pgorbTHJ
1Gbps


91 名前: root▲ ★ 投稿日: 05/01/09 21:23:29 ID:???
なお dso を使用するため、httpd そのものを ch2b1 権限で動くようにしてあります。
それに伴い、SuExecもなし。


92 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/10 20:24:35 ID:VFBoVca8
D言語お勧め


93 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/31 11:31:26 ID:1Pqyrpe70
なんか進展ないのかな・・・


94 名前: FOX ★ 投稿日: 05/01/31 11:33:29 ID:???0
もう少し暖かくなってからかも、


95 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/31 13:07:41 ID:ZrtyVVcK0
暖かくなったら溶けませんか? > 雪だるま


96 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/31 13:22:06 ID:9jxffk/E0
雪だるまが溶けないうちに雪だるま作戦はあらかた完了しなければならないと思われ、


97 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/01/31 14:41:26 ID:RzOb5kYE0
雪なんて4月になっても残ってるわけだが


98 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/02/03 00:01:27 ID:xt3Py2g/0
冷凍庫に保存してあるから大丈夫


99 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/02/03 00:15:49 ID:5z25kMKc0
溶けた雪だるまをどうするかって問題じゃなかった?w

            →dat(3の倍数)+レス書き込み
----→delegate-------→dat(3の倍数+1)+レス書き込み
  (逆プロキシ)   →dat(3の倍数+2)+レス書き込み
            →subject+スレ立て
           (振り分け)

下記の2点だけ出来れば動きそう
subjectサーバからdatサーバにスレ立てたら通知
datサーバからsubjectサーバにageの通知


100 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/02/03 00:16:04 ID:5z25kMKc0
ずれまくりorz


101 名前: [―{}@{}@{}-] 202.239.148.13 投稿日: 05/02/03 02:53:35 ID:hN2mZpmT0
>>99
どれどれ


102 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/02/05 14:22:38 ID:QIngC8On0
札幌ではそろそろ雪だるま祭りの始まる頃か


103 名前: root▲ ★ 投稿日: 05/02/16 21:31:42 ID:???0
さて、そろそろこれを動かさないとなぁ。
と、とりあえず宣言だけしとこう。

まずは、どうやるかの戦略というか、骨子を


104 名前: root▲ ★ 投稿日: 05/02/16 21:32:00 ID:???0
ありゃ。暴発。

骨子をぼちぼちと。


105 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/02/17 00:31:29 ID:qJ/os/360
もし>>75な方針で行くなら、
1-2ヶ月の内にどうにか動きそうなものを出せるかもしれません。
仮にフロント側とのインターフェースが決まっても
解決しなければいけない問題が山積みですが。


106 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/02/17 17:20:55 ID:??? BE:81094267-#
漏れ的には、特番板とか作ってみたらとか。。。


107 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/02/17 18:32:20 ID:sd53QL7W0
やっと始動ですか?(・∀・)


108 名前: root▲ ★ 投稿日: 05/02/18 19:16:14 ID:???0
>>105
おぉ。


109 名前: root▲ ★ 投稿日: 05/03/05 02:08:32 ID:???0
東京に雪が降ったから、そろそろこのスレを動かすか。

まずは、live8にある板をliveb1でも「読める」ようにしようかと。
さて、NFSでやるか、squidとかを使うか。

FreeBSDのNFSがちゃんと動くんなら、NFSのほうがよさげかもと思っていたりするけど、
どうなんだろうか。


110 名前: root▲ ★ 投稿日: 05/03/05 04:04:56 ID:???0
あ、あとApacheのmod_proxyというのもあるかな。


111 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 06:19:48 ID:/n3o7jvO0
始まりますか(・∀・)ワクワク


112 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 09:48:42 ID:iemQ7OUQ0
>>109
FreeBSDのNFSってLinuxのそれよりいいと聞いてますけど


113 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 10:30:22 ID:QpK6zgyU0
NFSなんておとろしいので、mod_proxy で reverse proxy設定がよいかと。


114 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 11:07:31 ID:U7AvG2Q50
sendfile効かないからNFSにはしないなぁ。
まぁベンチ取らないとなんともいえないんだけど。


115 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 11:34:04 ID:iemQ7OUQ0
まあ確かに用途を考えると
あまりすすめられたもんじゃないですね>NFS

Solaris同士ならいけたかもですが。

いっそ10をいれてじっけんじっけん!てのもありかもw


116 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 11:40:40 ID:RUlzb90X0
read.cgiの処理能力について、
昔書いたhttp://2ch-tool.net/mirror/mod_readcgi.zipをベースに(大幅に手を入れて)
「各レスを名前/本文等に分割したものをキャッシュする」から
「各レスを出力するHTMLになおしたものをキャッシュする」に変えたものが
ようやく動くようになったので、
軽くベンチを取ってみました。
(本来ならば現行のCGIDSO版をベースにすべきでしょうが
ソースが手元にないし、一度似たようなものを作っているので)

環境は、Athlon64-3000+ (2.0G, 512K DDR400single) MEM1G @Win2K
対象は、ある時期(1ヶ月程前)の、operate板の全dat
計116ファイル、9,456,984byte、総レス数は39585。

これを、全ての.datに対して
一通りread.cgiの出力イメージを作成するのにかかる時間(ms)です。
最初に空読みして、OSのディスクキャッシュに載せた後、
複数回測定したおよその数字です。

以下、「キャッシュなし」は初回及び保持数が少ない時にかかる時間
「キャッシュあり」は、キャッシュの保持数を充分にして、2回目以降にかかる時間です。
キャッシュなしの数字には、.datをapr_mmapしてそこから内部バッファにコピーする時間と
その.datをparseして各レスのHTMLを作成する時間が含まれます。
また、圧縮は、zlibの標準圧縮率での測定です。


117 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 11:42:21 ID:RUlzb90X0
「レスを全部読む」非圧縮
キャッシュ無し  680
キャッシュあり  290

「レスを全部読む」圧縮
キャッシュ無し  1660
キャッシュあり  1220

「最新50」非圧縮
キャッシュ無し  138
キャッシュあり  46

「最新50」圧縮
キャッシュ無し  282
キャッシュあり  184

「1-100」非圧縮
キャッシュ無し  210
キャッシュあり  85

「1-100」圧縮
キャッシュ無し  460
キャッシュあり  313

カーネルのネットワーク/スレッド、.dat読みや書き込みに割かれる分がありますが
Op246Dualの総合的処理能力が約2倍程度だろうと考えると
read.cgi処理に使えるCPU資源はK8単体と同程度以上はあると思われます。

その上で、(「全部読む」「新着」や>>リンククリックを含めた)平均的なread.cgi出力を
l50程度の長さだと仮定すると、read.cgiの処理自体は
ピーク毎秒400リクエスト以上は平気でこなせる、ということになります。
.dat転送も含めれば、(プロセッサ能力だけなら)毎秒1000近く捌けるはずです。


118 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 11:44:34 ID:RUlzb90X0
ところで、書き込み処理の方はどの程度まで可能かというと
こちらはHDDの能力に依存するでしょう。
仮に、シーク4ms、15000rpmのディスクに書き込むとします。

平均シークは4msですが、局所性も考えて
シーク+回転待ちで、5ms程度とみると
HDDの能力的には、毎秒200ブロックに対して書き込みが可能なはずです。
(データの書き込みにかかる時間は、64K程度の書き込みでも1ms以下です)

仮に、open,write,closeの3つの合計で
ディスクの10箇所に書き込むとすると
ピークで最大20ファイルに対して書き込みが出来るわけです。
ただし、プラッタもヘッドも1つではないし
ディスク自体も内部キャッシュを持っていることを考えると
ピーク30ファイルは書き込めると思われます。
(ディスクの動作モード等にも依存するかもしれません)
# 実際、体感的にはWin2K+Raptor(遅い方)RAID0でも
# 毎秒100ファイル程度は書き込めているという印象があります。
# まあ、データ本体は非同期書き込みなので、あまり参考にはなりませんが。


119 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 11:47:19 ID:RUlzb90X0
以上、読み込みと書き込みの両方の要素から
peko鯖単体の処理能力の限界を求めると
ピーク時に毎秒30書き込みが可能で、
読み出しリクエストがその20-30倍程度と考えると
毎秒600-800程度、内read.cgi呼び出しが300-400程度、
といったところでしょうか。

ピークが1日平均の1/3-1/5程度と考えると、1台のバックエンドで(peko鯖ならば)
毎秒平均6-10書き込み、1日平均50万-80万書き込み程度が
処理できる計算になります。
これは、2chの全書き込みの1/4-1/3程度に相当します。

# 本来、このスレでの話題は「live鯖をどうするか」であって
# 2ch全体の構成を変えることは考えてないでしょうが
# 私自身はlive系には全く縁も興味もないので・・・。


以上、(書き込み能力からの)理論上の目標数値のようなものは出ていますが
実際にここまで実現できるかというと、問題は山ほどあります。

で、とりあえず、バックエンドをどういう形態で動かすのか
(シングルプロセスapacheのモジュールにするのか、さらに別daemonにするのか)
という問題があります。


120 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 11:48:13 ID:RUlzb90X0
まず、apacheに載せる場合、(特にFreeBSDなら)workerが動くのか
もしうまく動かないならsolarisやlinuxは視野に入っているのか等や
そもそも1000ものスレッドを作れるのか
(例えばlinux2.4でpthreadをデフォルト使うと、各スレッドでスタックを10M取るため
32bit環境では4Gしかないアドレス空間が全然足りません)
デフォルトで作れないなら、worker.cに手を加えるのか、
仮に作れてもまともに動くのか、等です。

そしてバックエンドを別daemonにするなら
(daemon自体はselect系を使った少数スレッドによる実行形態が望ましい)
それとの通信はどうするのか
(マルチスレッドapacheに交信モジュールを追加して
コネクションプールと各プロセスからの同時接続数制限をしたい)
とかですね。

# 一応今作っているものは、apacheのhttpd依存部とそれ以外(aprには依存しますが)には
# 分離可能なようには努力しています。
# まだ.datの詳細データの読み出しと保存、subject/subbackの作成、及び
# 前述の基本的なread.cgi出力部のみですが。

もちろん、毎秒最大1000ものconnect/close要求(KeepAliveOffの場合)を
こなせるのかというのも大きな問題です。
(少数のコネクションに対してリクエストが合計1000来るというだけなら
DB等で実現しているように、問題なくこなせるはずです)


で、何らかの理由で「毎秒1000」が1台でこなせない場合の対案等は
後ほど(気が向いたら)書き込みます。


121 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/05 15:54:58 ID:U7AvG2Q50
まぁ排他処理とかキャッシュみたいなややこしいアクロバチックなことを1台のサーバーとソフトでするよりも。
Keep It Simple & Stupidでバカ端末を複数ぶらさげるほうがスケールするんだけどね。


122 名前: root▲ ★ 投稿日: 05/03/06 02:16:46 ID:???0
http://liveb1.2ch.net/livetbs/

とりあえず、単につないでみただけ。
リファラとかいろいろあるからもちろん書き込めないし、
いろんなところにlive8ってハードコーディングされてるということが改めてわかった。


123 名前: root▲ ★ 投稿日: 05/03/06 02:24:52 ID:???0
で、いろいろレス。

>>113
やっぱ、Apacheかsquidかなってことで、とりあえずsquidでやってみたです。
設定のフレキシビリティ考えると、Apacheかも。

>>115
それは、すぐにはできにくいすからね。

>>116-119
緻密な調査、ありがとうございます。
非常に参考になります。

100ファイル/secがそのまま「bbs.cgiを秒間100回」にできるわけではないですが、
私の感覚やいろんな統計などとも結構一致しているかんじがします。

cgidsoとspeedycgiにしてから、「読み」と「書き」を別ホストにできると、
実は相当いけるんじゃないだろうかというのが、これのそもそものきっかけなんで。

で、>>119 にある「2ちゃんねるの全書き込みの1/3-1/4を1台で処理できるパフォーマンスが
出せる可能性があるのかもしれない」というのが、なかなかですね。

>>120
workerで動かせるか、というのは、前からある課題ですね。
mod_proxyでリバースプロキシするなら、フロント側でworker使ってみる意味はあるかもしれないかも、
とか思ったり。

>>121
そですね。
banana大量横並べモデルって、じつはそれに近い気が、しないでもなかったり。


124 名前: root▲ ★ 投稿日: 05/03/06 03:16:58 ID:???0
…ということで、もうちょっと微調整するんで、
いったんつなげたやつを落とします。


125 名前: root▲ ★ 投稿日: 05/03/06 03:29:30 ID:???0
再度上げた。
今日はこんなとこか。


126 名前: ◆cZfSunOs.U 投稿日: 05/03/06 10:50:23 ID:adzBudCj0
Apache の mod_cache / mod_proxy 周りは現行の 2.0 より 2.1 / 2.2 の方が
いろいろ手が入って改良されてるようです.まだ alpha バージョンですけど,
実験と割り切るなら使ってみるのも一興かな,と.

live 系鯖のように板当たりのスレ数が少なく,かつ特定のスレに人が集中する
ような状況なら,read.cgi 出力のキャッシュは結構有効だろうと思います.
あとは,それを read.cgi 自前でやるのがいいのか,それとも mod_mem_cache に
お任せするのがいいのか,というところですが.

マルチスレッド MPM の選択肢としては worker 以外にも,バーチャルホスト単位で
別ユーザ権限で httpd を動かせて perchild より安定している Metux MPMとか,
Keep Alive 時の負荷軽減を図った Event MPM とか,もありますね.


127 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/08 05:03:43 ID:mDJH+l/N0
【実験】ミニ雪だるま作戦―ex7で3/8 3:10あたりから実験はじめます
http://qb5.2ch.net/test/read.cgi/operate/1110218877/


128 名前: FOX ★ 投稿日: 05/03/08 12:28:22 ID:???0
私もちと基礎実験するかな @live15

その前に知識をむさぼらなければ・・・・・
ということで 質問だらだらでーす

今 live15 は read.cgi が止まっています、つまり俗に言う「人大杉」状態。
この状態で 別サーバで read.cgi をサービスするという事を考えてみようかと、
もしかしたら root★さんがやっているのがそれなのかしら?

live15x.2ch.net で read.cgi を提供するとしたら dat@live15 を取得するのは
どうしたらいいだろう・・・



129 名前: FOX ★ 投稿日: 05/03/08 12:30:29 ID:???0
1) 直接 live15 から持ってくる、 (front end を増やすのが簡単じゃないかも)
2) 専用の black goat 経由で持ってくる、(スケールとの兼ね合いで高コスト?)
3) あと どうやるの?

もしかして root ★さんは 1) をやろうとしているのかしら?


130 名前: root▲ ★ 投稿日: 05/03/08 12:34:36 ID:???0
おぉ、、、。
めしの後で、レスします。


131 名前: root▲ ★ 投稿日: 05/03/08 14:00:26 ID:???0
read.cgiを別ホストで動かそうとする場合、何らかの形でdatにアクセスできる必要があります。
その方法ですが、1) 2) 3) だと混乱するんで、a) b) c)で、、、

a) NFSを使う

NFSを使ってlive15のdatディレクトリをlive15xにmountし、まるごと見えるようにします。
これだと、ローカルにあるファイルと同じようにopen()とかread()とかできるので、
read.cgiの改変は基本的に少なくてすみます。

でもmmap()とか使っていると、変えないといけない予感。

あと、FreeBSDのNFSの実装がどのくらい枯れているのかという点で、やや不安です。
私ののおすすめ度: ★

b) read.cgiをいじって、ローカルにdatを持ってくることにする

>>129 の 1) とか 2) の手法です。
で、専用のblackgat入れるのいまいちなので、ローカルにキャッシュ持って、
そこに入れることにするのはどうか、と考えています。

もちろんこのキャッシュで、dat直読みも対応させると。

で、フロントエンドはバックエンドにせいぜい3台、多くても5台ぐらいぶらさげれば
いいところじゃないかと思っているので、1)でいいんじゃないかなぁと(これは、甘く見てるかも)。

私のおすすめ度: ★★


132 名前: root▲ ★ 投稿日: 05/03/08 14:04:38 ID:???0
で、キャッシュを持つ実験として、ミニ雪だるまを動かしています。

ex7でディレイなし、read.cgiはノーキャッシュの状況で、
30%ぐらいキャッシュからヒットしています。
つまりその分のアクセスはフロントエンドのsquidがよきにはからってくれていて、
ex7のhttpdはdatの中身をsquid側に運ばないで済んでいます。

この状態でsquidを別マシンで動かすことを考えています。
で、別マシンで動くread.cgiはこのsquidに対して、datをリクエストすると。


133 名前: FOX ★ 投稿日: 05/03/08 14:07:33 ID:???0
混乱しないように ex7 で話しをすすめることにしよう。。。

(b)の場合 その squid というのは ex7 側にあるんですよね?
つまりその負荷はex7に負わせるということですが、
それの占有率ってどれくらいなんだろう・・・


134 名前: root▲ ★ 投稿日: 05/03/08 14:20:10 ID:???0
簡単な図にすると、今まではこんなかんじで、

ユーザPC = datリクエスト => httpd at 206.223.150.110

これを、今ex7ではこうやっています。

ユーザPC = datリクエスト => squidローカルキャッシュ[ datキャッシュ ] at 206.223.150.110 = datリクエスト => httpd at 127.0.0.1

で、次の段階では、squidとhttpdを別のマシンで動かすことを考えると。

で、今のsquidの負荷占有率は、それほど高くないです。
topだと、0点台です。
squidの非同期I/O機能が効いている模様。
だた、メモリは食ってますね。ex7のやつが今90Mぐらい。

そもそもsquidには「httpアクセラレーション機能」というのがあって、
それも、ある程度効果を発揮している模様です。

Apacheはpreforkだと1つのhttpdで同時に一人しか相手できないので、スロットいっぱいになってしまうと
身動きがとれなくなりますが、squidだと1つのsquidで同時に何百人を相手できるので、
その部分での効果も、期待できます。

マツケンサンバやバルス攻撃だと読み人が死ぬほど来てスロットをさらっていくので、
それも、ついでになんとかしてしまおうという目論見で。


135 名前: root▲ ★ 投稿日: 05/03/08 14:21:05 ID:???0
topだと、0点台です。=> CPU1%以下、という意味です。


136 名前: root▲ ★ 投稿日: 05/03/08 14:30:24 ID:???0
補足をひとつ:

リモートホストの情報は、squid => httpdの際に渡るようになっています。
つまり、IPアドレスやリモートホスト名で規制する部分は、従来どおりです。
(mod_rpaf というApacheモジュールを使用)


137 名前: FOX ★ 投稿日: 05/03/08 15:18:31 ID:???0
つまり squid を独立した別サーバで動かすと
それはまさに black goat であるということですかねぇ


138 名前: root▲ ★ 投稿日: 05/03/08 15:34:03 ID:???0
>>137
そうですね。
今のblackgoatでは、squidがせっせと動いています。


139 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/08 16:17:01 ID:/dAiNWW40
BSD Magazineで小飼弾さんがSquidリバースプロクシの記事を書いていたなぁ。
お昼にワイドスクランブルに出演してたのを見て吹いたけど。


140 名前: root▲ ★ 投稿日: 05/03/08 16:25:48 ID:???0
>>139
その記事、前にちょっと読んだです。
そんなことも思い出しつつ、設定していたり。

Kogaiさんは、元エッジの役員だからなぁ。


141 名前: root▲ ★ 投稿日: 05/03/09 02:58:59 ID:???0
で、subject.txtの304が増えることと、それは果たして負荷軽減なのか、
っていう話を、書いておこうかと。

通常の場合

2ちゃんねるビューワは、ユーザからのsubject.txtの再読み込み要求を受け付けると、
サーバにとりにいきます。

しかし、たいていのビューワはかしこくできていて、サーバ側にリクエストを出すときに、
自分が持っているsubject.txtのタイムスタンプはこれだから、それより更新されていた場合だけ
subject.txtを送ってちょうだい、というリクエストを出します。

サーバはsubject.txtのタイムスタンプを調べて(ここではsubject.txtの本体は読まない = 重要)、
ビューワから送られてきたタイムスタンプと比較して新しかったら、
サーバははじめてsubject.txt本体を読んで、ビューワ側に送ります。
もし更新されてなかったら「304 Not modified」(更新されていませんでした)だけを送って、
subject.txtの本体は読まないし、送りません。

つまりこのように「更新チェックつきりクエスト」を出すことで、もしsubject.txtが更新されていなかった場合、

・subject.txt本体を読むコスト
・subject.txtをビューワに送るコスト
・その分のネットワーク転送量コスト

が、削減できることになります。


142 名前: FOX ★ 投稿日: 05/03/09 03:02:06 ID:???0
それは squid を入れたからなるんですか?
そうじゃないと思うんですが、


143 名前: root▲ ★ 投稿日: 05/03/09 03:09:45 ID:???0
で、今回、ビューワとサーバ(httpd)の間に、squidを入れました。
squidはオンメモリとかディスク上とかに、他の人に送ったsubject.txtをたくわえています。
ここでは、現在の設定に従って、オンメモリで考えます。


ビューワからは、squidがリクエストを受け付けます。
squidは自分が持っているsubject.txtが更新されていないか、httpdに聞きます。
聞き方は、ビューワがやるときと同じ手法で、
私の手持ちはこれだから、それより更新されていたら、送ってね、
という聞き方をしているはずです。

ただしこの時、
squid => httpdの問い合わせの際に、何か「うまいこと」が起きているようなのです。
なぜか squid 出すリクエストに対して、httpd は 304 を多く返している。

なぜなのかは、よく調べないとわかりません。
でも、現象として起こっているように思えるので、再度、

実験してなかったときのログ、一昨日の19時台あたり
実験していたときのログ、昨日の19時台あたり

を、確認してみます。

# 謎のままにしたくないなぁ。


144 名前: FOX ★ 投稿日: 05/03/09 03:13:01 ID:???0
>他の人に送ったsubject.txt

これなのかな?


145 名前: root▲ ★ 投稿日: 05/03/09 03:14:04 ID:???0
>>144
それしか、考えられないですが。
だとすると、squid => httpdのリクエストがどうして出ているのかが、、、。
しかも、答えは304。


146 名前: FOX ★ 投稿日: 05/03/09 03:14:40 ID:???0
別の話しですが

でも subject.txt って
ex7はジンギスカン仕様だから 元々 on memory のはずなんですが
open close 分だけ節約できるというはなしですか?


147 名前: root▲ ★ 投稿日: 05/03/09 03:16:14 ID:???0
open send close ですね。sendはジンギスカンでも節約できないです。


148 名前: FOX ★ 投稿日: 05/03/09 03:16:44 ID:???0
>>145
squid => httpd のリクエストはでるでしょ
それの回答が 403 なだけで

クライアント => aquid の回答は 403 じゃないと思うけど
つまり今までと変わらないのでは?


149 名前: FOX ★ 投稿日: 05/03/09 03:19:01 ID:???0
squid => httpd の回答は send じゃないんですか?


150 名前: root▲ ★ 投稿日: 05/03/09 03:19:50 ID:???0
19:00-19:59 JST

3/7 実験なし
3/8 実験あり

のサンプルをとりました。

あぁ、そういう意味ですか。>>148
コストの着眼点が、違うかも。

私は本丸のhttpdのコストが下がるのが、ポイントだと思ったわけです。
squidを別のマシンで動かすことを考えた場合に。


151 名前: root▲ ★ 投稿日: 05/03/09 03:20:17 ID:???0
>>149
403 だと、本体のsendは起こらないです。


152 名前: root▲ ★ 投稿日: 05/03/09 03:22:50 ID:???0
これは、squidが何をクライアントに返しているかは、別にとらないとだめですね。
304 なのか、本体をずるずる返している(ないと思うけど)のか。


153 名前: FOX ★ 投稿日: 05/03/09 03:24:09 ID:???0
403 だったら、 memory disk でも send が起らないと思うんですが、

>>150
そんなこんなで先日の質問だったわけですが・・・
今さがしていまーす、どこで書いたか忘れちまった
このすれだと思ったんだけど、


154 名前: root▲ ★ 投稿日: 05/03/09 03:27:04 ID:???0
で、httpdのログとってみました。>>150 のつづき

3月7日の1時間分 382371 回 クライアント => httpd の数
3月8日の1時間分 353431 回 squid => httpd の数

少し減っているのは、もちろん日付が違う分とか、
squidが隠蔽した分とかが考えられます。
(squidのアクセスログとってなかったので、明確には不明)

>>153
質問・雑談スレだったような。


155 名前: FOX ★ 投稿日: 05/03/09 03:27:51 ID:???0
>>129 >>131
私は black goat 方式が良いのでは?
と思って >>131 の 2) を書いたのです。

理由としては、 正しいデータを格納するサーバは少しでも軽く
余計な仕事をしない方が、将来 fron end を並べたとき有利なのではないかと、
一つの系がこなせる上限というのは back end の上限によって決まるから
(前提条件は「back end は一台だけ」です)


156 名前: FOX ★ 投稿日: 05/03/09 03:28:34 ID:???0
>>129 >>131
私は black goat 方式が良いのでは?
と思って >>129 の 2) を書いたのです。

理由としては、 正しいデータを格納するサーバは少しでも軽く
余計な仕事をしない方が、将来 fron end を並べたとき有利なのではないかと、
一つの系がこなせる上限というのは back end の上限によって決まるから
(前提条件は「back end は一台だけ」です)

再投稿すんません


157 名前: root▲ ★ 投稿日: 05/03/09 03:29:04 ID:???0
総数 >>154 のうち、

%grep " 304 " 0307 | wc -l
70960
%grep " 304 " 0308 | wc -l
132584

となっていました。倍ぐらい304が多いかんじ。

うち、subject.txt は、

%grep " 304 " 0307 | grep subject.txt | wc -l
98
%grep " 304 " 0308 | grep subject.txt | wc -l
10687


158 名前: root▲ ★ 投稿日: 05/03/09 03:33:46 ID:???0
>>156
ふむ。

後ろには、データのファイルだけを入れるってかんじですか。
bbs.cgiも、データを書くところ以外は前に持ってくると。

そういえば、そんなことをどこかでも言っていたような。

で、今私がやってる実験の話を、別のレスで。


159 名前: root▲ ★ 投稿日: 05/03/09 03:44:03 ID:???0
ということで私がいまやっているのは、

目的1が、httpdの直前にキャッシュを入れて、dat直読みとsubject.txtの処理にかかるhttpdの仕事を軽くする、
目的2が、squidの機能(一人でたくさんの相手を処理できる)を使ってhttpdの空きを確保する、になります。

深夜の実況は、よくのびます。あと、読み手が少ない時も。
でも、とても人気のある番組では、伸びがわるいです。

その原因のひとつとして、大量の読み手がhttpdを占有してしまい、
そのためにhttpdの空きが少なくなってしまい、アクセスそのものが困難になる、というのがあります。
売り切れ状態というやつ。

マツケンサンバとかの時は、ログインするとサーバは反応ある(結構軽い)のに
売り切れ状態となり、アクセスはそのものができなくなってしまいます。
これは、大量の読み手がhttpdをふさいでしまうせいです。

httpdを増やせればいいのですが、httpdは1つのプロセスで1つのリクエストしかさばけないので、
限界があります。

そこでこれを解決するために、目的2をやったと。

目的1については、別レスで。


160 名前: FOX ★ 投稿日: 05/03/09 03:45:11 ID:???0
達成したいこと

live16(tiger) + live8(cobra) + live15(banana) それぞれジンギスカン
を一つの大きなサーバとして運用したい。
出来上がり品は 今の倍のキャパにしたい。

Front1 , Front2 , Front3 ,,, Front10
 ↓↑
black goat
 ↓↑
live8 , live15 , live16

この構成で 今の倍以上をこなしたい
私の目論見では二倍だったら black goat なし Front 三台で
こなせると思っております


そして Front が逼迫した場合は Front は横並びで増設
back end が逼迫したら black goat 追加、
これで五倍〜10倍いくような予感、なんちゃって

ちなみに back end の読み出しは dat , txt 読み(cgi経由なし)
書き込みは 専用のDSO(written in C)


161 名前: FOX ★ 投稿日: 05/03/09 03:47:32 ID:???0
Front end は単純な ろびんちゃん


162 名前: root▲ ★ 投稿日: 05/03/09 03:49:49 ID:???0
目的1について

これは、主にdat直読みとsubject.txt読み込みの負荷軽減の模索です。
ex7ではヒット率3割ぐらいのようなので、その分httpdの仕事が少なくてすみます。

squidはもちろんその分仕事します。
で、squidの部分を別のマシンに持ってくることで、分散できるんじゃないかと考えていたりしました。


…とここまで書きましたが、私のはは現状のものをあまり変えずに「皮をかぶせる」アイディアですね。

これでも、かなりいけると踏んでいますが、んじゃread.cgiはどうすんのとか、bbs.cgiは結局スルーか、
とか、そういうふうに考えると、ドラスティックには効果を期待できないのかも、しんないですね。
たぶんせいぜい、倍ぐらいにしかならない。

もっとスケールするようにするには、>>156 のほうが、本筋な気がしてきました。
しかしそれには、開発が必要ですね。でもそれは、必要な開発なのかなと。


163 名前: root▲ ★ 投稿日: 05/03/09 03:51:45 ID:???0
>私の目論見では二倍だったら black goat なし Front 三台で
>こなせると思っております

うわ、結婚したかも。


164 名前: root▲ ★ 投稿日: 05/03/09 03:55:33 ID:???0
今のex7での実験は「現状を延命させる」実験としてかなり面白いので続けようと思いますが、
(ヒット率3割も出ると思わなかった)

改めて >>160 の図面見ると、Front 1〜Front 10に、
squidの部分がそのまま使えそうな気がするですよ(オンメモリモードで)。


165 名前: FOX ★ 投稿日: 05/03/09 03:56:11 ID:???0
開発といっても

front で bbs.cgi も read.cgi も請け負う

front end に置く bbs.cgi の実際にdat に書くという処理の部分を
back end の所定のサーバの cgi(dso) を呼ぶに変えるだけかと、
(そうでもないか? やってみて変なとこちょこちょこ修正ですむような気が)
実況サーバですから timeclose 等はまぁがまんするとか
スレ立て規制はバーボンがあるし、

index.html subject.txt .dat(rea.cgi) を何時どうやって構成するかも問題ですが
最初は back end で構成したものをそのまま呼んできて渡してもよいような
実験の結果 304 が沢山発生したんですからかなり back end は楽になると思う




166 名前: root▲ ★ 投稿日: 05/03/09 04:01:56 ID:???0
>>165 ふむふむ。

front endにdat(相当品)を、ディスクI/Oしないでどう持ってくるか、
ってかんじになりそうですね。
>>164 に書いたように、squidとかをオンメモリモードで動かすのがいいかも。


167 名前: FOX ★ 投稿日: 05/03/09 04:03:49 ID:???0
>>160 の単純な形(第一歩)としては

Front1
 ↓↑
live16

だと思うんですよね、


168 名前: FOX ★ 投稿日: 05/03/09 04:05:00 ID:???0
>>166

それは front 側は、基本的にすべてメモリ上で処理する
って事ですか?


169 名前: root▲ ★ 投稿日: 05/03/09 04:05:01 ID:???0
>>167
ですね、、、下がlive8だったりしますが、
やろうとしているところだったりしました。


170 名前: root▲ ★ 投稿日: 05/03/09 04:05:50 ID:???0
>>168
できれば、そうしたいと思っていました。
cのフロントとおなじ乗りで。


171 名前: FOX ★ 投稿日: 05/03/09 04:08:00 ID:???0
んで live15 で実験しませんか?
なぜなら あいている banana があるわけで、

front1 , front2
↓↑
live15

がすぐ組めるような、
これで live15 系として banana 一台の何倍のキャパになるかが知りたかったり、、


172 名前: root▲ ★ 投稿日: 05/03/09 04:09:43 ID:???0
最初は、squidの非同期I/Oならかなりはやいはずだから、I/Oさせてもいいかなぁとか
思っていたんですが、今日の結果を見て(まだdiskd試してないからあれだけど)、
やっぱりフロントエンドでI/Oさせるのはかなりつらいのかなと、改めて思いました。

まだ独立で動かしてないから、言い切れない部分がありますけど。


173 名前: root▲ ★ 投稿日: 05/03/09 04:11:15 ID:???0
>>171
やりますか。

ex7でのデータとりは、このままやるとして、
今liveb1を名乗っているやつを front1 に改造すると。


174 名前: FOX ★ 投稿日: 05/03/09 04:14:00 ID:???0
第一弾としては

1) front1 をつくる
2) back はいまのまま (bbsx.soは作るけど)
3) front2 を追加

これで天井測定

こんな感じかしら?


175 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/09 04:18:31 ID:jjEUwiu90
私は基本的に>>156案に同意ですが
バックエンドは、基本的にCPUはスカスカになり
(ネットワーク処理もCPUはIDLEでしょうから)
read.cgi処理も出来るだろうと考えています。
.datも含めて、オンメモリのキャッシュを有効に活用すれば
sendfileには劣るかもしれませんが、ネットワーク負荷も
静的コンテンツ転送以下に抑えられるでしょうし。
同居すれば、「.datをどうやって取ってくるか」「.dat転送のコスト」
等は無視できるようになりますから。

ただ、(特に開発中は)CGIDSOは非常に有効ですが
これ自体は、(fork/execはしないものの)毎回ロードとリロケーションを行っていると思います。
この点も考慮すると、スカスカって程ではないかもしれません。

それと、index.htmlの作成もbackend側で出来れば、
(連投規制等考えなければいけない点もあるものの)
フロント(.dat書き込み以外のbbs.cgi処理全般に専念)は
ほぼ完全にラウンドロビンで台数増減が自由になると思います。


とはいえ、実験した数字を見てみるのが一番ですね。
backendのCPUに余力がありそうならread.cgiを後ろに回すことも考える、という事で。


176 名前: root▲ ★ 投稿日: 05/03/09 04:21:18 ID:???0
それでいきますか。

これで、read.cgi、dat直読み、bbs.cgiをfront1で担当できるようにいろいろ整えるということですね。

書き込みはfront1のbbs.cgi => live15のbbsx.so で、
読むほう(read.cgiとdat直読み)をどうするか、、、が、質問の趣旨であると。


177 名前: root▲ ★ 投稿日: 05/03/09 04:22:53 ID:???0
>>175
どもです。
> 毎回ロードとリロケーションを行っていると思います。

タイムスタンプぐらいは、見てるんじゃなかったけか。


178 名前: FOX ★ 投稿日: 05/03/09 04:24:42 ID:???0
そですね、

私も どれとどれを fontにして
どれを back にするかという点では
本当に迷います

ここは実験しかないでしょうなぁ



179 名前: root▲ ★ 投稿日: 05/03/09 04:30:06 ID:???0
>>178
さて、今liveb1って名前ですが、、、。
そのまま、使いますかね。


180 名前: FOX ★ 投稿日: 05/03/09 04:35:00 ID:???0
いいんじゃないですか、
作る cgi 等も、ぐちゃぐちゃぺたぺたで最初は作りますし、
本番はlive16,live8のときですから、


181 名前: FOX ★ 投稿日: 05/03/09 04:36:57 ID:???0
おっと 二台ありませんでしたっけ?
使っていないbanana

その2台を両方とも front にしたいから
livebq , liveb2 としておいて
実際にユーサがアクセスするラウンドロビンのやつは別名がいいかな?


182 名前: root▲ ★ 投稿日: 05/03/09 04:41:01 ID:???0
未使用は、1台のはず。

もう1台、私が他サーバのメンテナンス用として使っているのがあります。
バージョンアップ作業の際の作業用マシンとか、ソースツリー置いてあったり、
CVSupやftp.freebsd.orgの部分ミラーをしてしたりしています。
くずして転用することはできますが、あまりくずしたくないかも。


183 名前: ▲ 某ソレ511 投稿日: 05/03/09 04:42:07 ID:Jqgj2F0Y0
eq.2ch.netでつかっちゃったからね。


184 名前: FOX ★ 投稿日: 05/03/09 04:42:24 ID:???0
んじゃ pie工事後にbananaを一台投入するということで、


185 名前: FOX ★ 投稿日: 05/03/09 04:43:36 ID:???0
あっ そうか・・・ >>184

あのサーバは暇そうだなぁ
もっとアイデア出して忙しくさせてくださいー


186 名前: FOX ★ 投稿日: 05/03/09 04:43:57 ID:???0
ぐっ >>183 だった


187 名前: ◆cZfSunOs.U 投稿日: 05/03/09 08:34:19 ID:wqlHe1Zm0
read.cgi をフロントエンド側で走らせる場合,squid で dat をキャッシュさせるとなると,
dat を直接 open() はできないでしょうから,squid に対し HTTP リクエストを発して
取ってくるということになるんですかね.>>175 さんのおっしゃるようにバックエンドで
read.cgi を走らせてフロント側でキャッシュというのとどちらがいいのか......
まぁ実験しないとわかりませんね.

>>177
>> 毎回ロードとリロケーションを行っていると思います。
>
>タイムスタンプぐらいは、見てるんじゃなかったけか。

これは利用形態や状況に依存しますね.prefork MPM の場合,
あるいはマルチスレッド MPM でも read.cgi 呼び出しが間欠的であれば
ロード・リロケーションが毎回発生すると思います.一方,
マルチスレッド MPM で read.cgi が常時呼ばれている状況なら
毎回発生とはならず,ほぼ常駐したままになると思います.


188 名前: ◆cZfSunOs.U 投稿日: 05/03/10 20:55:04 ID:geHPxiLU0
http://www.mail-archive.com/dev@httpd.apache.org/msg24903.html
    * FreeBSD, threads, and worker MPM.  All seems to work fine
      if you only have one worker process with many threads.  Add
      a second worker process and the accept lock seems to be
      lost.  This might be an APR issue with how it deals with
      the child_init hook (i.e. the fcntl lock needs to be resynced).
      More examination and analysis is required.
        Status: Works with FreeBSD 5.3. Does not work in previous versions.
                This has also been reported on Cygwin.


189 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 05/03/10 21:13:47 ID:KUErTDVR0
ほう。
つまり、1プロセスならば問題なさそう、という事ですね。
むしろ願ったりな状況なのかも。


190 名前: root▲ ★ 投稿日: 05/03/10 22:54:35 ID:???0
>>188
おー。

やってみるか。


191 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 02:09:43 ID:NoitE4tj0
杉花粉で雪だるま・・・orz


192 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 03:44:18 ID:WsaRzBU50
■新年度特別企画「花粉だるま作戦」liveサーバの飛躍なるか!? Part1


193 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 11:49:44 ID:6OKcrSHN0
DISKDは速いディスクなら圧倒的にパフォーマンスいいよ。
ただ、failしたときどうすんのか。


194 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 12:10:47 ID:IBpTOhSr0
よー分からんけどスレを全てメモリで保持、バックアップ(ハードディスク書き込み)を外部で行えばいいんじゃないの?


195 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 14:14:34 ID:mV5GHo500
>>194
すでにメモリディスク=通称ジンギスカンは導入され絶大な成果を挙げていますが何か


196 名前: ▲ 某ソレ511 投稿日: 2005/03/22(火) 18:31:57 ID:3/GcYfJe0
datフォルダは今のところジンギスカンの対象外じゃなかったっけ、、


197 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 18:43:45 ID:vVOQLXCt0
>>196
やっぱりジンギスカンは高いから?


198 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 19:11:42 ID:mV5GHo500
>>196
そーでしたかしら
だったらスマソ


199 名前: じじぃ その4 ◆HETAREzfq. 投稿日: 2005/03/22(火) 20:20:59 ID:t1ZjBOs10
aliveなスレ(掲示板上にあるやつ)と過去ログ倉庫を
明確に分けたらうまく逝くのかのう?

aliveなほうは全ての作業をオンメモリで
dat落ちや削除・芋掘りがあった時点で倉庫に送る(HDDに送る)とか
云い換えれば、メモリマシンとHDDマシンを完全分割


200 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 20:39:39 ID:vVOQLXCt0
>>199
マシン感転送に時間かかりそうだしなんだか遊んでる資源が増えそうなようかん


201 名前: じじぃ その4 ◆HETAREzfq. 投稿日: 2005/03/22(火) 20:55:31 ID:t1ZjBOs10
>>200
ああ、云われてみればそうかものう。。。


202 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 22:22:25 ID:mV5GHo500
とりあえずHDD送りはLAが一定以下でbbs.cgiがコールされたとき限定でいいんじゃないかしらと言ってみる


203 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 22:57:30 ID:vVOQLXCt0
>>202
電源落ちるかメモリが逝くとデータが全部消えるんですが
サーバ室侵入で電源「プチっ」とかやられたら


204 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 22:59:14 ID:f6+r4Smx0
だんだん雪だるまの趣旨から外れてる希ガス…
ま、外野だからいいかw


205 名前: ◆Reffi/bQ.c 投稿日: 2005/03/22(火) 23:01:40 ID:r3m2eTKb0
>203
PIEのセキュリティ体制を知らないのかと小一時間(ry


206 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/22(火) 23:09:33 ID:vVOQLXCt0
>>204
すんまそん・・・

>>205
万全って感じですか

ってゆうか1見てこないとな
書き込みながらこのスレがなんなのかわかってない悪寒


207 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/23(水) 01:35:07 ID:IxC783Ix0
そういえばDB Magazineのはてなの記事は読んだ?
MySQLのレプリケーションを使って、参照系のサーバーを更新系DBにたくさんぶら下げて。
多数のreadを参照系でさばいて、少ない書き込みは更新系だけで処理するんだって。
んで参照系はメモリを2G積んだサーバーでtmpfsにDBを置くと。


208 名前: 動け動けウゴウゴ2ちゃんねる 投稿日: 2005/03/25(金) 16:35:17 ID:cDFxOch/0
こんにちは。

ちょいとこのスレを目を通しただけなので、いまいち掴み切れてないのですが、一提案。
整形済のものをハッシュテーブルを利用して生成済 HTML を cache してみるのは。

基本動作は

if(URL または、リクエストでハッシュを生成と検索)
{ ハッシュテーブルからキャッシュを送信}
else // 見付からない
{ HTML 生成して、ハッシュに保存 }

HTML 済の保存場所としては、
1. 一つのプロセスが常駐できるなら on-memory
2. mfs または tmpfs
3. local fs

理想としては、アクセス数と最終リクエストによる優先順を保持して、1 または 2 と 3 を併用できたらいいとは思うけど。
新しくアクセスされたところは 1(2) に残り古いページは 3 に移って、そのうち消去。

記事の数やメモリの量にもよるけど読者が多いところに有効。

とっても大雑把だけど雰囲気ぐらいはつかめまつか?




2ちゃんねるは、ここのサーバを使ってるです。。。