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

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

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

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

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

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

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

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

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

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

補足をひとつ:

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

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

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

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

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

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

で、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をビューワに送るコスト
・その分のネットワーク転送量コスト

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

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

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


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

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

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

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

を、確認してみます。

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

>他の人に送ったsubject.txt

これなのかな?

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

別の話しですが

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

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

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

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

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

19:00-19:59 JST

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

再投稿すんません

総数 >>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

>>156
ふむ。

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

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

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

ということで私がいまやっているのは、

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

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

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

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

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

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

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

達成したいこと

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)

Front end は単純な　ろびんちゃん

目的1について

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

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


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

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

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

>私の目論見では二倍だったら black goat なし Front 三台で
>こなせると思っております

うわ、結婚したかも。

今のex7での実験は「現状を延命させる」実験としてかなり面白いので続けようと思いますが、
(ヒット率3割も出ると思わなかった)

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

開発といっても

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 は楽になると思う

>>165 ふむふむ。

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

>>160 の単純な形(第一歩)としては

Front1
　↓↑
live16

だと思うんですよね、

>>166

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

>>167
ですね、、、下がlive8だったりしますが、
やろうとしているところだったりしました。

>>168
できれば、そうしたいと思っていました。
cのフロントとおなじ乗りで。

んで　live15 で実験しませんか?
なぜなら あいている banana があるわけで、

front1 , front2
↓↑
live15

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

最初は、squidの非同期I/Oならかなりはやいはずだから、I/Oさせてもいいかなぁとか
思っていたんですが、今日の結果を見て(まだdiskd試してないからあれだけど)、
やっぱりフロントエンドでI/Oさせるのはかなりつらいのかなと、改めて思いました。

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

>>171
やりますか。

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

第一弾としては

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

これで天井測定

こんな感じかしら?

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

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

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


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

それでいきますか。

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

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

>>175
どもです。
> 毎回ロードとリロケーションを行っていると思います。

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

そですね、

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

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

>>178
さて、今liveb1って名前ですが、、、。
そのまま、使いますかね。

いいんじゃないですか、
作る cgi 等も、ぐちゃぐちゃぺたぺたで最初は作りますし、
本番はlive16,live8のときですから、

おっと　二台ありませんでしたっけ?
使っていないbanana

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

未使用は、1台のはず。

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

eq.2ch.netでつかっちゃったからね。

んじゃ　pie工事後にbananaを一台投入するということで、

あっ　そうか・・・　>>184

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

ぐっ　>>183 だった

read.cgi をフロントエンド側で走らせる場合，squid で dat をキャッシュさせるとなると，
dat を直接 open() はできないでしょうから，squid に対し HTTP リクエストを発して
取ってくるということになるんですかね．>>175 さんのおっしゃるようにバックエンドで
read.cgi を走らせてフロント側でキャッシュというのとどちらがいいのか......
まぁ実験しないとわかりませんね．

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

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

http://www.mail-archive.com/[email protected]/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.

ほう。
つまり、1プロセスならば問題なさそう、という事ですね。
むしろ願ったりな状況なのかも。

>>188
おー。

やってみるか。

杉花粉で雪だるま・・・orz

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

DISKDは速いディスクなら圧倒的にパフォーマンスいいよ。
ただ、failしたときどうすんのか。

よー分からんけどスレを全てメモリで保持、バックアップ(ハードディスク書き込み)を外部で行えばいいんじゃないの?

>>194
すでにメモリディスク＝通称ジンギスカンは導入され絶大な成果を挙げていますが何か

datフォルダは今のところジンギスカンの対象外じゃなかったっけ、、

>>196
やっぱりジンギスカンは高いから？

>>196
そーでしたかしら
だったらスマソ

aliveなスレ（掲示板上にあるやつ）と過去ログ倉庫を
明確に分けたらうまく逝くのかのう？

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

>>199
マシン感転送に時間かかりそうだしなんだか遊んでる資源が増えそうなようかん

>>200
ああ、云われてみればそうかものう。。。

とりあえずHDD送りはLAが一定以下でbbs.cgiがコールされたとき限定でいいんじゃないかしらと言ってみる

>>202
電源落ちるかメモリが逝くとデータが全部消えるんですが
サーバ室侵入で電源「プチっ」とかやられたら

だんだん雪だるまの趣旨から外れてる希ガス…
ま、外野だからいいかｗ

>203
ＰＩＥのセキュリティ体制を知らないのかと小一時間（ry

>>204
すんまそん・・・

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

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

そういえばDB Magazineのはてなの記事は読んだ？
MySQLのレプリケーションを使って、参照系のサーバーを更新系DBにたくさんぶら下げて。
多数のreadを参照系でさばいて、少ない書き込みは更新系だけで処理するんだって。
んで参照系はメモリを2G積んだサーバーでtmpfsにDBを置くと。

こんにちは。

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

基本動作は

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

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

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

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

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