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

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

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

巨大Live専用サーバの構築

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

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

**ひろゆき＠どうやら管理人 ★** · 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/

**FOX ★** · 05/03/08 12:28:22

私もちと基礎実験するかな @live15

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

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

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

**FOX ★** · 05/03/08 12:30:29

1) 直接 live15 から持ってくる、 (front end を増やすのが簡単じゃないかも)
2) 専用の black goat 経由で持ってくる、(スケールとの兼ね合いで高コスト?)
3) あと　どうやるの?

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

**root▲ ★** · 05/03/08 12:34:36

おぉ、、、。
めしの後で、レスします。

**root▲ ★** · 05/03/08 14:00:26

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)でいいんじゃないかなぁと(これは、甘く見てるかも)。

私のおすすめ度: ★★

**root▲ ★** · 05/03/08 14:04:38

で、キャッシュを持つ実験として、ミニ雪だるまを動かしています。

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

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

**FOX ★** · 05/03/08 14:07:33

混乱しないように ex7 で話しをすすめることにしよう。。。

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

**root▲ ★** · 05/03/08 14:20:10

簡単な図にすると、今まではこんなかんじで、

ユーザ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で同時に何百人を相手できるので、
その部分での効果も、期待できます。

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

**root▲ ★** · 05/03/08 14:21:05

topだと、0点台です。=> CPU1%以下、という意味です。

**root▲ ★** · 05/03/08 14:30:24

補足をひとつ:

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

**FOX ★** · 05/03/08 15:18:31

つまり　squid を独立した別サーバで動かすと
それはまさに black goat であるということですかねぇ

**root▲ ★** · 05/03/08 15:34:03

>>137
そうですね。
今のblackgoatでは、squidがせっせと動いています。

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

BSD Magazineで小飼弾さんがSquidリバースプロクシの記事を書いていたなぁ。
お昼にワイドスクランブルに出演してたのを見て吹いたけど。

**root▲ ★** · 05/03/08 16:25:48

>>139
その記事、前にちょっと読んだです。
そんなことも思い出しつつ、設定していたり。

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

**root▲ ★** · 05/03/09 02:58:59

で、subject.txtの304が増えることと、それは果たして負荷軽減なのか、
っていう話を、書いておこうかと。

通常の場合

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

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

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

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

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

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

**FOX ★** · 05/03/09 03:02:06

それは squid を入れたからなるんですか?
そうじゃないと思うんですが、

**root▲ ★** · 05/03/09 03:09:45

で、今回、ビューワとサーバ(httpd)の間に、squidを入れました。
squidはオンメモリとかディスク上とかに、他の人に送ったsubject.txtをたくわえています。
ここでは、現在の設定に従って、オンメモリで考えます。

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

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

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

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

を、確認してみます。

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

**FOX ★** · 05/03/09 03:13:01

>他の人に送ったsubject.txt

これなのかな?

**root▲ ★** · 05/03/09 03:14:04

>>144
それしか、考えられないですが。
だとすると、squid => httpdのリクエストがどうして出ているのかが、、、。
しかも、答えは304。

**FOX ★** · 05/03/09 03:14:40

別の話しですが

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

**root▲ ★** · 05/03/09 03:16:14

open send close ですね。sendはジンギスカンでも節約できないです。

**FOX ★** · 05/03/09 03:16:44

>>145
squid => httpd のリクエストはでるでしょ
それの回答が 403 なだけで

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

**FOX ★** · 05/03/09 03:19:01

squid => httpd の回答は send じゃないんですか?

**root▲ ★** · 05/03/09 03:19:50

19:00-19:59 JST

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

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

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

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

**root▲ ★** · 05/03/09 03:20:17

>>149
403 だと、本体のsendは起こらないです。

**root▲ ★** · 05/03/09 03:22:50

これは、squidが何をクライアントに返しているかは、別にとらないとだめですね。
304 なのか、本体をずるずる返している(ないと思うけど)のか。

**FOX ★** · 05/03/09 03:24:09

403 だったら、 memory disk でも send が起らないと思うんですが、

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

**root▲ ★** · 05/03/09 03:27:04

で、httpdのログとってみました。>>150 のつづき

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

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

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

**FOX ★** · 05/03/09 03:27:51

>>129 >>131
私は black goat 方式が良いのでは?
と思って >>131 の 2) を書いたのです。

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

**FOX ★** · 05/03/09 03:28:34

>>129 >>131
私は black goat 方式が良いのでは?
と思って >>129 の 2) を書いたのです。

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

再投稿すんません

**root▲ ★** · 05/03/09 03:29:04