【激速】mod_perl SpeedyCGI FastCGI【激速】
at PHP
1:nobodyさん
06/06/05 20:01:09 +YcYjDiD
mod_perl
URLﾘﾝｸ(perl.apache.org)
SpeedyCGI
URLﾘﾝｸ(perldoc.jp)
前スレ
mod_perlを使おう！
ｽﾚﾘﾝｸ(php板)
ー二三ヘ( ﾟ∀ﾟ)ノ
2:nobodyさん
06/06/05 20:05:13 BE:141505128-#
僕の肛門も高速化されそうです
3:nobodyさん
06/06/05 20:31:26
mod_perlを04Webserverで使用してみたいのですが、
mod_perl.dllの仕様、使い方について解説されている
ページとか有りませんか？
4:nobodyさん
06/06/05 23:59:14
そんな馬鹿なことせずに apache 使えばよろし。
5:nobodyさん
06/06/06 21:19:24
SpeedyCGI使えばPerl側だけの問題で済ませるやん。
6:nobodyさん
06/06/07 16:43:05 2I/qpjTz
前スレに書いちゃって、誘導されてきました。前スレ995です。
↓こういう質問なんですが・・・。
mod_perlを設定中な者ですが、一つどこのサイトにも明示的には書いてない気が
して、あきらかにしたいんですが、、、
ModPerl::Registry を使って .cgiを動かしても、その.cgiファイル内からuseしたり使
っているモジュールは、別途PerlRequireで指定のスクリプト内でuseしてロードしな
ければならないのでしょうか？
現在実験している環境だと、PerlRequire経由でuseでロードしないモジュールは、
perl-statusの "Loaded Modules"には出てきません。僕の勝手な想像では、
「ModPerl::Registryが呼び出した.cgiがuseしているモジュール」は、適宜ロード
されて、perl-statusにも表示されるんじゃないかと予想していたんですが、それは
ちがうんでしょうかね？
当方の設定ミスなのか、仕様なのかがいまいちはっきり分らないので、聞いてみます。。。
7:nobodyさん
06/06/08 20:07:46
どのタイミングで、どのプロセスが、モジュールを読みこんでいるのか？
どのプロセスが読み込み済みのモジュールをチェックしようとしているのか？
ってのを意識しながら動作検証するといいといいんじゃない？
8:nobodyさん
06/06/13 00:27:19
mod_perl時の場合END{}はプロセスが終了した時のみに実行されますが
mod_perl時にPerl/CGIのEND{}と同様の事をしたい場合どうするのが一番良いのでしょうか。
9:nobodyさん
06/06/13 00:58:15
>>8
mod_perlにそういうhookが用意されていないと無理
10:nobodyさん
06/06/13 01:02:12
たいていオブジェクト指向バリバリで書くからsub DESTROYでも用意しておけばいいんじゃね？
11:8
06/06/13 02:41:06
了解です、ありがとうございます。
取りあえず
*CORE::GLOBAL::exit = sub { hogehoge(); \&Apache::exit } if$ENV{MOD_PERL};
のようにしてexitをオーバーライドしてexitの前に割り込ませる事にしました。
どんな処理でも必ずexitされるわけではないですけど。
12:nobodyさん
06/06/13 05:42:25 dXS5mc+F BE:76526-#
mod_perlをapacheで走らせてるときに、
apacheのerror_logに任意のテキストを出力したりすることって
出来るんでしょうか？
13:nobodyさん
06/06/13 06:11:59
stderrにprintしる!
14:nobodyさん
06/06/13 06:30:45 Nn2106Uk
mod_perlなら
URLﾘﾝｸ(search.cpan.org)
これ。
mod_perl2なら
URLﾘﾝｸ(search.cpan.org)
これかな？
15:nobodyさん
06/06/13 06:49:31 dXS5mc+F BE:303168-#
おぉ、どうもですー。
16:nobodyさん
06/06/13 12:49:11
Log4perl とか使えば、あんなことやこんなことできるんでは？
17:nobodyさん
06/06/13 20:23:39
前スレから疑問なんだけど、なぜにSpeedyCGIではなくmod_perlなの？
両方使ったが、
１．体感スピード
同じ
２．メモリ消費
愕然とするほどの差
３．導入の障害
圧倒的にSpeedyCGI有利
どちらもPerl専用アクセラレータだけどわざわざ選ぶメリットが見つけられん。
18:nobodyさん
06/06/13 20:36:37
Apachモジュールをperlで書けるからでしょ。
19:nobodyさん
06/06/13 20:39:24
> ２．メモリ消費
> 愕然とするほどの差
何か間違えてない？
20:nobodyさん
06/06/13 21:03:44
>>18
> Apachモジュールをperlで書けるからでしょ。
でしょうね。
アクセラレータとして使うメリットはみつけられない。
>>19
> > ２．メモリ消費
> > 愕然とするほどの差
>
> 何か間違えてない？
そのままお返しします。
mod_perlをはじめて使った時は感動したが、後で愕然とした。
しかも太る一方。
topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
そのまま使い続けたが、他のアプリがスワップしはじめガリガリいいだしたのでSpeedyCGIに変えた。
21:nobodyさん
06/06/13 21:05:17
しかも太る一方。
topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
↑間違い
topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
しかも太る一方。
22:nobodyさん
06/06/13 22:00:36
> mod_perlをはじめて使った時は感動したが、後で愕然とした。
> しかも太る一方。
> topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
apache の設定がわからんからといって、mod_perl のせいにしてはいかんよね。
23:nobodyさん
06/06/13 22:09:37
>>22
めちゃくちゃ言うなあ。
mod_perlをoffにしてapache再起動したら、通常のサイズに戻ったが。
逆にそちらではどれくらいのサイズなんだ？
24:nobodyさん
06/06/13 22:13:19
>>23
> めちゃくちゃ言うなあ。
どこらへんが滅茶苦茶なのだろう。
> mod_perlをoffにしてapache再起動したら、通常のサイズに戻ったが。
そうでしょうね。
> 逆にそちらではどれくらいのサイズなんだ？
アプリケーションの規模によるよね。
25:23
06/06/13 22:15:54
mod_perlでApacheが太るからわざわざリバースプロキシ使ってるんではなかったのか？
mod_perlに限らずmod_php、mod_ruby等もメモリの食いっぷりがすごいが。
26:22, 24
06/06/13 22:19:13
mod_perl 等を使う時は、フロントエンドとバックエンドに分けて使う。
フロントエンドで画像等をさばき、それ以外のものをバックエンドに送る。
バックエンド側で起動する perl のプロセスは、積んでいるメモリで決める。
そこらへん、mixi なり hatena bookmark なりの資料探して読むとわかるとおもう。
27:23
06/06/13 22:20:52
>>24
あほくさ。
> > mod_perlをoffにしてapache再起動したら、通常のサイズに戻ったが。
>
> そうでしょうね。
設定正しいって事やないか。
Apacheでmod_perlのメモリの制御はできん。
> > 逆にそちらではどれくらいのサイズなんだ？
>
> アプリケーションの規模によるよね。
使った事がないんだな。
そんな単純な食い方はしない。
28:nobodyさん
06/06/13 22:22:51 BE:247632847-#
（・∀・）ﾆﾔﾆﾔ
29:nobodyさん
06/06/13 22:23:13
> Apacheでmod_perlのメモリの制御はできん。
メモリの使用量でなく、プロセスの数を調整する。
で、定期的に再起動するようなオプションあるよね。
30:23
06/06/13 22:26:21
>>26
当然そういうことだが。
言葉がうわすべりしてないか？
mod_perlでリバースプロキシ使うのは、
１．mod_perlでApacheが太り、静的サービスの反応が鈍る。
２．解決策として静的サービスには別のApacheを使う。
こういうことなんだが。
何も別マシンにリバースプロキシかけなくても静的サービスのスピード向上はできるよ。
31:nobodyさん
06/06/13 22:27:36
>>30
別マシンとはひとことも言っていませんね。
32:23
06/06/13 22:28:56
>>29
> メモリの使用量でなく、プロセスの数を調整する。
> で、定期的に再起動するようなオプションあるよね。
面白いこと言うな。
プロセスの数は調整できんよ。
ある回数起動したらプロセス死ぬ設定はできるが、プロセスの数は運まかせになるよ。
33:nobodyさん
06/06/13 22:33:31
>>31
いいわけかっこ悪い。
34:nobodyさん
06/06/13 22:34:30
URLﾘﾝｸ(d.hatena.ne.jp)
35:nobodyさん
06/06/13 22:35:32
>>33
どこらへんがいいわけなのだろう。
36:nobodyさん
06/06/13 22:37:57
>>34
で君はそのページをまねて、実際にどれくらい節約できた？
37:nobodyさん
06/06/13 22:41:06
>>35
（・∀・）ﾆﾔﾆﾔ
38:nobodyさん
06/06/13 22:46:22 BE:247632847-#
(´；ω；`)
39:nobodyさん
06/06/13 22:47:05
(´･ω･`)
40:nobodyさん
06/06/13 22:49:19
>>34
URLﾘﾝｸ(d.hatena.ne.jp)
何やこれ。
１．Apacheが太るので子プロセスの数を制限する。
２．静的コンテンツのスピード確保にリバースプロキシを使う。
３．Apache自体をできるだけ太らせない。
当たり前のことやんか。
何も新しいものあらへん。
41:40
06/06/13 22:50:40
というか、これではやはりSpeedyCGI以下。
42:nobodyさん
06/06/13 22:52:30
>>41
どれでは？
43:nobodyさん
06/06/13 22:55:14
mod_perl使いたきゃ、
専用の鯖がいるってことでそ。
44:nobodyさん
06/06/13 22:57:03
>>34
URLﾘﾝｸ(d.hatena.ne.jp)
>テスト機で試した。MaxClients 調整前はめっさ重くなる(SSHまで！)。
>MaxClients 調整後はなんとか耐えられる。
なんとか耐えられるんだってよ。
45:nobodyさん
06/06/13 22:57:10
>>43
？
46:nobodyさん
06/06/13 22:57:44 BE:106128634-#
mod_perl厨
必死すぎ
ﾜﾛﾀ
47:nobodyさん
06/06/13 22:58:02
静的なもんも、動的なもんも、とりあえず一台でさばけて、
なおかつcgiも速くなるってのはどれ？
48:nobodyさん
06/06/13 22:58:52
>>47
規模を書かないと話にならないのでは？
49:nobodyさん
06/06/13 23:00:58
>>48
規模によってmod_perlがSpeedyCGIを上回ることがあんの？
50:nobodyさん
06/06/13 23:03:30
>>48
規模が大きいほどmod_perl不利。
セッション数を捌けない。
規模が小さくてもやはり不利。
無用にApacheが圧迫されている。
51:nobodyさん
06/06/13 23:06:35
FastCGIって、mod_perlやSpeedyCGIに比べるとどんなん？
52:nobodyさん
06/06/13 23:21:03
優秀。
SpeedyCGI同様にプロセス数を自由に設定できる。
Apacheと別プロセスなので、それによってApacheのMaxClientsが制限を受けない。
１．SpeedyCGIは導入は容易。
Perl内部の問題で終わらせられる。
必要ならApacheモジュールもある。
２．FastCGIはアプリ起動用スクリプトと、Apacheの設定が必要。
ただし、ほぼ言語を問わず使用できるので、言語が混在しているサイトには有利。
最近lighttpdとの組み合わせが一部で人気？
スピードはどれも意味のある差はない。
53:nobodyさん
06/06/13 23:23:19
URLﾘﾝｸ(www.dmst.aueb.gr)
54:52
06/06/13 23:26:56
mod_perlは
１．メモリの管理が非常に下手。
２．導入時にmod_perl独自の制限がある。
（カレントDirがPerlとは違う。使えない文法がある）
以上の点でSpeedyCGI、FastCGIに比べ劣るが、逆に有利な点は不明。
55:nobodyさん
06/06/13 23:28:50
FastCGI安定してるなぁ。
応用も利きそうなのでいい感じかも
56:nobodyさん
06/06/13 23:30:20
>>53
古くね？
57:nobodyさん
06/06/13 23:30:47
なんかものすごい自演だらけの予感。
58:52
06/06/13 23:31:48
>>53
ベンチはそれほど意味がないよ。
引用先も、対象ベンチ次第でで結果がころころ変わっている。
しかし、mod_perlはベンチでも負けている記事が目立つ。
59:nobodyさん
06/06/13 23:33:48
>>57
同意。
60:nobodyさん
06/06/13 23:37:01
mod_perl って 3 系統くらいあった気がするけど、だれか違いを説明きぼん。
61:nobodyさん
06/06/13 23:38:41
このスレの住人ってなぜにmod_perlにしがみつくの？
mod_perlは一体どこがアドバンテージ？
62:nobodyさん
06/06/13 23:39:34
なにをもって「mod_perlにしがみつく」ということにしたいのだろう。
63:nobodyさん
06/06/13 23:40:50
>>62
（・∀・）
64:nobodyさん
06/06/13 23:42:15
>>62
（・∀・）ﾆﾔﾆﾔ
65:nobodyさん
06/06/13 23:43:55 BE:53064432-#
出来損ないには愛着が沸くもの
66:nobodyさん
06/06/13 23:44:02
もうmod_perl専用スレじゃないのにね。
67:nobodyさん
06/06/14 00:04:43
C/FastCGIとPerl/FastCGIってどのくらい速度が違うか実践した方います？
Cの方が早いだろうけどインタープリタ部分のコストを除いた純粋な言語の速度対決なら
C/CGI vs Perl/CGIほどの差は出ないと思うのですが実際のところどのぐらい違うでしょうか。
68:nobodyさん
06/06/14 00:05:10
> mod_perlは一体どこがアドバンテージ？
必死だが、答えられないmod_perl厨は逝ってよし。
69:nobodyさん
06/06/14 00:07:07
うーん、こうやって貼り付けたくなるほど出来損ないには愛着がわくなｗ
ｽﾚﾘﾝｸ(php板:2番)
70:nobodyさん
06/06/14 00:12:22
>>67
試してないので机上の空論ですまそ。
Cはコンパイル時に非常に長い時間をかけて最適化を行うので、一瞬でコンパイルする必要があるPerlコンパイラとはやはり根本的な差があると思う。
そうでなければ、Cが今だに強い理由はないと思う。
しかし、大きく差が詰まるのは間違いないよね。
71:nobodyさん
06/06/14 00:14:07
>> そうでなければ、Cが今だに強い理由はないと思う。
Web アプリの分野で？ｗ
72:nobodyさん
06/06/14 00:15:49
>>72
まさか。
速度が必要な分野で。
OS、DB、科学技術計算。
73:nobodyさん
06/06/14 00:17:39
↑
>>71
74:nobodyさん
06/06/14 00:46:51
>>67
Win上で同じくネイティブコードを吐く、VBとCの速度差にビビった経験があるな。
.NETでは言語間の速度差はほぼ無いようだが。
75:nobodyさん
06/06/14 01:56:44
本格的に大規模なサイトだと、重い処理はCで書いて、それをPerlやPHPから使うって言うのが解決策になってるんじゃないかな。
ヤフーとかもそうでしょう。
76:nobodyさん
06/06/14 02:11:38
まぁ各ファイルで共通の手続きはできるだけモジュールに括り出すんだな。
77:nobodyさん
06/06/14 10:24:38 BE:212256083-#
大抵はI/Oがボトルネックだから関係ないべ
78:nobodyさん
06/06/14 12:24:45
>>77
Cの処理速度にはまじでビビるよ。
I／Oかかえていても速い。
79:nobodyさん
06/06/14 13:01:49
CPUが直接食える状態になってるからな。
ボトルネックになるディスクI/Oを減らすために少しでもI/Oの速いメモリに溜め込むけど
その結果メモリを馬鹿食いと。
80:nobodyさん
06/06/14 13:40:58
>>79
mod_perlの馬鹿食いはそのせいだけじゃないよ。
mod_perlはApacheの全子プロセスに問答無用でPerlインタプリタを埋め込む。
コードのキャッシュも全子プロセスが持つ。
結果的に、同じコピーが大量に作られる。
SpeedyCGIを運用しているが、常駐インタープリタは２個で充分。
リクエストが多い時はまたされるだけ。
ちゃんと捌く。
mod_perl運用時に比べメモリ使用量は激減した。
mod_perlはアクセラレータとしては、仕様に大きな問題があると思う。
81:nobodyさん
06/06/14 13:56:47
preforkはアレだが、workerならある程度再利用が有効に効かない？
82:nobodyさん
06/06/14 14:45:30
>>81
その通りなんだけど、workerは1.3系列はダメじゃなかったかな？
効果もある程度だしね。
FastCGI、SpeedyCGIがインタープリタの数等、リソースを自由にコントロールできるのに対して仕様自体が？？？ではないの。
83:nobodyさん
06/06/14 14:58:15
原理的には、プロセス間通信のないmod_perlは速度的に優位なはずだが、
どこのベンチをみても有意な差がない。
というより、むしろ負け気味。
たとえ原理通りになっても、現実には無意味な程度だと思う。
84:nobodyさん
06/06/14 18:02:41
とりあえず、”アクセラレータ"としては、SpeedCGIか、FastCGIでってことでオケ？
85:nobodyさん
06/06/14 19:12:48
無茶な使いかたしなければmod_perlでもいんじゃね？
86:nobodyさん
06/06/14 20:48:26
URLﾘﾝｸ(d.hatena.ne.jp)
>テスト機で試した。MaxClients 調整前はめっさ重くなる(SSHまで！)。
>MaxClients 調整後はなんとか耐えられる。
87:nobodyさん
06/06/14 20:53:08
>MaxClients 調整後はなんとか耐えられる。
>MaxClients 調整後はなんとか耐えられる。
>MaxClients 調整後はなんとか耐えられる。
88:nobodyさん
06/06/14 23:00:35
ベンチマークすら提示せずに否定に走られてもねぇ。
>>80
> mod_perlの馬鹿食いはそのせいだけじゃないよ。
> mod_perlはApacheの全子プロセスに問答無用でPerlインタプリタを埋め込む。
> コードのキャッシュも全子プロセスが持つ。
> 結果的に、同じコピーが大量に作られる。
これに関しては、何を言いたいのかさっぱりわかりませんね。
89:nobodyさん
06/06/14 23:20:34
このスレ見てるとmod_perlうんこな流れだけど
mixiやはてながmod_perlで運用してるのは何か理由があるの？
90:nobodyさん
06/06/14 23:37:09 nPkMVDT9
Apacheモジュールだからというだけで食いつきがいいような希ガス。
本物を見極められない哀れなmod_perler〜♪
91:nobodyさん
06/06/14 23:56:11
>>90
その本物とやらは、どんなものなんでしょう？
92:nobodyさん
06/06/15 00:14:17
まだ自分専用のスレと勘違いしたままのmod_perl厨カワイソス
93:nobodyさん
06/06/15 00:17:47
>>89
> このスレ見てるとmod_perlうんこな流れだけど
> mixiやはてながmod_perlで運用してるのは何か理由があるの？
理由が知りたいから、
「mod_perlは一体どこがアドバンテージ？」
mod_perl厨に聞きつづけてるんだが。
未だに返事はなし。
94:nobodyさん
06/06/15 00:22:57
「mod_perlは一体どこがアドバンテージ？」
これに返事もできない状態で
「mixiが．．．」
「はてなが．．．」
「ホリエモンの子飼いが．．．」
こんな話ばっかりやられてもねえ。
わからいなら、黙っとけ。
95:nobodyさん
06/06/15 00:28:25
>>88
> ベンチマークすら提示せずに否定に走られてもねぇ。
>
> >>80
> > mod_perlの馬鹿食いはそのせいだけじゃないよ。
> > mod_perlはApacheの全子プロセスに問答無用でPerlインタプリタを埋め込む。
> > コードのキャッシュも全子プロセスが持つ。
> > 結果的に、同じコピーが大量に作られる。
>
> これに関しては、何を言いたいのかさっぱりわかりませんね。
とてもユニークな意見やね。
どんなベンチとるんだろうか？
俺ならtopコマンド叩く程度しか思いつかんが。
96:nobodyさん
06/06/15 00:48:36
>>94
同意。
しかもmixiが重いって話になると、今度は
「それはMySQLのせいらしい。」
とくる。
「mixiやはてながやってるから正しいんだろう。」
これ以上のものは見えてこない。
うんざり。
97:nobodyさん
06/06/15 02:30:04
mixiがやろうと、はてながやろうと、間違ってると思えばその通りに発言できる。
それが、こういう場所の良さではないのか？
98:nobodyさん
06/06/15 04:04:13
>>85
”アクセラレータ"としてのmod_perl自体が無茶かと...
99:nobodyさん
06/06/15 04:23:38
実績があるからじゃないの。mixiやはてなクラスなら、フロントサーバとアプリケーションサーバを分けて運用するの、どのみち必須だろうし。
100:nobodyさん
06/06/15 06:12:39
あまりにもレス食いつきの良さに
なんだかアンチmod_perlが必死に見えるよ
落ち着こう
101:nobodyさん
06/06/15 06:18:43
ooとxxどっちが強いレベルだよ
どこにでもいる最強厨
102:nobodyさん
06/06/15 06:25:27 0MUuG1/E BE:170093-#
フロントとアプリサーバを分けるならいいけど、
フロントとしてつかうのであれば、
やっぱりmod_perlのメモリ量は気になるけどなぁ。
mod_perlの技術的なメリットがあるなら
きちんと知りたい昨今。
103:nobodyさん
06/06/15 06:52:48
lighthttpd+FastCGIが最速で終了。
スレタイがアフォすぎだな。
----- ここからまったり雑談スレになります -----
104:nobodyさん
06/06/15 07:02:50 0MUuG1/E BE:341069-#
URLﾘﾝｸ(www.drk7.jp)
たしかに。
105:nobodyさん
06/06/15 07:31:47
lighthttpdなんだよ
106:nobodyさん
06/06/15 07:33:16
>>102
お前はゲームでもやってろ
107:nobodyさん
06/06/15 07:47:54 BE:212256083-#
lighttpd+FastCGIもいいかと思ったんだけど設定がめんどくさそうなんだけど
SpeedyCGIは設定とか要らへんの？
108:nobodyさん
06/06/15 08:31:41
dagに、lighttpd,lighttpd-fastcgi があるけど、このrpm使えぱ設定とか
かなり楽になるのかな？
109:nobodyさん
06/06/15 09:06:57
>>107
SpeedyCGIは設定なし。
１．perlソースのグローバル変数を対応。
２．#!/usr/bin/perl等から#!/usr/bin/speedyや#!/usr/bin/perperl等に変更。
以上で終了。
Apacheは設定もできるが必要なし。
ただし、SpeedyCGIまたはPersistentPerl（中身はコマンド名以外同じ）が入っていること。
URLﾘﾝｸ(rintaro.dip.jp)
110:nobodyさん
06/06/15 09:20:47 BE:265320656-#
すげー
windows用のバイナリは無いんですかね探してるんですけど
111:109
06/06/15 10:06:20
>>110
すまそ。
Linux以外でperl使った事ないです。
112:nobodyさん
06/06/15 10:17:00
>>107
> lighttpd+FastCGIもいいかと思ったんだけど設定がめんどくさそうなんだけど
ぐぐれば、そこらへんに落ちてると思う。
113:nobodyさん
06/06/15 12:47:45
>>112
落ちてはいるだろうけど、
１．lighttpdの導入および設定
２．FastCGIの設定およびアプリ起動スクリプト作成法
これ新しくマスターするの結構、手間がかかるよ。
114:nobodyさん
06/06/15 15:36:14
ところでworker+mod_perlのベンチってどっかにあるかね？
115:nobodyさん
06/06/15 16:04:49
>>83
>原理的には、プロセス間通信のないmod_perlは速度的に優位なはずだが、
>どこのベンチをみても有意な差がない。
プロセス間通信がないことは、応答時間の短縮にはつながっても
スループットにはあんまり影響しないってことじゃない？
116:nobodyさん
06/06/15 18:41:07
>>115
応答時間の短縮≠スループットの向上。
ちょっと理解に苦しむが、どういう意味？
117:nobodyさん
06/06/15 18:53:08 0MUuG1/E BE:133237-#
処理が早いだけで、
多くの処理がこなせるようになるわけじゃないってことすかね？
118:nobodyさん
06/06/15 18:57:53
理解に苦しむといわれても、そのまんまなんだけど。
プロセス間通信がないmod_perlのほうが速いはずだけどベンチマークとったら差がない、ということだから、
mod_perlのほうが応答時間は短くなるかもしれないけど、それはスループットには影響を与えないんだろうね、ちうこと。
応答時間の短縮＝スループットの工場とは誰もいってないよ。
それを主張したら>>115とすごく矛盾してしまうんだけど。
119:115
06/06/15 18:58:33
そういう意味ならその通りだね。
話が脱線してるけど。
120:nobodyさん
06/06/15 18:59:24
↑115→116
121:nobodyさん
06/06/15 19:03:12
む？どこらへんが脱線してる？ふつうにmod_perlの話だと思うし、>>83の話からなんら飛躍してないと思うが。
122:116
06/06/15 19:03:57
>>118
言ってることはよくわかる。
しかし、ベンチの速度の話をしているときに、いきなりスループットは脱線だよ。
スループットが大きく影響するベンチもあれば、そうでないものもある。
ベンチ次第。
123:116
06/06/15 19:07:09
>>121
飛躍しているよ。
言っていることは、一般論としては正しいが、ベンチには反映されにくい。
124:nobodyさん
06/06/15 19:52:51
>>122
どんなベンチマークを想像してんだろ。
おれは ab -c 10 -n 1000 みたいなのを想像してたんだけど。
サーバーサイドの話なんだから、ふつうにスループット重視だと思うんだが、
サーバーサイドのベンチで、スループットじゃないベンチおしえてくれ。
つーか、ベンチマークの話のときにスループットだすのがなんで脱線なんだ。理解に苦しむ。
125:116
06/06/15 20:35:31
こういう事はあまり言いたくないが、スループットの意味を解って使っているのか？
スループットとは単位時間に処理できる量のことだ。
> mod_perlのほうが応答時間は短くなるかもしれないけど、それはスループットには影響を与えないんだろうね、ちうこと。
この話は、mod_perlはメモリを食うのでセッション数を捌けない。
だから、応答時間は短くても単位時間当たりの処理数はあがらない。
こういう意味なんだろうが、それは単純にベンチには出ない。
まずmod_perlへのリクエスト量が多く、mod_perlの処理に支障がある状態のベンチかどうか。
そうでなければ、何の関係もない。
くだらない話だ。
126:nobodyさん
06/06/15 21:01:02
>>125
どういうベンチの取り方だったらいいわけ？
127:nobodyさん
06/06/15 21:44:18
>>126
どういうベンチがいいとかいう問題じゃない。
ベンチは取った条件を考慮しないと、意味がない。
128:nobodyさん
06/06/15 21:58:26
SpeedyCGI,FastCGIを試してみようかなと思い、とりあえずrpmがあるかと調べてみたら、
dagに、
perl-CGI-SpeedyCGI-2.22-1.2.el4.rf.i386.rpm
perl-FCGI-0.67-1.c4.i386.rpm
がありました。
RHEL,CentOS,Fedoraだと、rpmでインストール出来る様ですね。
ちなみに、ファイルの更新日付は、SpeedyCGIが2005/12/25,FastCGIが2006/2/11。
upされたのは、比較的最近だったので、ちょっとびっくり。
129:nobodyさん
06/06/15 22:35:45 BE:212256746-#
URLﾘﾝｸ(daemoninc.com)
130:nobodyさん
06/06/16 03:06:13
>>125
おいおい、今までの話で、「スループット」を誤用したところがあるか？なんでこんな心配されなきゃならん。
まず、
>ベンチの速度の話をしているときに、いきなりスループットは脱線だよ
を説明してくれ。
>こういう意味なんだろうが、それは単純にベンチには出ない。
>まずmod_perlへのリクエスト量が多く、mod_perlの処理に支障がある状態のベンチかどうか。
>そうでなければ、何の関係もない。
あれー、今はmod_perlのベンチマークの話だよね？mod_perlに負荷がかからないようなベンチを勝手に想像されてもなー。
>どういうベンチがいいとかいう問題じゃない。
>ベンチは取った条件を考慮しないと、意味がない。
じゃあどういうベンチマークテストで、どういう条件を考慮すればいいわけ？
おまえの話きいてると、逃げてるだけじゃん。
131:nobodyさん
06/06/16 04:22:13
喧嘩するときはbeか鳥付けないと誰の発言か確認できないよね
132:nobodyさん
06/06/16 05:14:48
>>127
だぁかぁらぁ、どういう条件よ？
133:116
06/06/16 10:29:15
>>130
>>132
mod_perlはそのベンチの条件でセッション数が飽和しているか？
これをふまえて発言しろ。
134:nobodyさん
06/06/16 12:44:16
>>130
> あれー、今はmod_perlのベンチマークの話だよね？mod_perlに負荷がかからないようなベンチを勝手に想像されてもなー。
「mod_perlに負荷がかからないような」ではなくて、
mod_perlにどれくらいの負荷がかかっていて、mod_perlがセッションさばけるかが問題ってことじゃねえ？
「mod_perlに負荷がかかって」いても>129のような軽い負荷だと関係ないっていうことかな。
135:nobodyさん
06/06/16 16:44:07
>>130
（・∀・）ﾆﾔﾆﾔ
136:nobodyさん
06/06/16 18:48:56
>>133
してない。
それで？
137:nobodyさん
06/06/16 21:19:55
>>136
beか鳥をつけた方がよくね？
138:nobodyさん
06/06/16 21:22:19
>>136
> してない。
> それで？
それだと>116氏や>134氏の言うとおりになるんじゃない？
> 「mod_perlに負荷がかかって」いても>129のような軽い負荷だと関係ないっていうことかな。
139:nobodyさん
06/06/16 21:26:06
> beか鳥をつけた方がよくね？
beも鳥もつけずにデマだけ並べるといいということ？
140:nobodyさん
06/06/16 21:36:09
>>139
>116や>134がデマってことは、
mod_perlのスコアがのびない理由はセッション数以外にも理由があるって理解でええの？
141:140
06/06/16 21:37:17
だとしたら、まだ出てない意見なんだけど？
142:nobodyさん
06/06/16 21:40:51
>>140
> >116や>134がデマってことは、
>116や>134は、デマなんですか？
はつみみです。
143:140
06/06/16 21:49:45
漏れは頭悪いんで、>139が誰に対してデマっていってるのかわからんのやけど。
144:140
06/06/16 22:01:28
それ以前に、>139=>142ってことでいいん？
145:nobodyさん
06/06/16 22:02:25
>>143
> 漏れは頭悪いんで、>139が誰に対してデマっていってるのかわからんのやけど。
そもそも、誰かの発言がデマであるというようなことは >>139 では述べられて
ないのでは？
146:nobodyさん
06/06/16 22:03:25
>>144
> それ以前に、>139=>142ってことでいいん？
どのように解釈しようと、各人の自由だと思いますよ。
147:nobodyさん
06/06/16 22:08:18
（・∀・）ﾆﾔﾆﾔ
148:nobodyさん
06/06/16 22:12:47
必死だな
149:nobodyさん
06/06/16 22:36:39
Perl厨わかなくなったと思えば次はmod_perl厨。
収まったと思えば今度は匿名理屈厨。
すごいな。
このスレは。
150:nobodyさん
06/06/16 22:45:16
（・∀・）ﾆﾔﾆﾔ 厨
必死だな 厨
>>149 みたいなの
も定期的に湧くな。
すごいな。
このスレは。
151:nobodyさん
06/06/16 22:47:47
ｵﾏｴﾓﾅｰ
152:nobodyさん
06/06/16 22:48:45
さて、どこらへんの話からループすればいい？
153:nobodyさん
06/06/16 22:48:57 BE:283008184-#
煽り耐性なさ杉ｗ
154:nobodyさん
06/06/16 22:50:17
>>150
お前が一番変。
155:nobodyさん
06/06/16 22:52:21
>>154
まあ、一番と順位づけをするためには、ベンチマーク等と同様に
客観的な基準が必要だよね。
- 何をもって「変」とするかの基準
- 上記「変」の順位付けの方法
156:nobodyさん
06/06/16 22:53:23
でたあ、客観厨。
157:nobodyさん
06/06/16 22:54:27
何をもって．．．とするかの基準。
だってよ。
158:nobodyさん
06/06/16 22:56:08
>>155
>> ベンチマーク等と同様に客観的な基準が必要だよね。
このへんで頭の悪さがばれる。
159:nobodyさん
06/06/16 22:56:15
ｸﾏｰ
160:nobodyさん
06/06/16 22:57:54
>>158
まあ、ベンチが客観的と信じるのは個人の自由だし。
ええんでない？
161:nobodyさん
06/06/16 22:58:30
だな。ｗ
162:nobodyさん
06/06/16 22:59:18
>>160
んだな。
宗教の自由ってやつだ。
163:nobodyさん
06/06/16 23:00:45
そんな宗教もあるのか。
164:nobodyさん
06/06/16 23:02:01
まあほとんど宗教だわな。
165:nobodyさん
06/06/16 23:02:50
宗教に、ほとんどとか程度があるのか。
このスレすごいなー。ｗ
166:nobodyさん
06/06/16 23:04:07
>>165
マジレスすんなよ。
おもろないやつ。
167:nobodyさん
06/06/16 23:05:16
マジレスっておいしいの？
168:nobodyさん
06/06/16 23:14:23
ここまで俺の自演
169:nobodyさん
06/06/16 23:15:31
いや、俺の自演だよ。
170:nobodyさん
06/06/16 23:31:31
mod_perl と SpeedyCGI どっちがいいの？
171:nobodyさん
06/06/16 23:35:07
>>170
mod_perl以外クソに決まってるだろ！
172:nobodyさん
06/06/16 23:36:35
>>171
マジレスすんなよ。
おもろないやつ。
173:nobodyさん
06/06/16 23:38:52
>>170
mod_perl以外を選ぶメリットは何もない。
174:nobodyさん
06/06/16 23:41:09
>>172
そのまま返す。
コピペだし。
175:nobodyさん
06/06/16 23:41:20
>>171 さん >>173 さん、ありがとうございます！
176:nobodyさん
06/06/16 23:43:17
>>175
わかってるようだな。
世界で一番優れた言語mod_perl！
177:nobodyさん
06/06/16 23:45:16
>>176
mod_perl って言語だったんですね！
明日早速会社のサーバに mod_perl 言語を入れて実稼働はじめます！
178:nobodyさん
06/06/16 23:46:13
>>175
いや、言語ではなく神だ。
まだまだだな。
179:nobodyさん
06/06/16 23:48:01
>>177
神を汚れたサーバに入れるなどおそれおおい。
神棚に飾っておけ。
180:nobodyさん
06/06/16 23:49:07
>>178-179
神などという抽象的な存在の話なら、板違いじゃないのかな。
181:nobodyさん
06/06/16 23:53:19
つまらんこというな。
182:nobodyさん
06/06/16 23:54:01
>>181
つまらんこというな。
183:nobodyさん
06/06/16 23:54:12 BE:371448476-#
面白いと思ってるのが痛い
184:nobodyさん
06/06/16 23:56:18
痛いと思ってるのが面白い
185:nobodyさん
06/06/16 23:56:23
このスレは脱線かバトル以外話題がないからな。
そんときだけ異様にのびる。
186:nobodyさん
06/06/16 23:57:03
> そんときだけ異様にのびる。
だって全部おれの自演だし
187:nobodyさん
06/06/16 23:58:02
俺の自演だって言ってるだろ。
188:nobodyさん
06/06/17 00:01:32
まあ、誰が何を主張しようと、言論の自由だもんね！
189:nobodyさん
06/06/17 00:10:56 BE:283008184-#
もっと有益な話をしてくれ
190:nobodyさん
06/06/17 00:11:32
煽り耐性なさ杉ｗ
191:nobodyさん
06/06/17 00:14:20 BE:159191892-#
SpeedyCGIってlighttpdでも使えるん？
今実行できる環境にないので
192:nobodyさん
06/06/17 00:16:56
> SpeedyCGIってlighttpdでも使えるん？
使えないということにでもしたい？
193:nobodyさん
06/06/17 00:19:17 BE:318384094-#
ほぇ？
194:nobodyさん
06/06/17 00:23:38
> SpeedyCGIってlighttpdでも使えるん？
使えるよ。
Perlで完結するので、webサーバーは問わない。
195:nobodyさん
06/06/17 00:25:33 BE:283008184-#
>>194
ありがとう
バックエンドとか云うのは最初起動させとかなくていいの？
shebang行をspeedyに変えるだけでいいの？
196:nobodyさん
06/06/17 00:25:51
> Perlで完結するので、webサーバーは問わない。
デマですね。
/usr/bin/speedy は perl なのかと。
197:194
06/06/17 00:27:22
ただし、ActivePerlの場合は俺は知らん。
PC-UnixでPerlCGIが使えれば問題ない。
SpeedyCGIが入れられないとかいうなら別だが。
198:nobodyさん
06/06/17 00:29:35
> Perlで完結するので、webサーバーは問わない。
と
> ただし、ActivePerlの場合は俺は知らん。
> PC-UnixでPerlCGIが使えれば問題ない。
> SpeedyCGIが入れられないとかいうなら別だが。
とでは、異なる内容になっていますね。
199:194
06/06/17 00:35:58
>>195
> バックエンドとか云うのは最初起動させとかなくていいの？
> shebang行をspeedyに変えるだけでいいの？
変えるだけでOK。
最初に実行した時に勝手にインタプリタが常駐しネイティブコードもキャッシュされるよ。
ただし、デフォルト設定では１時間Callがなければ、すべて解放されてしまうので自分の環境に合わせてコマンドラインスイッチを。
URLﾘﾝｸ(perldoc.jp)
>>196
> /usr/bin/speedy は perl なのかと。
CPANでインストールできるし、Perlドキュメントにも載ってますが．．．？
Perlの公式リリースと思っても間違いではないはず。
200:nobodyさん
06/06/17 00:39:12
> CPANでインストールできるし、Perlドキュメントにも載ってますが．．．？
> Perlの公式リリースと思っても間違いではないはず。
CPAN に登録されていることと、Perl の公式リリースは何ら関係がありませんね。
そもそも「Perlの公式リリース」とは、具体的に何ですか？
201:nobodyさん
06/06/17 00:39:17 BE:141503982-#
凄い
ありがとう
環境が整ったらコンパイルしてみます
202:194
06/06/17 00:39:46
>>198
こだわるね。
正確に言えば、ActivePerlの場合は俺は知らんが、それ以外ならPerlで完結してるよ。
これでいいんだべか？
203:194
06/06/17 00:40:54
しつこい人は苦手でね。
疑うなら、自分でどうぞ。
204:nobodyさん
06/06/17 00:41:21
> 正確に言えば、ActivePerlの場合は俺は知らんが、それ以外ならPerlで完結してるよ。
バックエンドプロセスへ通信するために起動される実行ファイルは
Perl なのかと。
205:nobodyさん
06/06/17 00:42:30
デマばかり流している >>194 氏がかわいそうなので、
間違いを指摘するのは、このくらいでやめてあげてください。
206:194
06/06/17 00:44:43
お好きにどうぞ。
207:nobodyさん
06/06/17 00:45:18
間違いを認めないのは、みっともないねぇ。
208:194
06/06/17 00:47:06
何とでもお好きなように。
209:nobodyさん
06/06/17 00:50:36
>>204
> バックエンドプロセスへ通信するために起動される実行ファイルは
> Perl なのかと。
つ、SpeedyCGIのバックエンドはwebサーバーと無関係。
210:nobodyさん
06/06/17 00:56:47
>>209
> > バックエンドプロセスへ通信するために起動される実行ファイルは
> > Perl なのかと。
は、
>>198
> Perlで完結するので、webサーバーは問わない。
に関しての発言ですね。
> つ、SpeedyCGIのバックエンドはwebサーバーと無関係。
shebang を speedy の変更した場合、
httpd から perl 以外のバイナリが呼び出されて SpeedyCGI の
バックエンドプロセスとやりとりをするわけだから、
> Perlで完結
ということにはならない。
211:nobodyさん
06/06/17 01:03:48
>>210
まあ理屈ではなんとでも言えるよな。
誰もそんなことに関心はないわけだが。
212:nobodyさん
06/06/17 01:05:09
>>211
> 誰もそんなことに関心はない
という思考をしていると思われる人が、
何で >>211 のような記述をしてるのか謎ですね。
213:nobodyさん
06/06/17 01:05:55
？？？
214:nobodyさん
06/06/17 01:09:13
>>210
ほとんどカラミ癖だなｗ
215:nobodyさん
06/06/17 01:09:20
as you like
216:nobodyさん
06/06/17 01:11:10 BE:212256746-#
> shebang を speedy の変更した場合、
日本語でおｋ
217:nobodyさん
06/06/17 03:46:46 v+LZ4Y9O
このスレッドも高速化されてますね。
218:nobodyさん
06/06/17 04:07:05
speedyCGI試してみたけど、確かに速いね。
最初、dagのrpmを入れてみたけど、mod_speedycgiが入っていないのでsourceから起こしてみた。
手始めにhello worldを表示するだけのスクリプトで試すと、通常のCGIと、CGI版speedyCGIは
大差が無かったが、mod_speedycgiだと5倍程度のスピードが出た。
次に、上記hello worldにuse CGI; use DBI を付けてみたら、CGI版speedyCGIは、10〜20倍程度、
mod_s;peedycgiだと、100〜150倍程度のスピードになった。
ちなみに、PHP5.0.4でhello worldを出力すると、mod_speedycgiより、2割位遅い感じ。
PEAR DBをrequireすると、use CGI; use DBIしたCGI版speedyCGIと同程度のスピード。
普通のCGIや、PHP使うのが馬鹿らしくなってきた。
219:nobodyさん
06/06/17 09:36:53
>>218
マジ？
URLﾘﾝｸ(tbox.jpn.org)
ここマシンがリナザウだけどノーマルSpeedyCGIよりかなりベンチが落ちてたんだけど。
自分でも使ったが、自分の場合は体感差はなかった。
Apacheの設定はほとんど無いに近いが。
220:nobodyさん
06/06/17 09:43:47
日本語でおｋ
221:nobodyさん
06/06/17 09:49:36
>>218
> 通常のCGIと、CGI版speedyCGIは大差が無かった
CGI版SpeedyCGIで鯖運用してるが、通常のCGIから劇的に速くなったよ。
どこもそういうことになってるみたいだが。
CGI版SpeedyCGIは1発目の動作は
インタープリタ起動→常駐→コンパイル→キャッシュ→実行
となるから、遅い。
次回からは
最初の４ステップがなくなり実行のみになるので、急激に速度が向上する。
２回以上実行した？
222:nobodyさん
06/06/17 11:17:34
>>219
自分でも信じられなかったので、2台のマシン(Opteron ?GHz CentOS4.3とPen2 200MHz RH9)
で試したけど、同じような傾向が出た。
ザウルスのサイトも見ているんだけど、本当にmod_speedycgiで動かしているのかなという
気がしている。お恥ずかしながら、私も最初、大差無しの結果を出していたが、原因は、
LoadModuleをしただけで、cgi-binの下でcgiとして動かしてしまっていた事。マニュアルにある
様に、ディレクトリ切って、SetHandlerしたら、桁が上がった。
#!/usr/bin/speedy
use CGI;
use DBI;
print << "EOT";
Conent-Type: text/html
<html>
<head>
<title>test speedy</title>
</head>
<body>
Hello World
</body>
</html>
EOT
を、遅いマシンの方で、ab -n 10 URLﾘﾝｸ(localhost) みたいな事を今やったら、
CGI 1726.281 [ms]
SpeedyCGI(CGI版): 44.240 [ms]
mod_speedycgi: 10.990 [ms]
てな感じになりました。(Time per requestの値)
223:nobodyさん
06/06/17 11:19:33 BE:106128926-#
shebangをspeedyに変えても
ApacheでSuExecは有効になるんですかね？
224:nobodyさん
06/06/17 11:24:38
>>223
実際にはやってないのですまそ。
SpeedyCGIはSuExecはOKだったはず。
225:221
06/06/17 11:29:26
ソースは
URLﾘﾝｸ(rintaro.dip.jp)
ここを参考に作ったSpeedyCGI版nicky.cgi
ベンチ
ab -n 100 -c 10
CGI SpeedyCGI mod_speedycgi mod_perl
１回目 0.54 6.12 74.24 6.93
２回目 0.54 6.38 74.24 7.16
３回目 0.54 6.41 72.25 7.09
４回目 0.53 6.41 73.86 7.15
５回目 0.54 6.45 74.46 7.19
平均 0.538 6.354 73.81 7.104
あり得ない．．．
速い．．．
アパッチモジュール版SpeedyCGI最強。
>218は発見者
誰もmod_speedycgiは無視してたからな。
226:nobodyさん
06/06/17 11:39:03
>>221
上記のスクリプトから、use CGI; use DBI;を抜くと、
CGI: 49.640 [ms]
SpeedyCGI(CGI版): 43.361 [ms]
mod_speedycgi: 10.968 [ms]
という結果。
スクリプトの中身がほとんど無い状態だと、スピードに差が出なかった。
意味のあるスクリプトは、当然、ぐっと長くなるので、SpeedyCGI(CGI版)でも、劇的に
速くなったと感じられる筈。use CGI; use DBI;しただけで、150倍以上の差が出るので、
3桁の差が出る事も十分あり得そう。(普通のCGIが遅すぎるんだけど)
ちなみに、SpeedyCGIについては、2回立て続けにabし、2回目の結果を書いてます。
自分でも、速くなっている様だけど、？？？な所がある結果なので、追試して貰えれば、
何よりです。
227:nobodyさん
06/06/17 11:47:46 BE:433356577-#
おぉ凄い
228:225
06/06/17 11:49:50
>>226
確かに信じがたいよね。
検証します。
229:218,222,226
06/06/17 11:59:40
>>225
追試ありがとうございます。しかも、mod_perl付き。(^^)
それにしても、mod_speedycgi速いですね。
> 誰もmod_speedycgiは無視してたからな。
私は、一昨日あたりから真面目に調べ出したんで詳しくないんだけど、何でmod_speedycgi
は無視されてたんでしょうか？
あと、FastCGIは、speedyCGIよりも速度的に有利みたいな記述を見かけるけど、比較対象は
speedyCGI(CGI版)なんでしょうか？
これなら、Catalystを試してみても良いかなという気がして来た。
230:nobodyさん
06/06/17 12:47:40
とりあえず。
FastCGI：CGI一般
mod_perl, speedyCGI：perl用
って考えでok?
231:nobodyさん
06/06/17 13:09:03
> >218は発見者
> 誰もmod_speedycgiは無視してたからな。
アメリカ大陸を発見したような話か？
232:225
06/06/17 13:40:36
追試結果。
ぬかよろこびさせてすまそ。
>225の異常な高スコアはただのファイルとしてアクセスされていたためです。
修正後のベンチです。
CGI SpeedyCGI mod_speedycgi mod_perl
１回目 0.45 5.89 7.36 6.35
２回目 0.45 6.06 7.36 6.34
３回目 0.44 6.05 7.37 6.38
４回目 0.45 6.03 7.18 6.4
５回目 0.44 5.92 7.39 6.12
平均 0.446 5.99 7.332 6.318
(Requests per second)
お騒がせして申し訳ない。
233:nobodyさん
06/06/17 13:44:59 BE:397980195-#
SpeedyCGI単体でも十分速いな
234:nobodyさん
06/06/17 13:52:48
print するだけって、とても無意味なベンチですね。
235:nobodyさん
06/06/17 13:57:30
完璧なベンチ希望。
236:225
06/06/17 13:59:41
俺は貴重な時間を割いたので、これ以上はゴメンです。
完璧ではないのは確かですが。
完璧なベンチは難しい。
237:nobodyさん
06/06/17 14:00:00
まずは「完璧なベンチ」の要件から定義していかないとね。
238:218
06/06/17 14:31:37
>>232
お騒がせしました。
そうすると、mod_speedycgiは確かに速いけど、実際のアプリではファイルやDBへの
アクセスがあるから、speedyCGI(CGI版)との速度差はほとんど無くなると言う事の様
ですね。(ほとんどがオンメモリーで済む処理だと差が出るけど)
ちなみに、テストに使った Hello world をhtmlにして同じサーバに入れてベンチ取った
所、4.298 [ms]でした。
mod_speedycgiは、10.968 [ms] だったので、この2.5倍程度しか掛かっていない、という
事は、ぼちぼち限界。
アクセラレータとして、mod_perl,FastCGI,SpeedyCGIの比較で、>>52 の
「スピードはどれも意味のある差はない。」
は、正論だったんだなと再認識しました。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5313日前に更新/192 KB
担当:undef