トップページ⇒php
851コメント342KB

【激速】mod_perl SpeedyCGI FastCGI【激速】

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2006/06/05(月) 20:01:09ID:+YcYjDiD
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/

ー二三ヘ(　ﾟ∀ﾟ)ノ
0019nobodyさん2006/06/13(火) 20:39:24ID:???
> ２．メモリ消費
> 　　愕然とするほどの差

何か間違えてない？
0020nobodyさん2006/06/13(火) 21:03:44ID:???
>>18
>　Apachモジュールをperlで書けるからでしょ。
でしょうね。
アクセラレータとして使うメリットはみつけられない。

>>19
>　> ２．メモリ消費
>　> 　　愕然とするほどの差
>
>　何か間違えてない？
そのままお返しします。
mod_perlをはじめて使った時は感動したが、後で愕然とした。
しかも太る一方。
topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
そのまま使い続けたが、他のアプリがスワップしはじめガリガリいいだしたのでSpeedyCGIに変えた。
0021nobodyさん2006/06/13(火) 21:05:17ID:???
しかも太る一方。
topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。

↑間違い
topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。
しかも太る一方。
0022nobodyさん2006/06/13(火) 22:00:36ID:???
> mod_perlをはじめて使った時は感動したが、後で愕然とした。
> しかも太る一方。
> topコマンドを叩いたら、10MB超のアパッチプロセスが１０個以上並んでいた。

apache の設定がわからんからといって、mod_perl のせいにしてはいかんよね。
0023nobodyさん2006/06/13(火) 22:09:37ID:???
>>22
めちゃくちゃ言うなあ。
mod_perlをoffにしてapache再起動したら、通常のサイズに戻ったが。

逆にそちらではどれくらいのサイズなんだ？
0024nobodyさん2006/06/13(火) 22:13:19ID:???
>>23
> めちゃくちゃ言うなあ。

どこらへんが滅茶苦茶なのだろう。

> mod_perlをoffにしてapache再起動したら、通常のサイズに戻ったが。

そうでしょうね。

> 逆にそちらではどれくらいのサイズなんだ？

アプリケーションの規模によるよね。
0025232006/06/13(火) 22:15:54ID:???
mod_perlでApacheが太るからわざわざリバースプロキシ使ってるんではなかったのか？
mod_perlに限らずmod_php、mod_ruby等もメモリの食いっぷりがすごいが。
002622, 242006/06/13(火) 22:19:13ID:???
mod_perl 等を使う時は、フロントエンドとバックエンドに分けて使う。
フロントエンドで画像等をさばき、それ以外のものをバックエンドに送る。

バックエンド側で起動する perl のプロセスは、積んでいるメモリで決める。
そこらへん、mixi なり hatena bookmark なりの資料探して読むとわかるとおもう。
0027232006/06/13(火) 22:20:52ID:???
>>24
あほくさ。

>　> mod_perlをoffにしてapache再起動したら、通常のサイズに戻ったが。
>
>　そうでしょうね。

設定正しいって事やないか。
Apacheでmod_perlのメモリの制御はできん。

>　> 逆にそちらではどれくらいのサイズなんだ？
>
>　アプリケーションの規模によるよね。
使った事がないんだな。
そんな単純な食い方はしない。
0028nobodyさんNGNG
（・∀・）ﾆﾔﾆﾔ
0029nobodyさん2006/06/13(火) 22:23:13ID:???
> Apacheでmod_perlのメモリの制御はできん。

メモリの使用量でなく、プロセスの数を調整する。
で、定期的に再起動するようなオプションあるよね。
0030232006/06/13(火) 22:26:21ID:???
>>26
当然そういうことだが。
言葉がうわすべりしてないか？
mod_perlでリバースプロキシ使うのは、
１．mod_perlでApacheが太り、静的サービスの反応が鈍る。
２．解決策として静的サービスには別のApacheを使う。
こういうことなんだが。

何も別マシンにリバースプロキシかけなくても静的サービスのスピード向上はできるよ。
0031nobodyさん2006/06/13(火) 22:27:36ID:???
>>30
別マシンとはひとことも言っていませんね。
0032232006/06/13(火) 22:28:56ID:???
>>29
>　メモリの使用量でなく、プロセスの数を調整する。
>　で、定期的に再起動するようなオプションあるよね。

面白いこと言うな。
プロセスの数は調整できんよ。
ある回数起動したらプロセス死ぬ設定はできるが、プロセスの数は運まかせになるよ。
0033nobodyさん2006/06/13(火) 22:33:31ID:???
>>31
いいわけかっこ悪い。
0034nobodyさん2006/06/13(火) 22:34:30ID:???
http://d.hatena.ne.jp/babie/20060201/p3
0035nobodyさん2006/06/13(火) 22:35:32ID:???
>>33
どこらへんがいいわけなのだろう。
0036nobodyさん2006/06/13(火) 22:37:57ID:???
>>34
で君はそのページをまねて、実際にどれくらい節約できた？
0037nobodyさん2006/06/13(火) 22:41:06ID:???
>>35
（・∀・）ﾆﾔﾆﾔ
0038nobodyさんNGNG
(´；ω；`)
0039nobodyさん2006/06/13(火) 22:47:05ID:???
(´･ω･`)
0040nobodyさん2006/06/13(火) 22:49:19ID:???
>>34
http://d.hatena.ne.jp/babie/20060201/p3
何やこれ。
１．Apacheが太るので子プロセスの数を制限する。
２．静的コンテンツのスピード確保にリバースプロキシを使う。
３．Apache自体をできるだけ太らせない。
当たり前のことやんか。
何も新しいものあらへん。
0041402006/06/13(火) 22:50:40ID:???
というか、これではやはりSpeedyCGI以下。
0042nobodyさん2006/06/13(火) 22:52:30ID:???
>>41
どれでは？
0043nobodyさん2006/06/13(火) 22:55:14ID:???
mod_perl使いたきゃ、
専用の鯖がいるってことでそ。
0044nobodyさん2006/06/13(火) 22:57:03ID:???
>>34
http://d.hatena.ne.jp/babie/20060201/p3
>テスト機で試した。MaxClients 調整前はめっさ重くなる(SSHまで！)。
>MaxClients 調整後はなんとか耐えられる。

なんとか耐えられるんだってよ。
0045nobodyさん2006/06/13(火) 22:57:10ID:???
>>43
？
0046nobodyさんNGNG
mod_perl厨
必死すぎ
ﾜﾛﾀ
0047nobodyさん2006/06/13(火) 22:58:02ID:???
静的なもんも、動的なもんも、とりあえず一台でさばけて、
なおかつcgiも速くなるってのはどれ？
0048nobodyさん2006/06/13(火) 22:58:52ID:???
>>47
規模を書かないと話にならないのでは？
0049nobodyさん2006/06/13(火) 23:00:58ID:???
>>48
規模によってmod_perlがSpeedyCGIを上回ることがあんの？
0050nobodyさん2006/06/13(火) 23:03:30ID:???
>>48
規模が大きいほどmod_perl不利。
セッション数を捌けない。
規模が小さくてもやはり不利。
無用にApacheが圧迫されている。
0051nobodyさん2006/06/13(火) 23:06:35ID:???
FastCGIって、mod_perlやSpeedyCGIに比べるとどんなん？
0052nobodyさん2006/06/13(火) 23:21:03ID:???
優秀。
SpeedyCGI同様にプロセス数を自由に設定できる。
Apacheと別プロセスなので、それによってApacheのMaxClientsが制限を受けない。

１．SpeedyCGIは導入は容易。
Perl内部の問題で終わらせられる。
必要ならApacheモジュールもある。

２．FastCGIはアプリ起動用スクリプトと、Apacheの設定が必要。
ただし、ほぼ言語を問わず使用できるので、言語が混在しているサイトには有利。
最近lighttpdとの組み合わせが一部で人気？

スピードはどれも意味のある差はない。
0053nobodyさん2006/06/13(火) 23:23:19ID:???
http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-DynCont/html/dyncont.html
0054522006/06/13(火) 23:26:56ID:???
mod_perlは
１．メモリの管理が非常に下手。
２．導入時にmod_perl独自の制限がある。
（カレントDirがPerlとは違う。使えない文法がある）

以上の点でSpeedyCGI、FastCGIに比べ劣るが、逆に有利な点は不明。
0055nobodyさん2006/06/13(火) 23:28:50ID:???
FastCGI安定してるなぁ。
応用も利きそうなのでいい感じかも
0056nobodyさん2006/06/13(火) 23:30:20ID:???
>>53
古くね？
0057nobodyさん2006/06/13(火) 23:30:47ID:???
なんかものすごい自演だらけの予感。
0058522006/06/13(火) 23:31:48ID:???
>>53
ベンチはそれほど意味がないよ。
引用先も、対象ベンチ次第でで結果がころころ変わっている。
しかし、mod_perlはベンチでも負けている記事が目立つ。
0059nobodyさん2006/06/13(火) 23:33:48ID:???
>>57
同意。
0060nobodyさん2006/06/13(火) 23:37:01ID:???
mod_perl って 3 系統くらいあった気がするけど、だれか違いを説明きぼん。
0061nobodyさん2006/06/13(火) 23:38:41ID:???
このスレの住人ってなぜにmod_perlにしがみつくの？
mod_perlは一体どこがアドバンテージ？
0062nobodyさん2006/06/13(火) 23:39:34ID:???
なにをもって「mod_perlにしがみつく」ということにしたいのだろう。
0063nobodyさん2006/06/13(火) 23:40:50ID:???
>>62
（・∀・）
0064nobodyさん2006/06/13(火) 23:42:15ID:???
>>62
（・∀・）ﾆﾔﾆﾔ
0065nobodyさんNGNG
出来損ないには愛着が沸くもの
0066nobodyさん2006/06/13(火) 23:44:02ID:???
もうmod_perl専用スレじゃないのにね。
0067nobodyさん2006/06/14(水) 00:04:43ID:???
C/FastCGIとPerl/FastCGIってどのくらい速度が違うか実践した方います？
Cの方が早いだろうけどインタープリタ部分のコストを除いた純粋な言語の速度対決なら
C/CGI vs Perl/CGIほどの差は出ないと思うのですが実際のところどのぐらい違うでしょうか。
0068nobodyさん2006/06/14(水) 00:05:10ID:???
>　mod_perlは一体どこがアドバンテージ？

必死だが、答えられないmod_perl厨は逝ってよし。
0069nobodyさん2006/06/14(水) 00:07:07ID:???
うーん、こうやって貼り付けたくなるほど出来損ないには愛着がわくなｗ
http://pc8.2ch.net/test/read.cgi/php/1149089424/2
0070nobodyさん2006/06/14(水) 00:12:22ID:???
>>67
試してないので机上の空論ですまそ。

Cはコンパイル時に非常に長い時間をかけて最適化を行うので、一瞬でコンパイルする必要があるPerlコンパイラとはやはり根本的な差があると思う。
そうでなければ、Cが今だに強い理由はないと思う。
しかし、大きく差が詰まるのは間違いないよね。
0071nobodyさん2006/06/14(水) 00:14:07ID:???
>> そうでなければ、Cが今だに強い理由はないと思う。

Web アプリの分野で？ｗ
0072nobodyさん2006/06/14(水) 00:15:49ID:???
>>72
まさか。
速度が必要な分野で。
OS、DB、科学技術計算。
0073nobodyさん2006/06/14(水) 00:17:39ID:???
↑
>>71
0074nobodyさん2006/06/14(水) 00:46:51ID:???
>>67
Win上で同じくネイティブコードを吐く、VBとCの速度差にビビった経験があるな。
.NETでは言語間の速度差はほぼ無いようだが。
0075nobodyさん2006/06/14(水) 01:56:44ID:???
本格的に大規模なサイトだと、重い処理はCで書いて、それをPerlやPHPから使うって言うのが解決策になってるんじゃないかな。
ヤフーとかもそうでしょう。
0076nobodyさん2006/06/14(水) 02:11:38ID:???
まぁ各ファイルで共通の手続きはできるだけモジュールに括り出すんだな。
0077nobodyさんNGNG
大抵はI/Oがボトルネックだから関係ないべ
0078nobodyさん2006/06/14(水) 12:24:45ID:???
>>77
Cの処理速度にはまじでビビるよ。
I／Oかかえていても速い。
0079nobodyさん2006/06/14(水) 13:01:49ID:???
CPUが直接食える状態になってるからな。

ボトルネックになるディスクI/Oを減らすために少しでもI/Oの速いメモリに溜め込むけど
その結果メモリを馬鹿食いと。
0080nobodyさん2006/06/14(水) 13:40:58ID:???
>>79
mod_perlの馬鹿食いはそのせいだけじゃないよ。
mod_perlはApacheの全子プロセスに問答無用でPerlインタプリタを埋め込む。
コードのキャッシュも全子プロセスが持つ。
結果的に、同じコピーが大量に作られる。

SpeedyCGIを運用しているが、常駐インタープリタは２個で充分。
リクエストが多い時はまたされるだけ。
ちゃんと捌く。
mod_perl運用時に比べメモリ使用量は激減した。

mod_perlはアクセラレータとしては、仕様に大きな問題があると思う。
0081nobodyさん2006/06/14(水) 13:56:47ID:???
preforkはアレだが、workerならある程度再利用が有効に効かない？
0082nobodyさん2006/06/14(水) 14:45:30ID:???
>>81
その通りなんだけど、workerは1.3系列はダメじゃなかったかな？
効果もある程度だしね。
FastCGI、SpeedyCGIがインタープリタの数等、リソースを自由にコントロールできるのに対して仕様自体が？？？ではないの。
0083nobodyさん2006/06/14(水) 14:58:15ID:???
原理的には、プロセス間通信のないmod_perlは速度的に優位なはずだが、
どこのベンチをみても有意な差がない。
というより、むしろ負け気味。
たとえ原理通りになっても、現実には無意味な程度だと思う。
0084nobodyさん2006/06/14(水) 18:02:41ID:???
とりあえず、”アクセラレータ"としては、SpeedCGIか、FastCGIでってことでオケ？
0085nobodyさん2006/06/14(水) 19:12:48ID:???
無茶な使いかたしなければmod_perlでもいんじゃね？
0086nobodyさん2006/06/14(水) 20:48:26ID:???
http://d.hatena.ne.jp/babie/20060201/p3
>テスト機で試した。MaxClients 調整前はめっさ重くなる(SSHまで！)。
>MaxClients 調整後はなんとか耐えられる。
0087nobodyさん2006/06/14(水) 20:53:08ID:???
>MaxClients 調整後はなんとか耐えられる。
>MaxClients 調整後はなんとか耐えられる。
>MaxClients 調整後はなんとか耐えられる。
0088nobodyさん2006/06/14(水) 23:00:35ID:???
ベンチマークすら提示せずに否定に走られてもねぇ。

>>80
> mod_perlの馬鹿食いはそのせいだけじゃないよ。
> mod_perlはApacheの全子プロセスに問答無用でPerlインタプリタを埋め込む。
> コードのキャッシュも全子プロセスが持つ。
> 結果的に、同じコピーが大量に作られる。

これに関しては、何を言いたいのかさっぱりわかりませんね。
0089nobodyさん2006/06/14(水) 23:20:34ID:???
このスレ見てるとmod_perlうんこな流れだけど
mixiやはてながmod_perlで運用してるのは何か理由があるの？
0090nobodyさん2006/06/14(水) 23:37:09ID:nPkMVDT9
Apacheモジュールだからというだけで食いつきがいいような希ガス。
本物を見極められない哀れなmod_perler〜♪
0091nobodyさん2006/06/14(水) 23:56:11ID:???
>>90
その本物とやらは、どんなものなんでしょう？
0092nobodyさん2006/06/15(木) 00:14:17ID:???
まだ自分専用のスレと勘違いしたままのmod_perl厨カワイソス
0093nobodyさん2006/06/15(木) 00:17:47ID:???
>>89
>　このスレ見てるとmod_perlうんこな流れだけど
>　mixiやはてながmod_perlで運用してるのは何か理由があるの？

理由が知りたいから、
「mod_perlは一体どこがアドバンテージ？」
mod_perl厨に聞きつづけてるんだが。
未だに返事はなし。
0094nobodyさん2006/06/15(木) 00:22:57ID:???
「mod_perlは一体どこがアドバンテージ？」
これに返事もできない状態で
「mixiが．．．」
「はてなが．．．」
「ホリエモンの子飼いが．．．」

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

とてもユニークな意見やね。
どんなベンチとるんだろうか？
俺ならtopコマンド叩く程度しか思いつかんが。
0096nobodyさん2006/06/15(木) 00:48:36ID:???
>>94
同意。

しかもmixiが重いって話になると、今度は
「それはMySQLのせいらしい。」
とくる。

「mixiやはてながやってるから正しいんだろう。」
これ以上のものは見えてこない。
うんざり。
0097nobodyさん2006/06/15(木) 02:30:04ID:???
mixiがやろうと、はてながやろうと、間違ってると思えばその通りに発言できる。
それが、こういう場所の良さではないのか？
0098nobodyさん2006/06/15(木) 04:04:13ID:???
>>85
”アクセラレータ"としてのmod_perl自体が無茶かと...
0099nobodyさん2006/06/15(木) 04:23:38ID:???
実績があるからじゃないの。mixiやはてなクラスなら、フロントサーバとアプリケーションサーバを分けて運用するの、どのみち必須だろうし。
0100nobodyさん2006/06/15(木) 06:12:39ID:???
あまりにもレス食いつきの良さに
なんだかアンチmod_perlが必死に見えるよ
落ち着こう
0101nobodyさん2006/06/15(木) 06:18:43ID:???
ooとxxどっちが強いレベルだよ
どこにでもいる最強厨
0102nobodyさんNGNG
フロントとアプリサーバを分けるならいいけど、
フロントとしてつかうのであれば、
やっぱりmod_perlのメモリ量は気になるけどなぁ。
mod_perlの技術的なメリットがあるなら
きちんと知りたい昨今。
0103nobodyさん2006/06/15(木) 06:52:48ID:???
lighthttpd+FastCGIが最速で終了。
スレタイがアフォすぎだな。

----- ここからまったり雑談スレになります -----
0104nobodyさんNGNG
http://www.drk7.jp/MT/archives/000917.html
たしかに。
0105nobodyさん2006/06/15(木) 07:31:47ID:???
lighthttpdなんだよ
0106nobodyさん2006/06/15(木) 07:33:16ID:???
>>102
お前はゲームでもやってろ
0107nobodyさんNGNG
lighttpd+FastCGIもいいかと思ったんだけど設定がめんどくさそうなんだけど
SpeedyCGIは設定とか要らへんの？
0108nobodyさん2006/06/15(木) 08:31:41ID:???
dagに、lighttpd,lighttpd-fastcgi があるけど、このrpm使えぱ設定とか
かなり楽になるのかな？
0109nobodyさん2006/06/15(木) 09:06:57ID:???
>>107
SpeedyCGIは設定なし。
１．perlソースのグローバル変数を対応。
２．#!/usr/bin/perl等から#!/usr/bin/speedyや#!/usr/bin/perperl等に変更。
以上で終了。
Apacheは設定もできるが必要なし。
ただし、SpeedyCGIまたはPersistentPerl（中身はコマンド名以外同じ）が入っていること。
http://rintaro.dip.jp/program/nicky/index.html
0110nobodyさんNGNG
すげー
windows用のバイナリは無いんですかね探してるんですけど
01111092006/06/15(木) 10:06:20ID:???
>>110
すまそ。
Linux以外でperl使った事ないです。
0112nobodyさん2006/06/15(木) 10:17:00ID:???
>>107
> lighttpd+FastCGIもいいかと思ったんだけど設定がめんどくさそうなんだけど

ぐぐれば、そこらへんに落ちてると思う。
0113nobodyさん2006/06/15(木) 12:47:45ID:???
>>112
落ちてはいるだろうけど、
１．lighttpdの導入および設定
２．FastCGIの設定およびアプリ起動スクリプト作成法
これ新しくマスターするの結構、手間がかかるよ。
0114nobodyさん2006/06/15(木) 15:36:14ID:???
ところでworker+mod_perlのベンチってどっかにあるかね？
0115nobodyさん2006/06/15(木) 16:04:49ID:???
>>83
>原理的には、プロセス間通信のないmod_perlは速度的に優位なはずだが、
>どこのベンチをみても有意な差がない。

プロセス間通信がないことは、応答時間の短縮にはつながっても
スループットにはあんまり影響しないってことじゃない？
0116nobodyさん2006/06/15(木) 18:41:07ID:???
>>115
応答時間の短縮≠スループットの向上。
ちょっと理解に苦しむが、どういう意味？
0117nobodyさんNGNG
処理が早いだけで、
多くの処理がこなせるようになるわけじゃないってことすかね？
0118nobodyさん2006/06/15(木) 18:57:53ID:???
理解に苦しむといわれても、そのまんまなんだけど。
プロセス間通信がないmod_perlのほうが速いはずだけどベンチマークとったら差がない、ということだから、
mod_perlのほうが応答時間は短くなるかもしれないけど、それはスループットには影響を与えないんだろうね、ちうこと。
応答時間の短縮＝スループットの工場とは誰もいってないよ。
それを主張したら>>115とすごく矛盾してしまうんだけど。
■ このスレッドは過去ログ倉庫に格納されています