今回も、めちゃくちゃコンピューターチック話。
＃興味ない人はとばしてちょ。

で、Reverse Proxy運用を開始しました。

左側がフロントエンド。右側がバックエンドです。
＃読めないと思うので、クリックして拡大してみてちょ。

ええっと設定状況をまとめると、

１．フロントで、静的コンテンツを返します。eventＭＰＭを選んじゃいました。
　　keepalive時間は大目で、100個の接続を面倒見ます。
２．バックエンドは、動的コンテンツを返します。preforkです。
　　コネクションは３つ。
　　で、大まかな設定として、フロント側では、

RewriteCond %{LA-U:REQUEST_FILENAME} \.(cgi|pl|php)$
RewriteRule ^/(.*) http://www.gakitama.com:8080/$1 [L,P,QSA]

って感じです。バックエンド側は普通に８０８０番をListenするだけ。でも、同じディレクトリを参照するようにしてます。（これのために、ちと、面倒なことしなきゃいけないんですが、ｋろえは後述。）
あとは、細かい話だけど、
１．フロントもバックも同じmakeだが、動的に、必要なモジュールだけ（ＭＰＭも含め）ロード。
　　apacheの、２．３．１４あたりからの新機能です。(loadable MPM)
　　フロントのＰＭＡＰ

# pmap 30110 | grep Total
Total Kb 14504 8064 7060 8772
中略、、、２５回繰り返し。スレッド分出てるのかな？
Total Kb 14504 8064 7060 8772
#

　　　なぜかスレッド分の２５個が繰り返し出てきますが、表示上の話かなと、、、
　　　右側の８７７２キロバイトというのが、プロセスで、Privateで使うメモリーなのですが、これが、
　　　全部８７７２なので、重複して、でてるんだあ、、と勝手に思ってますが、、、（だれかおしえてちょ。）

　　　次に、ＰＭＡＰのバックエンド

# pmap 30116 | grep Total
Total Kb 58696 22680 19048 40280

　　　　おっと、プロセス固有で、４０２８０キロバイトも使ってますね。
　　　　これは、、、実は、そのうち３２Ｍは、ＡＰＣで使ってます。（後述）

３．DirectoryIndexに、index.html index.php とかしてると、ちょっと面倒な苦労があります。
　　backendにindex.phpをさがしに行くとバックエンドで動いてしまうので、ちょっと工夫がいる。
４．ProxyPassReverseは設定してないけど動いてます。
５．フロント側には、メモリーが勿体無いので、mod_phpをリンクしてないんですけど、そうすると、
　　.htaccess に、php_valueとか書いてると、これもまた、面倒なことを考えなきゃいけない。
６．同じようなことを実現するのに、fcgi proxyというのが、有るらしいので、こちらをいろいろと調べたが、
　　fcgistarterの使い方がわからんちんで、もっちょっと待とうかな。
　　ちなみに、他にも、選択肢がいろいろあります。（mod_fcgiとか、mod_fastcgiとかあります。）
　　が、mod_fcgi_proxyが、主流になるという予想なんですが。（私の予想はだいたい外れますけど。）

ま、そんなところかな。

で、ＡＰＣも導入しました。
これ、ＰＨＰのコンパイル結果を、キャッシュしてくれるというもの。
とりあえず、うちのサイトの思いつくＰＨＰを動かした後の状態。

キャッシュの３２Ｍのうち、５．４Ｍだけで、うちのサイトはほとんど入っちゃう、って感じですね。
この３２Ｍは、プロセス同士で共有されてると思うんですが、PMAPでprivateのところにでてくるというのは、なんじゃろな。（これもだれか教えて。
あ、以下のように無名ブロックのところに出てきます。

# pmap 30116 | tail
29620000 16 4 - 16 rwx [ anon ]
29700000 1024 980 - 1024 rwx [ anon ]
29800000 32768 5552 - 32768 rwx [ anon ]
2B800000 1024 808 - 1024 rwx [ anon ]
2BF00000 1024 1020 - 1024 rwx [ anon ]

BFBE0000 128 48 - 128 rwx [ anon ]
-------- ------- ------- ------- -------
Total Kb 58696 23424 19048 40280
#

で、とりあえず、効果としては、apacheのＡＢで計ったところ、PHPのＣＰＵ使用時間は、３分の２程度には、なっています。

ま、いいっか、、、
、

＃今回は、めちゃくちゃコンピューターチックな話。
＃苦手な人は、とばしてちょ。

家鯖のＷＥＢを、ＲｅｖｅｒｓｅＰｒｏｘｙ構成にしようと、目論んでます。

今は、Ｗｅｂサーバーだけで、そこにＰＨＰをモジュールで動かしています。
特に、充電生中継というツールが、非常にメモリーを食うので、通常に、フロントのＷｅｂサーバーで、大量のpreforkをすると、ちと、メモリー的につらいかも、、、
というのがあり、今は、実は、preforkを７本で固定にしてます。
なんで、７本って中途半端な数字かといえば、画像がたくさんあるようなページだと、最近のブラウザは６本も同時接続しやがる、という関係で、一本ぐらいのこしてやろうか、、、なんて感じ。
＃ま、あまり意味のない残し方ですが、、、
で、ＫｅｅｐＡｌｉｖｅは１秒と、短くしてます。
ま、ここまで節約しなくても、、、という気はしますが、、、
ただ、それで十分はけるほどのリクエストしか、来ないんですけど。

で、計画としては、以下のような感じ。
　　１．フロントのサーバーは静的コンテンツを返す。
　　　　（１）つまり、リバースプロキシー
　　　　（２）workerを使って、５０ぐらい、スレッドをうごかしてあげる。
　　　　（２）keepaliveは、５秒ぐらいに増やしてやるかな。
　　２．バックエンドにＰＨＰやＣＧＩのプログラムを流す。
　　　　（１）プロセス数は１とか２とかで固定。
　　　　（２）当然prefork
　　　　（３）keppaliveはしない。
　　３．１と２のプログラムのビルドは、同じものを使う。
　　　　（１）つまり、apache 2.3のloadable MPMを使う
　　　　（２）できるものはすべてＤＳＯにして、実行時にリンク
まとめると、リバースプロキシーをメモリー節約のために使おうかと。で、あまったメモリーをkeepaliveに使ってやる、って感じ。（サーバーは１台で、フロントとバックエンドのＡｐａｃｈｅを動かします。）

とまあ、計画的には完璧なはずが、１（２）のworkerで、はまった感じかな。

いやあ、いろいろとベンチマークとかやったんですけどね、、、
どういう現象かといえば、同じリクエストをさばくための、メモリーが、結局preforkのほうが少なくて済む、、、
というもの。スピード（ＣＰＵ使用時間）も、そう変わらん感じ。

なんでなんでしょうねー
メモリー量については、コード部分や定数部分は、もともと共有する機能が、ＯＳにはついてるので、個別データ部分が違うかと思ったんですけど、、、、
まあ、よくよく考えてみれば、スレッドごとにプライベートにメモリーを使っちゃったら、一緒だし。
ＣＰＵについても、プロセスの切り替えが少ないＷｏｒｋｅｒのほうが有利かと思ったんですが、ＵＮＩＸなんて、プロセスが軽いＯＳだと、プロセスの切り替えに負荷もほとんどないのかなあ、、、とかおもっちゃったり。

ということで、なんのこっちゃ、という感じです。
ま、本気でお仕事でやってるわけじゃないので、テストに失敗してる可能性もありますが。
ま、今、２．３はベーター版なので、リリース版が出たら、もっぺん試すかな、、、

で、翌日追記

ちゃんと、意図通り動きました。というか、正確には、動くと思います、が正しいけど。
意図というのは、workerにして、keepaliveをたくさん面倒を見たときに、preforkよりメモリー節約になる、ということ。
ただ、期待してたほど、メモリーの節約にはならなかったですけどね。

今回の反省：
　　apacheのabだけで、こんなテストをするのは、かなり難しい。
　　　　例えばswapされても、使わないモジュールが使ってるメモリーが追い出されるだけ。
　　酔っ払ってベンチマークをしても無駄だ。

で、最初に書いた、「動くと思います。」だけど、実際にレスポンスやスループット等の差に、現れるようなテストは、かなり大変なので、やりませんです。

というか、数秒に１回ぐらいしか、ユーザーがアクセスしない、このサイトを、数百、数千、数万ユーザー向けに、まじめにチューニングしてもなあ。


あ、嘘ついた。
誤：　数秒に１回ぐらいしか、ユーザーがアクセスしない、このサイト
正：　数秒に１回ぐらいしか、ユーザー（ロボットも含む）がアクセスしない、このサイト

以上　　

以下、チェーンの構造がわかってることを前提に書いています。
チェーンの構造は、自転車探検の、チェーンの種類および構造を見てください。

で、チェーンが伸びて寿命、というのは、自転車に乗る人は、割と知ってることです。
で、チェーンが実は伸びるものではなく、減るものであることは、知らない人もいます。
チェーンが減ってというのは、チェーンのピン、あるいはブッシュの内側が減ることであり、

前に計ったこの計り方は、それを計るのに、いい方法だと。
（左側の寸法に、右側で計った外プレートの寸法を足して測るという計り方。

ところが、この方法は、チェーンの伸び（＝ピンとブッシュの内側の磨耗）を測定しているだけで、チェーンが減ったことを測定するのは、この方法だけではダメ、という気がしてきました。

つまり、ローラーの内側と、ブッシュの外側も減るのではないかと。
ということで早速測定してみました。

これで計った寸法に、ローラー外径の７．８ミリを足せば、一コマ分の１２．７ｍｍぐらいになるはずです。
もちろん、１コマ分のローラーの遊び分が含まれます。（正確にはピンの遊びと磨耗が含まれますが、これはたいした寸法じゃない。）
で、古いチェーンと新しいチェーンを比較するとブッシュの外側とローラーの内側の磨耗、つまり、本来のローラーの遊びがどれだけ大きくなってしまったかが測定できます。
で測定結果。

	隙間寸法（Ａ） （上の写真）	一こま分（Ｂ） Ａ＋７．８	ローラーの遊び (Ｂ－１２．７）
新品チェーン	5.4	13.2	0.5
古いチェーン	5.8	13.6	0.9

ちゅうことで、ローラーの遊びが０．４ｍｍも大きくなっていることがわかりました。
この間測定したのは、チェーン１０コマ分のピンの遊びの増加分であり、それが０．５７ｍｍであることを考えると、これは、かなり大きい磨耗だと思います。だって、一コマだけで０．４ｍｍですよ。

ちゅうことで、この２つの数値（ピンの遊びの増分と、ローラーの遊びの増分）を共に管理していくのがよいかと思います。
一般のチェーンチェッカーで計ってるこの計り方、

は、１コマ分のローラーの遊びの増分と、１０コマ分のピンの遊びの増分を合わせて計っている、ということですね。これはこれで、いいんでしょう。
でも私は、２つの数値を別々に管理しておこうかと。

ちゅうことで、半分自分メモ。
チェーンの伸び測定２０１１年８月９日
あえて、解説はしません。
以上で書いたことを理解して、計算式をみれば、だいたい意図はわかるかな、、、わからないかな？
勝負自転車のランドナーは、５０００キロ走ってるけど、この程度しか磨耗してないというのは、すごいでしょ。
あと、ローラー（とブッシュの外側）は減ってるけど、ピン（とブッシュの内側）はぜんぜん減っていない、というのも、興味深いです。

前のエントリで書いた、賞味期限の間違い問題で、再送されてきた。
しかしまあ、ラッキーとしかいいようがないなあ。

本来の優待のこれ、

に比べて、量的には、半分以上も入ってる感じだよ。