■新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!? Part1

**FOX ★** · 05/01/07 03:19:00

■　新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!?

巨大Live専用サーバの構築

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

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

**root▲ ★** · 05/01/07 03:59:41

もちろん、前と後ろの通信をうまくやってできるだけブロックしないようにするとか、
そういう方向でのプログラミング的手法も、必要になりそうかな。

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

**マァヴ ★** · 05/01/07 04:00:19

>26
なるほど(^_^;)
まずはbbs.cgiの分離ですね

**通行人** · 05/01/07 04:06:28

実況系はagesageの処理を無くしてもいいんじゃないかと思ったり・・・

**その他 ★** · 05/01/07 04:07:54

1) 机上の空論
2) それに基づいた絵
3) 絵を描く
4) 実験する
5) 1)が合っていたかどうかの検証

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

**じじぃ その４** ◆HETAREzfq. · 05/01/07 04:11:11

コレを機会に負荷が高くなった時に起きる不可視やら板とびやらの
主だった仕組み（原因）をご教授願いたいものじゃ

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

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

**その他 ★** · 05/01/07 04:11:44

んで
現状は bbs.cgi が律速であると解かっている

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

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

**ひろゆき＠どうやら管理人 ★** · 05/01/07 04:12:49

readがいくらでも分散できるのは
blackgoatで証明済みなような。

**その他 ★** · 05/01/07 04:13:02

>>32
「壊れてもいいや直せば」という前提で
ファルロックを一切行っていない、つまり排他制御していない

なので壊れるのです。

**FOX ★** · 05/01/07 04:15:04

>>34

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

**root▲ ★** · 05/01/07 04:15:29

で、最近のことをちょっと書いておくと、、、。

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

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

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

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

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

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

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

**マァヴ ★** · 05/01/07 04:17:25

>33
sambaや連投規制は、frontendが今まで通りにやればいいんでないかな？(^_^;)
ラウンドロビンしてるとはいえ、短期的には同じサーバにアクセスするわけだし。

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

**root▲ ★** · 05/01/07 04:17:35

>>34
そうですね。読ませるほうは、比較的楽なのですよ。
Apacheのリバースプロキシとか、blackgoatみたいにsquid使うとか、
結構いろいろな手法があります。

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

**FOX ★** · 05/01/07 04:22:41

ラウンドロビン　(←弱そうな名前であまり好きでないのだが)
を使うのであれば、

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

**root▲ ★** · 05/01/07 04:24:42

個人的には、NFS経由での書き込みはあまり使いたくないな、
と思っています。トラブルの元。

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

**root▲ ★** · 05/01/07 04:26:36

datは、キャッシングかなと思っているです。
フロントにもdatプールみたいなのを作って、キャッシュできないかなと。

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

**マァヴ ★** · 05/01/07 04:26:37

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

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

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

**マァヴ ★** · 05/01/07 04:28:30

お茶飲み規制・落ち着け規制・とかげの尻尾
　仕組みがよーわからん(^_^;)

その他
　従来通り

**FOX ★** · 05/01/07 04:29:58

お茶飲み規制・落ち着け規制 <- 現在これらはないはず
とかげの尻尾 <- BBQ のように外部経由です

**root▲ ★** · 05/01/07 04:32:11

最初の段階でのイメージとしては、bbs.cgi(フロント)が、バックにあるbbs-back.cgi(仮称)を叩く、
という、きわめて単純なイメージを考えています。

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

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

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

**じじぃ その４** ◆HETAREzfq. · 05/01/07 04:32:40

live系の即死はほぼ一律じゃしねぃ

>>35
そうかー

**マァヴ ★** · 05/01/07 04:33:45

スレ立て規制以外の規制は、同じ機能をほとんどいじらずに使えそうですな(^_^;)
＞samba24・二重書き込み・連続投稿
　ラウンドロビンでサーバが切り替わるタイミング（DNSのTTL単位かな？）ごとに
　新しいフロントエンドサーバに割り当て直しが起こるので
　今までより多少甘くなるかも・・・・

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

**root▲ ★** · 05/01/07 04:36:35

>>48
そうはならないようにしたいなと、思っていたりします。
つまり、別のフロントエンドサーバにあたっても、従来通りそのへんは効くようにしたいなと。

**root▲ ★** · 05/01/07 04:38:54

なんにせよ、明日以降まずは土地を整地して、
器の構築をやるです。

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

**マァヴ ★** · 05/01/07 04:39:30

>49
つまり「samba24・二重書き込み・連続投稿」は要改良という方向で(^_^;)
どれも（スレたて規制もふくめて）トカゲの尻尾にまとめちゃうっていう手はあるなぁ・・・・

**じじぃ その４** ◆HETAREzfq. · 05/01/07 04:39:34

ん？
規制といえば
SETTING.TXTで定める値が必然的に各板共通になるのけ？

**マァヴ ★** · 05/01/07 04:40:47

subcakはbackendのお仕事になるのかな？(^_^;)やはり

**マァヴ ★** · 05/01/07 04:41:37

subbackじゃないや(^_^;)subjectだ

**root▲ ★** · 05/01/07 04:43:19

>>53
subject.txt / subback.html は、後ろの仕事になるですね。たぶん。

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

**マァヴ ★** · 05/01/07 04:49:16

おつかれさまです(^_^;)おやすみなさい
おいらもそろそろ寝る～

**ひろゆき＠どうやら管理人 ★** · NG

ディスクI/Oの分散化じゃないすかね？
dat番号で保存するサーバを切り分けるとか。

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 05:38:24

>>27
read.cgiのサーバとbbs.cgiのサーバは同一にするという計画だったんだよ！
な、なんだってー＞ΩΩ Ω

桶屋 · 05/01/07 08:15:26

>>37 >>57
これを読むと、それはありかもしれない。
datの末尾番号で保存サーバを振り分けるようにするとか。

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

**FOX ★** · 05/01/07 13:44:12

うーん　逆なんだけどなぁ
フロント複数で datサーバは一台でとうぶん間に合うんだけど、
たぶん　一台で 1,000万post/day くらい処理できそうなんだが、

**root▲ ★** · 05/01/07 14:13:19

私も、そう思ってますです。
datのマスターを管理するのは、1台でいけるんではないかと。

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

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

**root▲ ★** · 05/01/07 14:19:44

>>61 のキャッシュは、ライブdatはメモリディスク利用かな。
で、過去ログ(●)はNFS経由か、バックエンドに丸投げ。

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

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

**FOX ★** · 05/01/07 14:26:44

>>62
banana227 の情報メールしましたー

**FOX ★** · 05/01/07 14:33:59

bbs-back.cgi は bbs-back.so でやりますんで
dso 化お願いします < banana227

**root▲ ★** · 05/01/07 14:39:19

>>63
受け取り&確認しました。
今夜あたりからぼちぼちと。

**root▲ ★** · 05/01/07 14:39:35

>>64
Ack.

**FOX ★** · 05/01/07 14:40:52

banana227.maido3.com
liveb1.2ch.net
ch2b1

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

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 15:11:40

http://www.sankei.co.jp/news/050107/sha048.htm
「雪まつり」の作業も本格化
運用開始目標は2月7日という感じでしょうか

**root▲ ★** · 05/01/07 15:41:23

OS上げて整地してごそごそして、、、。
週末作業ってかんじで。

**ひろゆき＠どうやら管理人 ★** · NG

>>61
そうすると、read.cgiは分散化できていて、datは分散の必要ないと。
あとは、bbs.cgiが分散化できればOKですか？

**ひろゆき＠どうやら管理人 ★** · NG

bbs.cgiの分散化って昔、sp.2ch.netでテストして
出来た気がする。。

**/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 05/01/07 17:36:11

>>70-71
ここまでの方針を見る限りは、bbs.cgiの分散化というよりは
ディスクへの書き込みをいかにして均すかということでしょう。
bbs.cgiのコストの最たる部分ですし。

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

**root▲ ★** · 05/01/07 17:51:30

>>70
read.cgiは比較的分散化しやすいんじゃないかな、ってことです。
bbs.cgiの分散化(たぶん機能を分ける)は、たぶんここでぼちぼちと。

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

**ひろゆき＠どうやら管理人 ★** · NG

たんにsquidの透過プロキシーでした。
ネットワーク周りの負荷をとりもって、
本体はbbs.cgiの処理に集中って感じでした。

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 18:27:33

以前話が出ていたことがあるけど、
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のイメージ等を渡すみたいな。
必要なら、１スレッドでキューに入れながらの非同期書き込みも視野に入れて。

**root▲ ★** · 05/01/07 18:37:52

>>74
シンプルすね(私も原案はそれです)
リモホ渡すところとか、そのへんの問題はありますが、
現在でもじゅうぶんに有力な策のひとつかと。

**root▲ ★** · 05/01/07 18:38:30

>>75
いいかんじですね。

**動け動けウゴウゴ２ちゃんねる** · NG

む、、、この作戦が成功すると
地震板がまともに機能するようになるのかな？

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 20:06:47

臨時板がまともを期待してはいけません（す

**FOX ★** · 05/01/07 20:09:49

>>78
その予定なんですけどねぇ
壁は高く、幾重にも

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 20:23:46

>>80
積み重ねていくしかないわけですな。
まさに雪だるま。

**あぼーん** · NG

あぼーん

**桃太郎 ★** · 05/01/08 00:12:40

地震板、電話の輻輳みたく、「お掛けになった方面の鯖は、ただ今大変込み合ってつながりにくくなっています」
なんてメッセージ画面表示したら、起こられるんだろうな・・・

**動け動けウゴウゴ２ちゃんねる** · 05/01/08 00:34:09

>>83
そのメッセージに、落ちる寸前のレスをいくつか（あとスレタイ）を
表示させるようにすれば、とりあえず何が原因で落ちたかは、分かる気がします。

む P061198142013.ppp.prin.ne.jp · 05/01/08 00:39:09

それって、一昔前にあった、お茶飲め規制なんすよね。
つまり、掲示板みたいなメディアだと、あんまり効果なかったりするです。

**root▲ ★** · 05/01/08 07:16:04

banana227 概ねセットアップ完了。

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

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

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

**root▲ ★** · 05/01/08 07:26:31

これから >>67 のアカウント情報メールして、
pekoサーバスレでDNSの儀式依頼します。

**root▲ ★** · 05/01/08 07:45:36

ということで、
.so という拡張子のファイルは、dso風味で動くようにしてあります。(>>64)

**root▲ ★** · 05/01/08 07:56:24

ということで、作業はとりあえずここまで。

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

**動け動けウゴウゴ２ちゃんねる** · 05/01/09 19:04:22

１Gbps

**root▲ ★** · 05/01/09 21:23:29

なお dso を使用するため、httpd そのものを ch2b1 権限で動くようにしてあります。
それに伴い、SuExecもなし。

**動け動けウゴウゴ２ちゃんねる** · 05/01/10 20:24:35

D言語お勧め

**動け動けウゴウゴ２ちゃんねる** · 05/01/31 11:31:26

なんか進展ないのかな・・・

**FOX ★** · 05/01/31 11:33:29

もう少し暖かくなってからかも、

**動け動けウゴウゴ２ちゃんねる** · 05/01/31 13:07:41

暖かくなったら溶けませんか？ > 雪だるま

**動け動けウゴウゴ２ちゃんねる** · 05/01/31 13:22:06

雪だるまが溶けないうちに雪だるま作戦はあらかた完了しなければならないと思われ、

**動け動けウゴウゴ２ちゃんねる** · 05/01/31 14:41:26

雪なんて4月になっても残ってるわけだが

**動け動けウゴウゴ２ちゃんねる** · 05/02/03 00:01:27

冷凍庫に保存してあるから大丈夫

**動け動けウゴウゴ２ちゃんねる** · 05/02/03 00:15:49

溶けた雪だるまをどうするかって問題じゃなかった？ｗ

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

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

**動け動けウゴウゴ２ちゃんねる** · 05/02/03 00:16:04

ずれまくりorz

[―{}@{}@{}-] 202.239.148.13 · 05/02/03 02:53:35

>>99
どれどれ

**動け動けウゴウゴ２ちゃんねる** · 05/02/05 14:22:38

札幌ではそろそろ雪だるま祭りの始まる頃か

**root▲ ★** · 05/02/16 21:31:42

さて、そろそろこれを動かさないとなぁ。
と、とりあえず宣言だけしとこう。

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

**root▲ ★** · 05/02/16 21:32:00

ありゃ。暴発。

骨子をぼちぼちと。

**動け動けウゴウゴ２ちゃんねる** · 05/02/17 00:31:29

もし>>75な方針で行くなら、
1-2ヶ月の内にどうにか動きそうなものを出せるかもしれません。
仮にフロント側とのインターフェースが決まっても
解決しなければいけない問題が山積みですが。

**動け動けウゴウゴ２ちゃんねる** · NG

漏れ的には、特番板とか作ってみたらとか。。。

**動け動けウゴウゴ２ちゃんねる** · 05/02/17 18:32:20

やっと始動ですか？(･∀･)

**root▲ ★** · 05/02/18 19:16:14

>>105
おぉ。

**root▲ ★** · 05/03/05 02:08:32

東京に雪が降ったから、そろそろこのスレを動かすか。

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

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

**root▲ ★** · 05/03/05 04:04:56

あ、あとApacheのmod_proxyというのもあるかな。

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 06:19:48

始まりますか(･∀･)ﾜｸﾜｸ

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 09:48:42

>>109
FreeBSDのNFSってLinuxのそれよりいいと聞いてますけど

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 10:30:22

NFSなんておとろしいので、mod_proxy で reverse proxy設定がよいかと。

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 11:07:31

sendfile効かないからNFSにはしないなぁ。
まぁベンチ取らないとなんともいえないんだけど。

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 11:34:04

まあ確かに用途を考えると
あまりすすめられたもんじゃないですね＞NFS

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

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

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 11:40:40

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

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

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

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

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 11:42:21

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

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

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

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

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

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

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

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

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 11:44:34

ところで、書き込み処理の方はどの程度まで可能かというと
こちらはHDDの能力に依存するでしょう。
仮に、シーク4ms、15000rpmのディスクに書き込むとします。

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

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

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 11:47:19

以上、読み込みと書き込みの両方の要素から
peko鯖単体の処理能力の限界を求めると
ピーク時に毎秒30書き込みが可能で、
読み出しリクエストがその20-30倍程度と考えると
毎秒600-800程度、内read.cgi呼び出しが300-400程度、
といったところでしょうか。

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

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

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

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

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 11:48:13

まず、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」が１台でこなせない場合の対案等は
後ほど(気が向いたら)書き込みます。

**動け動けウゴウゴ２ちゃんねる** · 05/03/05 15:54:58

まぁ排他処理とかキャッシュみたいなややこしいアクロバチックなことを1台のサーバーとソフトでするよりも。
Keep It Simple & Stupidでバカ端末を複数ぶらさげるほうがスケールするんだけどね。

**root▲ ★** · 05/03/06 02:16:46

http://liveb1.2ch.net/livetbs/

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

**root▲ ★** · 05/03/06 02:24:52

で、いろいろレス。

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

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

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

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

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

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

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

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

**root▲ ★** · 05/03/06 03:16:58

…ということで、もうちょっと微調整するんで、
いったんつなげたやつを落とします。

**root▲ ★** · 05/03/06 03:29:30

再度上げた。
今日はこんなとこか。

◆cZfSunOs.U · 05/03/06 10:50:23

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 とか，もありますね．

**動け動けウゴウゴ２ちゃんねる** · 05/03/08 05:03:43

【実験】ミニ雪だるま作戦―ex7で3/8 3:10あたりから実験はじめます
http://qb5.2ch.net/test/read.cgi/operate/1110218877/