【激速】mod_perl SpeedyCGI FastCGI【激速】
■ このスレッドは過去ログ倉庫に格納されています
ooとxxどっちが強いレベルだよ
どこにでもいる最強厨 フロントとアプリサーバを分けるならいいけど、
フロントとしてつかうのであれば、
やっぱりmod_perlのメモリ量は気になるけどなぁ。
mod_perlの技術的なメリットがあるなら
きちんと知りたい昨今。
lighthttpd+FastCGIが最速で終了。
スレタイがアフォすぎだな。
----- ここからまったり雑談スレになります ----- lighttpd+FastCGIもいいかと思ったんだけど設定がめんどくさそうなんだけど
SpeedyCGIは設定とか要らへんの? dagに、lighttpd,lighttpd-fastcgi があるけど、このrpm使えぱ設定とか
かなり楽になるのかな? >>107
SpeedyCGIは設定なし。
1.perlソースのグローバル変数を対応。
2.#!/usr/bin/perl等から#!/usr/bin/speedyや#!/usr/bin/perperl等に変更。
以上で終了。
Apacheは設定もできるが必要なし。
ただし、SpeedyCGIまたはPersistentPerl(中身はコマンド名以外同じ)が入っていること。
http://rintaro.dip.jp/program/nicky/index.html すげー
windows用のバイナリは無いんですかね探してるんですけど >>110
すまそ。
Linux以外でperl使った事ないです。 >>107
> lighttpd+FastCGIもいいかと思ったんだけど設定がめんどくさそうなんだけど
ぐぐれば、そこらへんに落ちてると思う。 >>112
落ちてはいるだろうけど、
1.lighttpdの導入および設定
2.FastCGIの設定およびアプリ起動スクリプト作成法
これ新しくマスターするの結構、手間がかかるよ。 ところでworker+mod_perlのベンチってどっかにあるかね? >>83
>原理的には、プロセス間通信のないmod_perlは速度的に優位なはずだが、
>どこのベンチをみても有意な差がない。
プロセス間通信がないことは、応答時間の短縮にはつながっても
スループットにはあんまり影響しないってことじゃない? >>115
応答時間の短縮≠スループットの向上。
ちょっと理解に苦しむが、どういう意味? 処理が早いだけで、
多くの処理がこなせるようになるわけじゃないってことすかね?
理解に苦しむといわれても、そのまんまなんだけど。
プロセス間通信がないmod_perlのほうが速いはずだけどベンチマークとったら差がない、ということだから、
mod_perlのほうが応答時間は短くなるかもしれないけど、それはスループットには影響を与えないんだろうね、ちうこと。
応答時間の短縮=スループットの工場とは誰もいってないよ。
それを主張したら>>115とすごく矛盾してしまうんだけど。 そういう意味ならその通りだね。
話が脱線してるけど。 む?どこらへんが脱線してる?ふつうにmod_perlの話だと思うし、>>83の話からなんら飛躍してないと思うが。 >>118
言ってることはよくわかる。
しかし、ベンチの速度の話をしているときに、いきなりスループットは脱線だよ。
スループットが大きく影響するベンチもあれば、そうでないものもある。
ベンチ次第。 >>121
飛躍しているよ。
言っていることは、一般論としては正しいが、ベンチには反映されにくい。 >>122
どんなベンチマークを想像してんだろ。
おれは ab -c 10 -n 1000 みたいなのを想像してたんだけど。
サーバーサイドの話なんだから、ふつうにスループット重視だと思うんだが、
サーバーサイドのベンチで、スループットじゃないベンチおしえてくれ。
つーか、ベンチマークの話のときにスループットだすのがなんで脱線なんだ。理解に苦しむ。 こういう事はあまり言いたくないが、スループットの意味を解って使っているのか?
スループットとは単位時間に処理できる量のことだ。
> mod_perlのほうが応答時間は短くなるかもしれないけど、それはスループットには影響を与えないんだろうね、ちうこと。
この話は、mod_perlはメモリを食うのでセッション数を捌けない。
だから、応答時間は短くても単位時間当たりの処理数はあがらない。
こういう意味なんだろうが、それは単純にベンチには出ない。
まずmod_perlへのリクエスト量が多く、mod_perlの処理に支障がある状態のベンチかどうか。
そうでなければ、何の関係もない。
くだらない話だ。 >>125
どういうベンチの取り方だったらいいわけ? >>126
どういうベンチがいいとかいう問題じゃない。
ベンチは取った条件を考慮しないと、意味がない。 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されたのは、比較的最近だったので、ちょっとびっくり。 >>125
おいおい、今までの話で、「スループット」を誤用したところがあるか?なんでこんな心配されなきゃならん。
まず、
>ベンチの速度の話をしているときに、いきなりスループットは脱線だよ
を説明してくれ。
>こういう意味なんだろうが、それは単純にベンチには出ない。
>まずmod_perlへのリクエスト量が多く、mod_perlの処理に支障がある状態のベンチかどうか。
>そうでなければ、何の関係もない。
あれー、今はmod_perlのベンチマークの話だよね?mod_perlに負荷がかからないようなベンチを勝手に想像されてもなー。
>どういうベンチがいいとかいう問題じゃない。
>ベンチは取った条件を考慮しないと、意味がない。
じゃあどういうベンチマークテストで、どういう条件を考慮すればいいわけ?
おまえの話きいてると、逃げてるだけじゃん。 喧嘩するときはbeか鳥付けないと誰の発言か確認できないよね >>130
>>132
mod_perlはそのベンチの条件でセッション数が飽和しているか?
これをふまえて発言しろ。 >>130
> あれー、今はmod_perlのベンチマークの話だよね?mod_perlに負荷がかからないようなベンチを勝手に想像されてもなー。
「mod_perlに負荷がかからないような」ではなくて、
mod_perlにどれくらいの負荷がかかっていて、mod_perlがセッションさばけるかが問題ってことじゃねえ?
「mod_perlに負荷がかかって」いても>129のような軽い負荷だと関係ないっていうことかな。 >>136
> してない。
> それで?
それだと>116氏や>134氏の言うとおりになるんじゃない?
> 「mod_perlに負荷がかかって」いても>129のような軽い負荷だと関係ないっていうことかな。 > beか鳥をつけた方がよくね?
beも鳥もつけずにデマだけ並べるといいということ? >>139
>116や>134がデマってことは、
mod_perlのスコアがのびない理由はセッション数以外にも理由があるって理解でええの? >>140
> >116や>134がデマってことは、
>116や>134は、デマなんですか?
はつみみです。 漏れは頭悪いんで、>139が誰に対してデマっていってるのかわからんのやけど。 >>143
> 漏れは頭悪いんで、>139が誰に対してデマっていってるのかわからんのやけど。
そもそも、誰かの発言がデマであるというようなことは >>139 では述べられて
ないのでは? >>144
> それ以前に、>139=>142ってことでいいん?
どのように解釈しようと、各人の自由だと思いますよ。 Perl厨わかなくなったと思えば次はmod_perl厨。
収まったと思えば今度は匿名理屈厨。
すごいな。
このスレは。 (・∀・)ニヤニヤ 厨
必死だな 厨
>>149 みたいなの
も定期的に湧くな。
すごいな。
このスレは。
>>154
まあ、一番と順位づけをするためには、ベンチマーク等と同様に
客観的な基準が必要だよね。
- 何をもって「変」とするかの基準
- 上記「変」の順位付けの方法
>>155
>> ベンチマーク等と同様に客観的な基準が必要だよね。
このへんで頭の悪さがばれる。 >>158
まあ、ベンチが客観的と信じるのは個人の自由だし。
ええんでない? 宗教に、ほとんどとか程度があるのか。
このスレすごいなー。w mod_perl と SpeedyCGI どっちがいいの? >>170
mod_perl以外クソに決まってるだろ! >>170
mod_perl以外を選ぶメリットは何もない。 >>171 さん >>173 さん、ありがとうございます!
>>175
わかってるようだな。
世界で一番優れた言語mod_perl! >>176
mod_perl って言語だったんですね!
明日早速会社のサーバに mod_perl 言語を入れて実稼働はじめます! >>175
いや、言語ではなく神だ。
まだまだだな。 >>177
神を汚れたサーバに入れるなどおそれおおい。
神棚に飾っておけ。 >>178-179
神などという抽象的な存在の話なら、板違いじゃないのかな。 このスレは脱線かバトル以外話題がないからな。
そんときだけ異様にのびる。 > そんときだけ異様にのびる。
だって全部おれの自演だし SpeedyCGIってlighttpdでも使えるん?
今実行できる環境にないので > SpeedyCGIってlighttpdでも使えるん?
使えないということにでもしたい? > SpeedyCGIってlighttpdでも使えるん?
使えるよ。
Perlで完結するので、webサーバーは問わない。 >>194
ありがとう
バックエンドとか云うのは最初起動させとかなくていいの?
shebang行をspeedyに変えるだけでいいの? > Perlで完結するので、webサーバーは問わない。
デマですね。
/usr/bin/speedy は perl なのかと。 ただし、ActivePerlの場合は俺は知らん。
PC-UnixでPerlCGIが使えれば問題ない。
SpeedyCGIが入れられないとかいうなら別だが。 > Perlで完結するので、webサーバーは問わない。
と
> ただし、ActivePerlの場合は俺は知らん。
> PC-UnixでPerlCGIが使えれば問題ない。
> SpeedyCGIが入れられないとかいうなら別だが。
とでは、異なる内容になっていますね。 >>195
> バックエンドとか云うのは最初起動させとかなくていいの?
> shebang行をspeedyに変えるだけでいいの?
変えるだけでOK。
最初に実行した時に勝手にインタプリタが常駐しネイティブコードもキャッシュされるよ。
ただし、デフォルト設定では1時間Callがなければ、すべて解放されてしまうので自分の環境に合わせてコマンドラインスイッチを。
http://perldoc.jp/docs/modules/CGI-SpeedyCGI-2.21/SpeedyCGI.pod
>>196
> /usr/bin/speedy は perl なのかと。
CPANでインストールできるし、Perlドキュメントにも載ってますが...?
Perlの公式リリースと思っても間違いではないはず。
> CPANでインストールできるし、Perlドキュメントにも載ってますが...?
> Perlの公式リリースと思っても間違いではないはず。
CPAN に登録されていることと、Perl の公式リリースは何ら関係がありませんね。
そもそも「Perlの公式リリース」とは、具体的に何ですか? ■ このスレッドは過去ログ倉庫に格納されています