【激速】mod_perl SpeedyCGI FastCGI【激速】

1 ：06/06/05

mod_perl
http://perl.apache.org/
SpeedyCGI
http://perldoc.jp/docs/modules/CGI-SpeedyCGI-2.21/SpeedyCGI.pod
前スレ
mod_perlを使おう！
http://pc8.2ch.net/test/read.cgi/php/1005122528/
ー二三ヘ(　ﾟ∀ﾟ)ノ

2 ：06/06/05

僕の肛門も高速化されそうです

3 ：06/06/05

mod_perlを04Webserverで使用してみたいのですが、
mod_perl.dllの仕様、使い方について解説されている
ページとか有りませんか？

4 ：06/06/05

そんな馬鹿なことせずに apache 使えばよろし。

5 ：06/06/06

SpeedyCGI使えばPerl側だけの問題で済ませるやん。

6 ：06/06/07

前スレに書いちゃって、誘導されてきました。前スレ995です。
↓こういう質問なんですが・・・。
mod_perlを設定中な者ですが、一つどこのサイトにも明示的には書いてない気が
して、あきらかにしたいんですが、、、
ModPerl::Registry を使って .cgiを動かしても、その.cgiファイル内からuseしたり使
っているモジュールは、別途PerlRequireで指定のスクリプト内でuseしてロードしな
ければならないのでしょうか？
現在実験している環境だと、PerlRequire経由でuseでロードしないモジュールは、
perl-statusの "Loaded Modules"には出てきません。僕の勝手な想像では、
「ModPerl::Registryが呼び出した.cgiがuseしているモジュール」は、適宜ロード
されて、perl-statusにも表示されるんじゃないかと予想していたんですが、それは
ちがうんでしょうかね？
当方の設定ミスなのか、仕様なのかがいまいちはっきり分らないので、聞いてみます。。。

7 ：06/06/08

どのタイミングで、どのプロセスが、モジュールを読みこんでいるのか？
どのプロセスが読み込み済みのモジュールをチェックしようとしているのか？
ってのを意識しながら動作検証するといいといいんじゃない？

8 ：06/06/13

mod_perl時の場合END{}はプロセスが終了した時のみに実行されますが
mod_perl時にPerl/CGIのEND{}と同様の事をしたい場合どうするのが一番良いのでしょうか。

9 ：06/06/13

>>8
mod_perlにそういうhookが用意されていないと無理

10 ：06/06/13

たいていオブジェクト指向バリバリで書くからsub DESTROYでも用意しておけばいいんじゃね？

11 ：06/06/13

了解です、ありがとうございます。
取りあえず
*CORE::GLOBAL::exit = sub { hogehoge(); \&Apache::exit }　if$ENV{MOD_PERL};
のようにしてexitをオーバーライドしてexitの前に割り込ませる事にしました。
どんな処理でも必ずexitされるわけではないですけど。

12 ：06/06/13

mod_perlをapacheで走らせてるときに、
apacheのerror_logに任意のテキストを出力したりすることって
出来るんでしょうか？

13 ：06/06/13

stderrにprintしる!

14 ：06/06/13

mod_perlなら
http://search.cpan.org/~gozer/mod_perl-1.29/Log/Log.pm
これ。
mod_perl2なら
http://search.cpan.org/~pgollucci/mod_perl-2.0.2/docs/api/Apache2/Log.pod
これかな？

15 ：06/06/13

おぉ、どうもですー。

16 ：06/06/13

Log4perl とか使えば、あんなことやこんなことできるんでは？

17 ：06/06/13

前スレから疑問なんだけど、なぜにSpeedyCGIではなくmod_perlなの？
両方使ったが、
１．体感スピード
　　同じ
２．メモリ消費
　　愕然とするほどの差
３．導入の障害
　　圧倒的にSpeedyCGI有利
どちらもPerl専用アクセラレータだけどわざわざ選ぶメリットが見つけられん。

18 ：06/06/13

Apachモジュールをperlで書けるからでしょ。

19 ：06/06/13

> ２．メモリ消費
> 　　愕然とするほどの差
何か間違えてない？

20 ：06/06/13

>>18
>　Apachモジュールをperlで書けるからでしょ。
でしょうね。
アクセラレータとして使うメリットはみつけられない。
>>19
>　> ２．メモリ消費
>　> 　　愕然とするほどの差
>
>　何か間違えてない？
そのままお返しします。
mod_perlをはじめて使った時は感動したが、後で愕然とした。
しかも太る一方。
topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
そのまま使い続けたが、他のアプリがスワップしはじめガリガリいいだしたのでSpeedyCGIに変えた。

21 ：06/06/13

しかも太る一方。
topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
↑間違い
topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
しかも太る一方。

22 ：06/06/13

> mod_perlをはじめて使った時は感動したが、後で愕然とした。
> しかも太る一方。
> topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
apache の設定がわからんからといって、mod_perl のせいにしてはいかんよね。

23 ：06/06/13

>>22
めちゃくちゃ言うなあ。
mod_perlをoffにしてapache再起動したら、通常のサイズに戻ったが。
逆にそちらではどれくらいのサイズなんだ？

24 ：06/06/13

>>23
> めちゃくちゃ言うなあ。
どこらへんが滅茶苦茶なのだろう。
> mod_perlをoffにしてapache再起動したら、通常のサイズに戻ったが。
そうでしょうね。
> 逆にそちらではどれくらいのサイズなんだ？
アプリケーションの規模によるよね。

25 ：06/06/13

mod_perlでApacheが太るからわざわざリバースプロキシ使ってるんではなかったのか？
mod_perlに限らずmod_php、mod_ruby等もメモリの食いっぷりがすごいが。

26 ：06/06/13

mod_perl 等を使う時は、フロントエンドとバックエンドに分けて使う。
フロントエンドで画像等をさばき、それ以外のものをバックエンドに送る。
バックエンド側で起動する perl のプロセスは、積んでいるメモリで決める。
そこらへん、mixi なり hatena bookmark なりの資料探して読むとわかるとおもう。

27 ：06/06/13

>>24
あほくさ。
>　> mod_perlをoffにしてapache再起動したら、通常のサイズに戻ったが。
>
>　そうでしょうね。
設定正しいって事やないか。
Apacheでmod_perlのメモリの制御はできん。
>　> 逆にそちらではどれくらいのサイズなんだ？
>
>　アプリケーションの規模によるよね。
使った事がないんだな。
そんな単純な食い方はしない。

28 ：06/06/13

（・∀・）ﾆﾔﾆﾔ

29 ：06/06/13

> Apacheでmod_perlのメモリの制御はできん。
メモリの使用量でなく、プロセスの数を調整する。
で、定期的に再起動するようなオプションあるよね。

30 ：06/06/13

>>26
当然そういうことだが。
言葉がうわすべりしてないか？
mod_perlでリバースプロキシ使うのは、
１．mod_perlでApacheが太り、静的サービスの反応が鈍る。
２．解決策として静的サービスには別のApacheを使う。
こういうことなんだが。
何も別マシンにリバースプロキシかけなくても静的サービスのスピード向上はできるよ。

31 ：06/06/13

>>30
別マシンとはひとことも言っていませんね。

32 ：06/06/13

>>29
>　メモリの使用量でなく、プロセスの数を調整する。
>　で、定期的に再起動するようなオプションあるよね。
面白いこと言うな。
プロセスの数は調整できんよ。
ある回数起動したらプロセス死ぬ設定はできるが、プロセスの数は運まかせになるよ。

33 ：06/06/13

>>31
いいわけかっこ悪い。

34 ：06/06/13

http://d.hatena.ne.jp/babie/20060201/p3

35 ：06/06/13

>>33
どこらへんがいいわけなのだろう。

36 ：06/06/13

>>34
で君はそのページをまねて、実際にどれくらい節約できた？

37 ：06/06/13

>>35
（・∀・）ﾆﾔﾆﾔ

38 ：06/06/13

(´；ω；`)

39 ：06/06/13

(´･ω･`)

40 ：06/06/13

>>34
http://d.hatena.ne.jp/babie/20060201/p3
何やこれ。
１．Apacheが太るので子プロセスの数を制限する。
２．静的コンテンツのスピード確保にリバースプロキシを使う。
３．Apache自体をできるだけ太らせない。
当たり前のことやんか。
何も新しいものあらへん。

41 ：06/06/13

というか、これではやはりSpeedyCGI以下。

42 ：06/06/13

>>41
どれでは？

43 ：06/06/13

mod_perl使いたきゃ、
専用の鯖がいるってことでそ。

44 ：06/06/13

>>34
http://d.hatena.ne.jp/babie/20060201/p3
>テスト機で試した。MaxClients 調整前はめっさ重くなる(SSHまで！)。
>MaxClients 調整後はなんとか耐えられる。
なんとか耐えられるんだってよ。

45 ：06/06/13

>>43
？

46 ：06/06/13

mod_perl厨
必死すぎ
ﾜﾛﾀ

47 ：06/06/13

静的なもんも、動的なもんも、とりあえず一台でさばけて、
なおかつcgiも速くなるってのはどれ？

48 ：06/06/13

>>47
規模を書かないと話にならないのでは？

49 ：06/06/13

>>48
規模によってmod_perlがSpeedyCGIを上回ることがあんの？

50 ：06/06/13

>>48
規模が大きいほどmod_perl不利。
セッション数を捌けない。
規模が小さくてもやはり不利。
無用にApacheが圧迫されている。

51 ：06/06/13

FastCGIって、mod_perlやSpeedyCGIに比べるとどんなん？

52 ：06/06/13

優秀。
SpeedyCGI同様にプロセス数を自由に設定できる。
Apacheと別プロセスなので、それによってApacheのMaxClientsが制限を受けない。
１．SpeedyCGIは導入は容易。
Perl内部の問題で終わらせられる。
必要ならApacheモジュールもある。
２．FastCGIはアプリ起動用スクリプトと、Apacheの設定が必要。
ただし、ほぼ言語を問わず使用できるので、言語が混在しているサイトには有利。
最近lighttpdとの組み合わせが一部で人気？
スピードはどれも意味のある差はない。

53 ：06/06/13

http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-DynCont/html/dyncont.html

54 ：06/06/13

mod_perlは
１．メモリの管理が非常に下手。
２．導入時にmod_perl独自の制限がある。
（カレントDirがPerlとは違う。使えない文法がある）
以上の点でSpeedyCGI、FastCGIに比べ劣るが、逆に有利な点は不明。

55 ：06/06/13

FastCGI安定してるなぁ。
応用も利きそうなのでいい感じかも

56 ：06/06/13

>>53
古くね？

57 ：06/06/13

なんかものすごい自演だらけの予感。

58 ：06/06/13

>>53
ベンチはそれほど意味がないよ。
引用先も、対象ベンチ次第でで結果がころころ変わっている。
しかし、mod_perlはベンチでも負けている記事が目立つ。

59 ：06/06/13

>>57
同意。

60 ：06/06/13

mod_perl って 3 系統くらいあった気がするけど、だれか違いを説明きぼん。

61 ：06/06/13

このスレの住人ってなぜにmod_perlにしがみつくの？
mod_perlは一体どこがアドバンテージ？

62 ：06/06/13

なにをもって「mod_perlにしがみつく」ということにしたいのだろう。

63 ：06/06/13

>>62
（・∀・）

64 ：06/06/13

>>62
（・∀・）ﾆﾔﾆﾔ

65 ：06/06/13

出来損ないには愛着が沸くもの

66 ：06/06/13

もうmod_perl専用スレじゃないのにね。

67 ：06/06/14

C/FastCGIとPerl/FastCGIってどのくらい速度が違うか実践した方います？
Cの方が早いだろうけどインタープリタ部分のコストを除いた純粋な言語の速度対決なら
C/CGI vs Perl/CGIほどの差は出ないと思うのですが実際のところどのぐらい違うでしょうか。

68 ：06/06/14

>　mod_perlは一体どこがアドバンテージ？
必死だが、答えられないmod_perl厨はってよし。

69 ：06/06/14

うーん、こうやって貼り付けたくなるほど出来損ないには愛着がわくなｗ
http://pc8.2ch.net/test/read.cgi/php/1149089424/2

70 ：06/06/14

>>67
試してないので机上の空論ですまそ。
Cはコンパイル時に非常に長い時間をかけて最適化を行うので、一瞬でコンパイルする必要があるPerlコンパイラとはやはり根本的な差があると思う。
そうでなければ、Cが今だに強い理由はないと思う。
しかし、大きく差が詰まるのは間違いないよね。

71 ：06/06/14

>> そうでなければ、Cが今だに強い理由はないと思う。
Web アプリの分野で？ｗ

72 ：06/06/14

>>72
まさか。
速度が必要な分野で。
OS、DB、科学技術計算。

73 ：06/06/14

↑
>>71

74 ：06/06/14

>>67
Win上で同じくネイティブコードを吐く、VBとCの速度差にビビった経験があるな。
.NETでは言語間の速度差はほぼ無いようだが。

75 ：06/06/14

本格的に大規模なサイトだと、重い処理はCで書いて、それをPerlやPHPから使うって言うのが解決策になってるんじゃないかな。
ヤフーとかもそうでしょう。

76 ：06/06/14

まぁ各ファイルで共通の手続きはできるだけモジュールに括り出すんだな。

77 ：06/06/14

大抵はI/Oがボトルネックだから関係ないべ

78 ：06/06/14

>>77
Cの処理速度にはまじでビビるよ。
I／Oかかえていても速い。

79 ：06/06/14

CPUが直接食える状態になってるからな。
ボトルネックになるディスクI/Oを減らすために少しでもI/Oの速いメモリに溜め込むけど
その結果メモリを馬鹿食いと。

80 ：06/06/14

>>79
mod_perlの馬鹿食いはそのせいだけじゃないよ。
mod_perlはApacheの全子プロセスに問答無用でPerlインタプリタを埋め込む。
コードのキャッシュも全子プロセスが持つ。
結果的に、同じコピーが大量に作られる。
SpeedyCGIを運用しているが、常駐インタープリタは２個で充分。
リクエストが多い時はまたされるだけ。
ちゃんと捌く。
mod_perl運用時に比べメモリ使用量は激減した。
mod_perlはアクセラレータとしては、仕様に大きな問題があると思う。

81 ：06/06/14

preforkはアレだが、workerならある程度再利用が有効に効かない？

82 ：06/06/14

>>81
その通りなんだけど、workerは1.3系列はダメじゃなかったかな？
効果もある程度だしね。
FastCGI、SpeedyCGIがインタープリタの数等、リソースを自由にコントロールできるのに対して仕様自体が？？？ではないの。

83 ：06/06/14

原理的には、プロセス間通信のないmod_perlは速度的に優位なはずだが、
どこのベンチをみても有意な差がない。
というより、むしろ負け気味。
たとえ原理通りになっても、現実には無意味な程度だと思う。

84 ：06/06/14

とりあえず、”アクセラレータ"としては、SpeedCGIか、FastCGIでってことでオケ？

85 ：06/06/14

無茶な使いかたしなければmod_perlでもいんじゃね？

86 ：06/06/14

http://d.hatena.ne.jp/babie/20060201/p3
>テスト機で試した。MaxClients 調整前はめっさ重くなる(SSHまで！)。
>MaxClients 調整後はなんとか耐えられる。

87 ：06/06/14

>MaxClients 調整後はなんとか耐えられる。
>MaxClients 調整後はなんとか耐えられる。
>MaxClients 調整後はなんとか耐えられる。

88 ：06/06/14

ベンチマークすら提示せずに否定に走られてもねぇ。
>>80
> mod_perlの馬鹿食いはそのせいだけじゃないよ。
> mod_perlはApacheの全子プロセスに問答無用でPerlインタプリタを埋め込む。
> コードのキャッシュも全子プロセスが持つ。
> 結果的に、同じコピーが大量に作られる。
これに関しては、何を言いたいのかさっぱりわかりませんね。

89 ：06/06/14

このスレ見てるとmod_perlな流れだけど
mixiやはてながmod_perlで運用してるのは何か理由があるの？

90 ：06/06/14

Apacheモジュールだからというだけで食いつきがいいような希ガス。
本物を見極められない哀れなmod_perler〜♪

91 ：06/06/14

>>90
その本物とやらは、どんなものなんでしょう？

92 ：06/06/15

まだ自分専用のスレと勘違いしたままのmod_perl厨カワイソス

93 ：06/06/15

>>89
>　このスレ見てるとmod_perlな流れだけど
>　mixiやはてながmod_perlで運用してるのは何か理由があるの？
理由が知りたいから、
「mod_perlは一体どこがアドバンテージ？」
mod_perl厨に聞きつづけてるんだが。
未だに返事はなし。

94 ：06/06/15

「mod_perlは一体どこがアドバンテージ？」
これに返事もできない状態で
「mixiが．．．」
「はてなが．．．」
「ホリエモンの子飼いが．．．」
こんな話ばっかりやられてもねえ。
わからいなら、黙っとけ。

95 ：06/06/15

>>88
>　ベンチマークすら提示せずに否定に走られてもねぇ。
>　
>　>>80
>　> mod_perlの馬鹿食いはそのせいだけじゃないよ。
>　> mod_perlはApacheの全子プロセスに問答無用でPerlインタプリタを埋め込む。
>　> コードのキャッシュも全子プロセスが持つ。
>　> 結果的に、同じコピーが大量に作られる。
>　
>　これに関しては、何を言いたいのかさっぱりわかりませんね。
とてもユニークな意見やね。
どんなベンチとるんだろうか？
俺ならtopコマンド叩く程度しか思いつかんが。

96 ：06/06/15

>>94
同意。
しかもmixiが重いって話になると、今度は
「それはMySQLのせいらしい。」
とくる。
「mixiやはてながやってるから正しいんだろう。」
これ以上のものは見えてこない。
うんざり。

97 ：06/06/15

mixiがやろうと、はてながやろうと、間違ってると思えばその通りに発言できる。
それが、こういう場所の良さではないのか？

98 ：06/06/15

>>85
”アクセラレータ"としてのmod_perl自体が無茶かと...

99 ：06/06/15

実績があるからじゃないの。mixiやはてなクラスなら、フロントサーバとアプリケーションサーバを分けて運用するの、どのみち必須だろうし。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

Python CGI (347)
僕に系のシステムを売ってください (918)
【PHP】PEAR Part3 (661)
CGIで運営される２ちゃんねる (221)
PHP+MySQL掲示板作ろうぜ (795)
Ruby VS PHP 仁義なき戦い (166)
--log9.info------------------
【ぶたお】BS@もてもてラジ袋16【川柳】 (284)
東京ポッド許可局　part5 (204)
【老舗】くりらじ26【パクリの秀、受け売りのBJ】 (514)
【和歌山の】隔離空間ラジオその2【恥さらし達】 (378)
スパロボOGネットラジオ うますぎWAVE Part14 (700)
【宗教から】桜川マキシムの三【下ネタまで】 (570)
【大喜利】まこっさんファンクラブ8 (503)
【ニコ生】ぷよぷよ総合スレ（実況あり） 8連鎖目 (528)
ageラジオ総合スレ（現行番組） 第67回 (342)
しゃべる実況スレ★7 (846)
【もっこパレ】【もてラジ以外の劣化サイキック】 2 (137)
ネットラジオ板 忍法帖テストスレ (198)
【GOgoGOGO!!】洋楽垂れ流し総合【VIviVIVIP!!】 (162)
のら犬兄弟のギョーカイ時事放談 第158回 (926)
ノリスケラジオ　(ジョジョラジオ) (233)
第三回ぷよぷよ国際親善試合 日本×韓国 （実況可） (319)
--log55.com------------------
【悲報】大阪維新のここ10年の悪政がこちら [479613355]
【悲報】さつまいも界の最強品種「紅はるか」 韓国に盗まれる [396379575]
石橋貴明「日本には奴隷文化がない。人の権利を剥奪し、売るという発想すらなかった」 [479613355]
コロナからしばらく経つのに天皇から声明なし。すまん、このゴミいるか？ [972137345]
レベッカ　何を思い浮かべる？？ [327876567]
【悲報】亀田総合病院の大澤良介先生、新型コロナについて本当のことをうっかり喋ってしまう [321190791]
【真理省】厚労省、死亡女性を診察した日付を改竄★2 [963243619]
女漫画家「売れ残り男が、こんな感じで童貞で優しくてイケメンなら最高なのに！！」 [873049711]