【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part15

質問です

1) SpeedyCGIはPerlを高速化するものですか?
2) bbs.cgi or bbs.cgi がrequire しているファイルが更新されたとき
　　何かしなければいけませんか?

1)Perlのプロセス起動をへらすので結果的に
2)再読み込みが必要なのでapachectl graceful

>>691
ちと長くなるので、別々に答えます。
まず結論から。

1) Yes

動作原理は後述します。

2) 現在の2chの運用形態なら、bbs.cgiの配布・保守形態は現在のままでよい

2-1)親bbs.cgiがrequireしているファイル、
例えばbbs.cgi主処理部(頻繁に変更される方)が
更新された場合は、特に何もする必要はありません。

なぜかというと、現在の２ちゃんねるでのSpeedyCGIの運用形態が
「バックエンドエンジン毎回起動モード(-r1)」だからです。
理由は後述します。

2-2)親bbs.cgiそのものが更新された場合は、>>659にあるように、
bbs.cgiの1行目を#!/usr/bin/perlから
#!/usr/local/bin/speedy -- -r1 -t60に変更する必要があります。

ただし、急いで変更しなくてもSpeedyCGIのパフォーマンスにならないだけで、
従来のPerlのパフォーマンスで動き続けるため、運用にすぐに支障が出るわけではありません。

現状、親bbs.cgiにはめったに更新がかからないため、
親bbs.cgiに変更がかかったのを私が知ったら、その都度作業するというポリシーで、
当面はいけると考えています。

# というか、想定質問っす(w。

## 後述は、めしくってから書きます。

ちなみに、bbs.cgi主処理部が更新された場合に
ちゃんとそれが即座に反映されることは、実地に確認してありますです。はい。

bbs.cgi がこれによってかなり美味い具合になってきたとすると、
もう一つほとんど更新されないcgiがあるわけですが、
そっちはどのような方針がいいんですかね?

1) Perl にして同様にSpeedy化する。
2) C のまま、Apache のモジュール化する。

2) の方が効果があると思ってはいますが、
実は 1) でも 2) の90% くらいの効果が望めるので 2) にするとか?

read.cgi ですが、

今既にCで書いてあるもので、かつコンパクトなプログラムなので、
私は 2) がよいと考えていますです。
めざす方向は、mod_readがいいなと。

1)にして効果を上げる(SpeedyCGIの本来のパワーを発揮させる)ためには、
それなりにきちんと(Per作法l的に)プログラミングする必要があるようです。

今のbbs.cgiはいわば「SpeedyCGIを使ううまみの1割も使っていない」状況です。
それも、あわせて後述を。

んじゃ　若さの暴走ということで
mod_read に挑戦してみますかー

と、

以下はにわか勉強なので、間違い・不足な点はご指摘いただけるとたすかります ]

・SpeedyCGIの動作原理

SpeedyCGIは、フロントエンド部とバックエンドエンジンに分かれています。
フロントエンドは、ApacheモジュールまたはCGIプログラム(/usr/local/bin/speedy)として呼ばれます。

フロントエンドはバックエンドエンジンがいなければ起動し、Perlプログラムをプロセス間通信で
バックエンドエンジンに渡します。

バックエンドエンジンはPerlプログラムを＊実行前に＊コンパイルし、できた中間コードをメモリ上に展開し、
それを実行します。

つまり、Perlをインタプリタで実行せず、コンパイル後のバイナリを実行するようになるため、
その分実行が高速になります(効果1)。

その後、デフォルトではバックエンドエンジン側の処理が終わっても、
コンパイル後のバイナリコードは開放されることなくバックエンドプロセスのメモリ上に残り、
次に同じプログラムのリクエストをフロントエンドから受けた場合、
cgiプログラムが更新されていなければ
(ここで本体cgiの時間をチェックし、更新されていれば自動的に再読み込み&再コンパイル)、
同じバイナリコードを、そのまま再利用します。

つまりデフォルトでは、2回目以降はバックエンドエンジンの再起動なし、
再コンパイルなしでそのままバイナリコードが動きます。
ということで、動作がとても高速になります(効果2)。

しかし、この場合Perl側でコードの再利用(主に変数関連)を考慮した、
行儀の良いコードを書く必要があるため、
場合によっては、Perlプログラム側を行儀の良い形に書き直す必要が出てきます。

で、bbs.cgiは残念ながらこれに該当したため、デフォルトの状態では動かなかった。

(続く)

(続き)

これを避けるために、SpeedyCGIのオプションとして、
バックエンドエンジンの再起動インターバルを指定することができるようになっています。
これが、#!/usr/local/bin/speedy -- -r1 -t60 の -r1 のところです。

ここで1を指定してあるため、1回ごと(つまりフロントエンドが起動されるたびに、毎回)、
バックエンドエンジンを起動しなおすことになります。
つまり、上記の(効果2)を捨てることになるわけです。

といったところが、SpeedyCGIの私の理解です。

で、量産型bananaにもSpeedyCGIを入れていただけると、
全部のマシンのbbs.cgiを
#!/usr/local/bin/speedy -- -r1 -t60

にできるので、bbs.cgiの管理が楽になったりするです。



>>697
おおっっ。

もったいなかと、

なお、デフォルトのモードの場合、requireしているほうの子供Perlプログラムが更新された場合には、
自動的には更新を検知できないため、
その場合には >>692 にあるようにApacheをリセットするか、
親cgiをtouchする必要があります。

# ２ちゃんねるの場合「毎回起動モード」なので、たまたましなくてもいいと。

>>701
ですよ(ο･д･)(･д･`ο)ﾈｰ

bbs.cgiを、具体的にはどう改良すればいいんだろうか。
>>638-639 あたりが答えの一部?

>>703

気分が盛り上がっているので
先に　read.cgi に挑戦したいなと、


read.cgi再開発スレ
http://qb5.2ch.net/test/read.cgi/operate/1087199303/

>>704
てなわけで、今日はなんだか記念日みたいです。

bbs.cgi の speedy化の効果２をねらう改造の為に
サブドメインが必要な気がしまーす
read.cgi も一緒にやるか、

やっぱ明日、tiger に一個サブドメイン増やそうぜ

>>706
了解です。

今日は、いい気分で寝られそうな気がするですよ。

電子雑誌だったらできそうな悪寒＞ここのスレのログっぽいの

＞697 ：FOX ★ sage ：04/11/29 01:00:06 ID:???
＞んじゃ　若さの暴走ということで
＞mod_read に挑戦してみますかー
↑これ、笑うところ？

質問・雑談スレ81＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1101642955/79-82 を前に、
live8 の bbs.cgi を perlcc 版から SpeedyCGI 版に変えてみた。

昨日の座頭市の時のLAの上がり方から考えて、
毎回起動モードでも、SpeedyCGIの方がいい気がするんで。

live8 だけ、read.cgi の時も KeepAlive を有効にした。

今の設定:

#
# Thank you for http://qb5.2ch.net/test/read.cgi/operate/1093068260/391-393
#
SetEnvIf Request_URI ^/test/bbs\.cgi nokeepalive
SetEnvIf Request_URI ^/test/subbbs\.cgi nokeepalive
#SetEnvIf Request_URI ^/test/read\.cgi nokeepalive <= ここをコメントアウト

たのしみ　たのしみ