【激速】mod_perl SpeedyCGI FastCGI【激速】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2006/06/05(月) 20:01:09ID:+YcYjDiDhttp://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/
ー二三ヘ( ﾟ∀ﾟ)ノ
0685nobodyさん
2007/10/15(月) 15:54:12ID:???mod_perl で効果的に ithread 使うのが一番速い。
FastCGI だとスレッドの恩恵が少ない。
レンタルサーバだと一定時間を越えて動作するプロセス
情け容赦なく kill されるので
SpeedyCGI は利用できないと思った方が無難。
(SpeedyCGI に限らないが。)
0686nobodyさん
2007/10/15(月) 16:30:46ID:???今度試してみよう。
この板見て初めての収穫。
0687nobodyさん
2007/10/15(月) 16:32:14ID:???0688nobodyさん
2007/10/15(月) 16:51:46ID:???0689nobodyさん
2007/10/15(月) 18:07:12ID:???一方で lighttpd + fastcgi で十分じゃないかと言う話も。
0690nobodyさん
2007/10/15(月) 22:42:23ID:???>SpeedyCGI をユーザホームディレクトリ配下にインスコする。
わからん｡｡｡｡｡｡｡
普通にmakeしてもダメだろ？
0691nobodyさん
2007/10/16(火) 00:58:26ID:???Perl で ithread を使うための宣言が use threads だろ。
同じ物だよ。
>>690
「CPAN ホームディレクトリ」でググれ。
cpan コマンド使わずに手動でインスコするなら perl Makefile.PL PREFIX=$HOME とか
0692nobodyさん
2007/10/16(火) 10:52:05ID:???それだったら期待できないな。
過去の経験からいえばperlのthreadsはメモリーの扱い下手過ぎ（過消費）。
スワップまでの寿命がかなり短くなる。
0693nobodyさん
2007/10/16(火) 12:36:40ID:???企業としては開発効率以外にも見るべき所があるでしょ
0694nobodyさん
2007/10/16(火) 12:47:07ID:???5.005 の thread (use Thread;) と 5.6 以降の ithreads (use threads;) は違う。
後者の場合も注意して作らないとメモリをジャブジャブ使うのは変わらないが。
>>683
場合によりけりだろう。
一般的には規模が大きくなればかえって効率下がることになってる。
個人的には規模が小さくても型付けの弱い言語は開発効率が低いと感じる。
0695nobodyさん
2007/10/16(火) 16:20:31ID:???でも、多分
Interpreter threads are different from "5005threads"
(the thread model of Perl 5.005)
by creating a new perl interpreter per thread and not sharing any data or state between threads by default.
とあるとおり、スレッド毎にinterpreter分のメモリーをガンって増やすから、凄いことになっちゃったのかな。
mod_perlだともしかしてこのinterpreter分が節約できるのか？
自分はコマンド用途で試してたから増え方にビックリしたんだけど。
0696nobodyさん
2007/10/16(火) 16:50:51ID:???mod_perl (2.x) は ithread を内部的に使ってる、だった。
で、プロセス毎に上限の設定されたスレッドプールで使いまわしてる。
0697nobodyさん
2007/10/17(水) 16:52:12ID:???普通ってかあたりまえな気はする。
別サーバといっても同じマシンに別のApache立ち上げるだけでいいわけだし
mod_phpにしてもメモリ食いだし、静的ファイル用に別サーバ用意するのは当たり前だとおもってたけどな・・
それで重いといわれても〜
0698nobodyさん
2007/10/17(水) 16:54:27ID:???大規模なサイトでも機能ごとにちゃんと分けてあげたり普通につくれば普通に便利。
てか体が慣れてるので俺の中ではウェブ系はPerl以外ありえない
0699nobodyさん
2007/10/17(水) 16:56:24ID:???と独り言
0700nobodyさん
2007/10/17(水) 17:16:43ID:???静的ファイルで速度出したいなら lighttpd も良い選択だと思われ。
0701nobodyさん
2007/10/17(水) 19:51:25ID:???0702nobodyさん
2007/10/22(月) 16:25:52ID:YWIr8Jbqまるごと組んじゃうとか、どうなの？
0703nobodyさん
2007/10/23(火) 13:31:51ID:???0704nobodyさん
2007/10/29(月) 01:19:53ID:???うち、Cent4で、自前makeしたAp2.2.6を/usr/local/apache2/にインスコして、
そのapxsを読み込ませるようにしてmakeしてみたんだけど、mod_speedycgi2.cでエラー100個くらい出て止まってしまう。
内容はなんかsyntaxErrorだとか、previous definition(定義済みの再定義？)がでまくるんだけど・・・。
ちなみにrpmからの2.0.59では一応makeは通る(でもtestでmod_系は全スキップしてしまう)。
どなたか2.2系で動かしてる人いませんか？
0705nobodyさん
2007/10/29(月) 08:39:55ID:???http://rt.cpan.org/Public/Bug/Display.html?id=23920
0707nobodyさん
2007/10/30(火) 04:25:29ID:OsAJPMJ7うち、Cent4で、自前makeしたAp2.2.6を/usr/local/apache2/にインスコして、
そのapxsを読み込ませるようにしてmakeしてみたんだけど、mod_speedycgi2.cでエラー100個くらい出て止まってしまう。
内容はなんかsyntaxErrorだとか、previous definition(定義済みの再定義？)がでまくるんだけど・・・。
ちなみにrpmからの2.0.59では一応makeは通る(でもtestでmod_系は全スキップしてしまう)。
どなたか2.2系で動かしてる人いませんか？
0708nobodyさん
2007/11/14(水) 00:27:32ID:MPH8wi6Gうち、Cent4で、自前makeしたAp2.2.6を/usr/local/apache2/にインスコして、
そのapxsを読み込ませるようにしてmakeしてみたんだけど、mod_speedycgi2.cでエラー100個くらい出て止まってしまう。
内容はなんかsyntaxErrorだとか、previous definition(定義済みの再定義？)がでまくるんだけど・・・。
ちなみにrpmからの2.0.59では一応makeは通る(でもtestでmod_系は全スキップしてしまう)。
どなたか2.2系で動かしてる人いませんか？
0709nobodyさん
2007/11/14(水) 06:43:19ID:vnJkUfbwうち、Cent4で、自前makeしたAp2.2.6を/usr/local/apache2/にインスコして、
そのapxsを読み込ませるようにしてmakeしてみたんだけど、mod_speedycgi2.cでエラー100個くらい出て止まってしまう。
内容はなんかsyntaxErrorだとか、previous definition(定義済みの再定義？)がでまくるんだけど・・・。
ちなみにrpmからの2.0.59では一応makeは通る(でもtestでmod_系は全スキップしてしまう)。
どなたか2.2系で動かしてる人いませんか？
0710nobodyさん
2007/11/17(土) 13:53:14ID:???うち、Cent4で、自前makeしたAp2.2.6を/usr/local/apache2/にインスコして、
そのapxsを読み込ませるようにしてmakeしてみたんだけど、mod_speedycgi2.cでエラー100個くらい出て止まってしまう。
内容はなんかsyntaxErrorだとか、previous definition(定義済みの再定義？)がでまくるんだけど・・・。
ちなみにrpmからの2.0.59では一応makeは通る(でもtestでmod_系は全スキップしてしまう)。
どなたか2.2系で動かしてる人いませんか？
0711nobodyさん
2007/11/17(土) 18:28:52ID:???0712nobodyさん
2007/11/24(土) 02:37:09ID:???make test した時の、
t/apreq/cgi テストは失敗するもん？
CPANから取って来た2.08と、FedoraのRepoから引っ張ってきた2.09-rcのsrc.rpm
からやってみたんだけど、両方これがエラーになる。
ググってみても、いくつかのBlogとかで
「make test いくつか失敗するけど無視する」
みたいなこと書いてあるし、ほんとにこれでいいんかい？？
CentOS4.5,Apache2.2,mod_perl2.0.3
0713nobodyさん
2007/11/24(土) 09:23:53ID:???どんなエラーかも書いてないし…これは酷い。
0714712
2007/11/25(日) 19:11:55ID:???>>713
エラーの内容ってこれ？
t/apreq/big_input....ok
t/apreq/cgi..........# Failed test 1 in t/apreq/cgi.t at line 62
t/apreq/cgi..........NOK 1# Failed test 2 in t/apreq/cgi.t at line 62 fail #2
t/apreq/cgi..........NOK 2# Failed test 3 in t/apreq/cgi.t at line 62 fail #3
t/apreq/cgi..........NOK 3# Failed test 4 in t/apreq/cgi.t at line 62 fail #4
・
・
こんなのが40行ほど続いて、
t/apreq/cgi..........FAILED tests 1-41
Failed 41/41 tests, 0.00% okay
t/apreq/cookie.......ok
これ。つまりt/apreq2/cgi_tファイル全滅。全てのテストが失敗してる。これ以外は全てOKとなる。
このエラー見たところでline**で、コケてるのはわかるんだが、どうゆうエラーかは分からないと思った。
確かに上のスレでは内容書かなかった。すまん。
でも、当然だけどCPANやらで一通りBugReportは斜め読みしてみて、似たようなErrorの報告があったけど明確な解決になってなかったし、
patchも出てなかったから、「libapreq2」とか「libapreq2 インストール」でググってみて、上位のほうにあったいくつかの
インストール手順を紹介したサイト（Blog）の内容に、「make test 通らない」とか、「make test 飛ばす」みたいなこと書いてあったし、
Fedora6,7,8のSRPMの.specも make セクションの後に、test せずに install セクションに入ってたから、
test通らないのがデフォかなって思って、書き込みしたわけなんだが・・・。笑うところか？
まあいいわ。原因はつかんだ。
0715つづき
2007/11/25(日) 19:12:31ID:???で、ちょっと長くなるけど、specに従い
./buildconf
CC=gcc CFLAGS="-O2 -g" ./configure --with-apache2=/usr/local/apache2 --enable-perl-glue
とやるわけなんだが、最後の”--enable-perl-glue”がくせもの。
このオプションは、通常libapreq2のコンパイル、Library(libapreq2.so)とmodule(mod_libapreq2.so)に加えて、
perl-libapreq2モジュール郡のコンパイルも同時に行う。でまあ、
make
make test
と進むわけだが、この全滅する glue/perl/t/apreq/cgi_t は、三つ目(perl-module)のビルドセクション
(Lib、mod、perlとテスト郡が３ステップある。実際makeしてみたらわかる。)に含まれるテストなんだけど、
Library、moduleはなんなくPass(じつはこれも落とし穴あり)して、このperlのテストセクションに入ってから、
問題のerrorが発生する。
で、Test中の動作を追っかけていたんだが、この t/apreq/cgi テストの時は、一時的に
t/の下位dirにcgi-bin/test_cgi.plってファイルが生成されて、それが実際に走ってる(httpd上で)。
で、このファイルはt/apreq/cgiテスト中にしか生存しなくて、次のテストに移ったら消えてしまう。(その間約2秒、その隙に捕獲する)
このtest_cgi.plファイル自体が諸悪の根源。以下中身(の上位行)
use strict;
use File::Basename;
use warnings FATAL => 'all';
use blib;
use APR;
use APR::Pool;
use APR::Request::Param;
use APR::Request::Cookie;
use APR::Request::CGI;
0716つづき2
2007/11/25(日) 19:13:06ID:???特に自分の環境では、Apache2.2系(mod_perlも)を/usr/local/apache2/にインストールしてたんで、
コンソールで、perl -e ’use APR’ とかしただけで、
Can't load ・・・・ libaprutil-1.so.0がロードできません。そんなファイルはありません DynaLoader.pm line230 みたいなErrorになる。
確かlibaprな.soファイル一式は、/usr/local/apache2/lib以下に格納されていて、どうやらここはperlのLIBPATHには含まれていない。
ちなみにperlのLIBPATHは、
perl -e 'use DynaLoader; print join("\n",@di_library_path) . "\n";' で確認できるんだけど、これの結果は
/usr/lib
/lib
/usr/local/lib
となっていて、(perl-5.8.8-4.el4si.i386.rpm)、/usr/local/apache2/等は読み込んでくれない。
仕方がないので、一時的に/usr/local/apache2/lib/以下を、/usr/lib/にコピーして、コンソールで再度 perl -e 'use APR'とやってエラー無し。
しかししかし、これで問題解決にはならないんだこれが・・。
この状態で再び make test としても、やっぱりt/apreq/cgiで全コケは変わらない。
今度は、
use APR::Request::Param;
use APR::Request::Cookie;
use APR::Request::CGI;
この三つ、実は今ビルドしようとしてるlibapreq2-perlに含まれるmodule郡で、しかも内部でlibapreq2.so.3にリンクしてる。で、こいつらが、
Can't load ...APR/Request/Request.so' for module APR::Request: libapreq2.so.3: cannot open shared object file: No such file or directory
なエラーを吐いて、正常に走ってくれないってわけ。
(このlibapreq2.so.file郡は、今まさにビルドしたばっかりのファイルで、libapreq2-2.09/library/.lib/にいて、当然perlのLIBPATH下にはいない)
0717たぶん終わり
2007/11/25(日) 19:13:42ID:???make test せずに
make install してしまい、LIBPATH(/usr/lib/以下)に、いったんlibapreq2.soファイル郡を掘り込んでしまい、
(ApacheがRPMなら、ここに入るはず。でなければ、INSTDIRからここにコピー)その上でもっかい、libapreq2をmakeしたDirにcdして、
make test とすれば、みごと全てのテストに合格する。
(Cent4.5 Apache2.2を/usr/local/apache2/にinstall と、CentOS5.0 Apache2.2-rpmの両環境で確認)
でも、これじゃあなんだか手順が逆じゃない？？
testでCompileコケてないの確認してからinstallじゃん、普通は・・・。
で、なんとかならないかと色々調べてみてんだが、
一時的にperl の DynaLoaderが検索するLIBPATHは、スクリプトの中からなら操作できるようなんだが、
外からやる方法が見つからない。(オプションとかスイッチとかで・・・。)
例えば、
LD_LIBRARRY_PATH=/usr/local/apache2/lib perl -e 'use DynaLoader; print join("\n",@dl_library_path) . "\n";'
とかやれば、@dl_library_pathに /usr/local/apache2/lib が追加されるんで、「お、出来たか」と思ったけど、
だめなんだよ。
0718ほんとに終わり
2007/11/25(日) 19:14:17ID:???前もって、exportしといても、引き継いでくれない。
上の例みたいにワンライナーなり、直接perlを呼べば変数が生きたままになるんだけど、
対象がmakeだと、makeのなかで、何段にもbashを呼び出す(子プロセス扱い)もんで、この$LD_LIBRARY_PATHを継承してくれないようだ。
Fedoraでもこうなるみたい。(Fedora.jpにLD_LIBRARY_PATHがらみのスレにあった。)
ここらへん、自分もあんまり理解がないのと、WebProg板っぽくないので、ム板の方にちょっと出張してきたんだけど、
まだよくわからない。(コレ関係はこれから調べるつもり)
LIBPATHを制御できたら、make test する時にちょこっとコマンド足せばいけそうだけど、出来ないとなったら、
Makefileなり、TESP.PLがらみを書き換えないといけない。(ちょっとで済みそうにない。)
あるいは、/etc/ld.so.confとかあたりかな？
ぶっちゃけ一番簡単な方法は、testしないか、
本末転倒になっちゃうけど、/usr/libなりにso一式をコピー(インストール)してから、testかけるかのどっちかだね。
でも、みんな躓かなかったのか？
2.07以前は試してないからわからんけど、2.08,2.09両方とも、いきなりやって一発目でうまくいかんだろこれじゃあ。
(ってか、make test する以上、絶対コケるようにしか思えないんだが・・・)
0719nobodyさん
2007/11/25(日) 20:48:10ID:???まで読んだ
0720nobodyさん
2007/11/26(月) 12:58:45ID:???0721nobodyさん
2007/11/26(月) 13:24:06ID:???0722nobodyさん
2007/12/02(日) 08:44:17ID:1DkmgRhY0723nobodyさん
2007/12/10(月) 11:46:51ID:???http://pc11.2ch.net/test/read.cgi/php/1018333172/580-581
環境は、
OS:centos5
httpd-2.2.3-11.el5.centos
mod_perl-2.0.2-6.3.el5
になります。
0725723
2007/12/10(月) 21:05:41ID:???ありがとうございます。
早速試してみたところ、無事解決しました！うおおお！
■変更前
<DirectoryMatch "/home/aaa/cgi-bin/(.*.cgi)">
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options ExecCGI +MultiViews
</DirectoryMatch>
↓
■変更後
<Directory "/home/aaa/cgi-bin/">
AddHandler perl-script .cgi
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options ExecCGI +MultiViews
</Directory>
■設定3で追記した通常のCGIで動作させるDirecitoryディレクティブは削除
0726nobodyさん
2008/02/18(月) 21:32:41ID:aEv1JCZt100MBとかの大きなファイルをPHPにアップロードしている最中、
startDelayごとに新しいプロセスが起動されてしまう。
maxClassProcessesかmaxProcessesに到達するまで続く。
どうにかならないでしょうか？
0727726
2008/02/19(火) 18:33:58ID:3qklWUbGWebサーバーからFastCGIサーバーへの、CGIでいうところの標準入力は
すぐ完了するという仮定でコードが書かれてて、
時間がかかる⇒FastCGiサーバーがハング という想定なのね。
ちょこっとパッチ当てるだけじゃ解決できないっぽい…？
参ったなあ
0728nobodyさん
2008/02/19(火) 21:41:50ID:???0729726
2008/02/19(火) 22:41:08ID:???おかげでhttpdが150MBメモリ使ってしまった。
メーリングリストを見ると、MaxRequestInMemディレクティブを使えとのことだが、
症状は変わらない。例え動くとしても、
http://fastcgi.coremail.cn/download.htm
>If the length of http request longer than "MaxRequestInMem", it will store in tmp file.
結局ファイルにバッファリングするだけみたいだし。
Apacheが異常終了したのか、それともFastCGIサーバーが異常終了したのか
0732nobodyさん
2008/02/22(金) 07:02:49ID:???ちゃんとApache権限で呼び出してるんだけど、CGIとして動いてる。
他のも一緒？
0733732
2008/02/24(日) 01:02:41ID:9eLfTMt1誰か教えておくれ。
あと、mod_perlって標準出力も違う？
Image::Magickで標準出力しようとして、
$image->Write('jpeg:-');
の部分でエラー。ファイル場所がおかしいって。
指定方法を変えれば標準出力できる？
0734nobodyさん
2008/02/24(日) 02:11:15ID:???0735nobodyさん
2008/02/24(日) 02:43:34ID:???http://rintaro.dip.jp/program/apbench/index.html
このページ繋がらなくなっちゃってるなー
このスレの人のベンチがあったからたまに見てたんだが
自宅鯖だったんだろな
0736nobodyさん
2008/02/24(日) 16:59:49ID:???mod_perlだとforkするわけじゃなくevalされるからsudoの入り込む余地は無いんじゃないか。
>ファイル場所がおかしいって。
標準出力はSTDOUTで同じ。カレントディレクトリがルートになってるよ多分。
print `pwd`;とかで調べて絶対パスで指定するか始めにchdir。
0737nobodyさん
2008/02/24(日) 17:06:50ID:???STDOUTに出力してるのに「ファイル場所がおかしいって」ってエラーが出るのか
私もわからんです。
0738732
2008/02/24(日) 18:56:01ID:9eLfTMt1sudo -u apache /var/www/hoge.cgi
で動かしたいんだけど、permissionエラーになるの。
当然って言えば当然なんだけど、mod_perlならパーミッション関係なく動くよね？
これはapacheが予めコンパイルしてるからだろうけど、そのコンパイル済みのperlとして呼び出したいんだけどなぁ。
つまり、cronをはじめ、外部から呼び出す時にはmod_perlで動かす事は不可能って事でよいのかな？
url叩けばmod_perlとして動くのかな？
それと他のspeedyとかでも挙動は同じなのかなって質問です。
標準出力についての質問は、
普通"-"で標準出力を指すよね？mod_perlではこれを標準出力として認識しないようなんですが。
0739732
2008/02/24(日) 19:12:29ID:9eLfTMt1あ。ありがとうございます。
標準出力についてですが、そもそも標準出力ってオンメモリーみたいなものだと思ってたのですが、
俺の勘違いでしょうか？
フルパスでどこを指定すればよいのでしょうか？
0740736
2008/02/24(日) 19:43:44ID:???>で動かしたいんだけど、permissionエラーになるの。
>当然って言えば当然なんだけど、mod_perlならパーミッション関係なく動くよね？
mod_perlは独自にapache権限で実行権限があるか調べています。
>これはapacheが予めコンパイルしてるからだろうけど、そのコンパイル済みのperlとして呼び出したいんだけどなぁ。
>つまり、cronをはじめ、外部から呼び出す時にはmod_perlで動かす事は不可能って事でよいのかな？
>url叩けばmod_perlとして動くのかな？
mod_perlは初回プログラム実行時に実行状態のままapacheプロセスの中で待機します。
なのでcronやコンソールから呼び出すときには必ずapacheを通さなければいけません。
>それと他のspeedyとかでも挙動は同じなのかなって質問です。
speedycgiではお望みの動作をします。独自にプロセスを立ち上げるのでapacheには依存しません。
cronやコンソールからの実行でも高速に動作することが可能です。面倒なsocketの管理も勝手にやってくれます。
>普通"-"で標準出力を指すよね？mod_perlではこれを標準出力として認識しないようなんですが。
エラーの原因は標準出力部分ではないと推測します。
出力以前に
$Image->Read('./hoge.jpg');
等をしていませんか？
mod_perl2から標準ではカレントディレクトリの位置がスクリプトを置いたディレクトリ
にならないためno such〜エラーが発生していると思われます。
0741732
2008/02/24(日) 21:05:56ID:9eLfTMt1詳しい説明ありがとうございました。
なるほど。やはりmod_perlですとcronからはURLとして叩く（Apacheを通す）しかないのですね。
speedycgiは挙動が違うというのも非常に知りたい情報でした。ありがとうございます。
標準出力についてですが、
$image->Read('フルパス');
としています。その時点ではエラーは吐いておらず、
$image->Write('フルパス');
としてファイルに書き込む場合は同じく問題ないのですが、
$image->Write('jpeg:-');
と標準出力に出力しようとした場合にエラーとなります。
0742732
2008/02/24(日) 21:10:29ID:9eLfTMt1お詳しいようなのでもう一点質問して良いですか？
mod_perlだとDBとの接続も維持したままになると思いますが、それはspeedyCGIでも同じでしょうか？
なぜcronでmod_perlとして動かしたいかというと、そこにあるので。
0743nobodyさん
2008/02/24(日) 21:59:41ID:???> と標準出力に出力しようとした場合にエラーとなります。
それはWrite時に初めてリード時のエラーを指摘されているだけだと思います。
$image->Read('フルパス') or die $!;
とすればRead時にエラーが発生しているのが分かるかと思います。
>mod_perlだとDBとの接続も維持したままになると思いますが、それはspeedyCGIでも同じでしょうか？
speedyCGIでもコネクションプーリングする事は可能です。
但しmod_perlのApache::DBIのようにトランスペアレントではありませんから
自分でDBハンドルを再利用するようにロジックを組む必要があります。
もしかするとspeedyCGIからでもApache::DBIが利用できるかもしれませんが試したことが無いので分かりません。
0744732
2008/02/24(日) 22:49:11ID:9eLfTMt1ありがとうございます。
ご指摘の通り、Readの時点でこけます。
フルパスで指定しているのに、なぜNo suchが出るのでしょうか？
それとファイルに書き込む時は（or dieをつけなければ)そのままエラー無く処理が完了します。
試しに標準出力ではなくファイル書き込み時ではReadの時点でInappropriate ioctl for deviceというエラーになります。
なぜエラー内容が変わってくるのでしょうか？
pwdの結果は/でしたのでフルパスの指定は間違いないと思うのですが。
0745732
2008/02/24(日) 22:52:20ID:9eLfTMt1Exception 450: Output file write error --- out of disk space? `-'
0746732
2008/02/24(日) 23:14:44ID:9eLfTMt1すいません。どちらの場合もReadの時点で以下のエラーが出ています。
Inappropriate ioctl for device
DBとのコネクションプーリングの件は私には敷居が高そうなのでmod_perlでやってみようと思います。
0747nobodyさん
2008/02/24(日) 23:24:44ID:???とりあえず>>732はこれでも読んどけ
http://www.google.co.jp/search?q=%83R%83l%83N%83V%83%87%83%93%83v%81[%83%8A%83%93%83O%93s%8Es%93%60%90%E0
0748736
2008/02/25(月) 00:37:18ID:???・Readは如何なる場合でも真を返さない
・今回の件はmod_perl時に起こる問題
XSなimageMagickがレイヤー飛び越えて標準出力してるのでIOエラーが出ている模様
標準出力とメモリ展開を混同されているっぽいですがオンメモリでやりたいという事であれば
$image->Write('jpeg:-'); を
print $image->ImageToBlob;
とすれば良いと思います。
なまじっかスキルがあると自分の解釈で勝手に理解してこういう当を得ない質問になるんだよなと
生暖かく見てたがそれは俺でした／(^o^)＼
0749732
2008/02/25(月) 01:01:47ID:r7CiXV4jわざわざ試してまでもらって恐縮です。
ImageMagickは標準出力がmod_perlでは出来ないんですね。
ImageToBlobでやってみます。
長々と素人にお付き合いありがとうございました。m(__)m
0750nobodyさん
2008/03/30(日) 17:36:33ID:???0751nobodyさん
2008/04/19(土) 04:55:36ID:???0752nobodyさん
2008/06/04(水) 04:11:40ID:???0753nobodyさん
2008/06/10(火) 16:29:09ID:m3z0B2HmRubyForApache-1.3.1.exe をダウンロードしてきて
LoadModule fastcgi_module modules/mod_fastcgi.so
するんですが、そんなモジュールは無いとapacheがMSGを出します。
その他mod_fastcgi-2.4.6-AP22.dll等も入れてみてるのですが、
そんなモジュールは無いといわれるのですが、そもそも LoadModule
する前になにかする必要があるのでしょうか？apacheが古い？
教えてください。
0754nobodyさん
2008/06/11(水) 01:21:57ID:???0755nobodyさん
2008/06/11(水) 11:26:09ID:???0756nobodyさん
2008/06/26(木) 03:55:41ID:LMAVX0mlapache2.2のためにはパッチをあてるってあるけど
2.4.6の今もパッチは必要なの？
0757nobodyさん
2008/06/29(日) 00:22:02ID:M9i4VA+K一番安定するという話をネットで目にしたのですが
これは今でもそうですか？
一昔前ならともかく、1.3系はもう古いという印象があるんですが
0758nobodyさん
2008/06/29(日) 00:39:11ID:???あなたの基準で「古い」と何か問題？
0759nobodyさん
2008/06/29(日) 00:43:03ID:M9i4VA+K目にしたブログの記事が少し古いものばかりなので
今の状況は少し変わってるのではないかと思ったのです
0760nobodyさん
2008/06/29(日) 02:14:29ID:???状況も解らずに「古い印象」とかなんとかヌかしてるから言われるんでしょ
0761nobodyさん
2008/06/29(日) 06:14:16ID:???757 ではないが、お前が「古い」の意味を混同してるよ。
日本語が読めればわかると思うが、>>759 で書かれてるのは、
「FastCGIは、apache1.3と組み合わせるのが一番安定するという話」
が書かれた記事が
「少し古いものばかりなので今の状況は少し変わってるのではないかと」
ってことだろ。
Apache 1.3 系が古いか否かや、メンテナンスが続いているか否かとは別次元の話。
で、
> あなたの基準で「古い」と何か問題？
を俺なりに勝手に考えると、
・今時のディストリビューションには標準で付属していないことが多いので 1.3 の導入やメンテが面倒、できればやりたくない
・今はメンテが続いているけどいつかは終わるだろう、当然ながら 2.0 系より早い時期に
ってとこじゃね?
0762nobodyさん
2008/06/29(日) 09:19:02ID:???debian stable 使えばいいと思うよ。今のところ全部そろってるよ。
0763nobodyさん
2008/06/29(日) 19:16:17ID:???Debian でも
・少なくとも静的なファイル配信は Apache2 の方が優れてるからできれば Apache2 に一本化したい
ってのはあると思うよ。
0764nobodyさん
2008/06/29(日) 20:57:20ID:???> ・少なくとも静的なファイル配信は Apache2 の方が優れてるからできれば Apache2 に一本化したい
> ってのはあると思うよ。
何おっしゃりたいのか、さっぱりいみわかんなーい。
持論はブログで展開してくれよ。
0765763
2008/06/29(日) 23:45:25ID:???一応マジレスしておくと、
仮に「FastCGI を Apache 1.3 で動かすべき」という前提が今日も変わらないとした場合、
FastCGI を使う Web サイトを運営するには
・Apache 2.x で静的なファイルを配信しつつ、動的な部分だけ Apache 1.3 に橋渡しする
・静的なファイルも動的なコンテンツも Apache 1.3 で配信する
の2択になるわけだ。
前者は明らかに面倒だわな。避けたい。
後者はまあ Apache 2.x だけで運営する場合と手間的には大差ないが
静的コンテンツの配信パフォーマンスはやや落ちる。
Apache 1.3 がいつまでメンテされ続けるかも不安がある。
しかしもし「FastCGI を Apache 1.3 で動かすべき」という前提がもう過去の話になっていて
現在は別に Apache 2.x でも全然信頼性変わらんよという状態なのであれば
静的なファイルも動的なコンテンツも Apache 2.x に一本化できるわけだ。
どちらの方向で行くかはこの「FastCGI を Apache 1.3 で動かすべき」という伝説が
現在も正しいかどうかにかかってるから、どうなの? というのが>>757の質問でしょう。
0766nobodyさん
2008/06/30(月) 00:09:35ID:???0767nobodyさん
2008/06/30(月) 00:52:55ID:???まあ、2.x用のmod_fastcgiもmod_fcgiもしょーもないとは思うけど
0768nobodyさん
2008/07/01(火) 01:32:06ID:???■apache (1.3.34)
Time taken for tests: 87.821402 seconds
(略)
Requests per second: 1138.67 [#/sec] (mean)
Time per request: 8.782 [ms] (mean)
Time per request: 0.878 [ms] (mean, across all concurrent requests)
Transfer rate: 1279.89 [Kbytes/sec] received
■apache2 (2.2.3 mpm-prefork)
Time taken for tests: 28.611753 seconds
(略)
Requests per second: 3495.07 [#/sec] (mean)
Time per request: 2.861 [ms] (mean)
Time per request: 0.286 [ms] (mean, across all concurrent requests)
Transfer rate: 1744.21 [Kbytes/sec] received
■apache2 (2.2.3 mpm-worker)
Time taken for tests: 32.149481 seconds
(略)
Requests per second: 3110.47 [#/sec] (mean)
Time per request: 3.215 [ms] (mean)
Time per request: 0.321 [ms] (mean, across all concurrent requests)
Transfer rate: 1552.25 [Kbytes/sec] received
localhost から空のコンテンツを取るベンチだから実利用環境ではこんな大きな差は出ないと思うが、参考まで。
0769nobodyさん
2008/07/01(火) 01:38:53ID:???パフォーマンスをとるか安定度をとるかってことか
0770nobodyさん
2008/07/01(火) 18:39:39ID:???0771nobodyさん
2008/07/01(火) 18:41:18ID:???0772nobodyさん
2008/07/01(火) 20:25:22ID:1MihmXWAなんとかならない？
0773nobodyさん
2008/07/01(火) 21:02:49ID:???しょうがないでしょ
0774nobodyさん
2008/07/01(火) 22:13:25ID:???0775nobodyさん
2008/07/02(水) 01:13:34ID:???メンテされてないってことはないんじゃね？
枯れてるだけじゃないの
0776nobodyさん
2008/07/02(水) 02:33:20ID:f6IA2zpT【緊急】 ７・２（水） 毎日新聞本社前抗議活動
＿＿＿
／ ＼
／ ＼ , , ／＼
／ （●） （●） ＼ 行動は起こさないと、何にも始まらない！
| （__人__） | 数は圧力です！ その場にいるだけでいい！
＼ ` ⌒ ´ ,／
. /⌒〜"￣,￣￣〆⌒,ﾆつ
| ,＿_＿ﾞ＿__､rヾｲｿ⊃
| ｀l￣
「毎日新聞本社前抗議活動」 でググってください！！！
「毎日新聞本社前抗議活動」 でググってください！！！
http://jp.youtube.com/watch?v=XnVCDtGRhFU
【緊急】 ７・２（水） 毎日新聞本社前抗議活動
〜 時間がありません！協力をお願いします！！広めてください。 〜
0777nobodyさん
2008/07/03(木) 14:43:11ID:???.fcgiファイルをtouchしたら再読み込みされるらしいね！
これ常識なん？
0778nobodyさん
2008/07/03(木) 21:50:04ID:???mod_perlとか系に対するアドバンテージかもね
0780nobodyさん
2008/07/04(金) 00:15:26ID:???そもそもtouchするなんていうハック的な方法じゃなくて
正式にapiを提供したらいいのにな・・・
0781nobodyさん
2008/07/04(金) 01:38:38ID:???http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
http://d.tir.jp/pw?mod_fastcgi
0782nobodyさん
2008/07/04(金) 10:18:25ID:???なるのかなー？
fastcgi つかうと、FCGI::ProcManager アプリ側と front 両方いじらないと
アプリを再起動できなくね。
メモリ共有せずにプロセスの数分メモリ使っていいなら別だけど。
0783nobodyさん
2008/07/04(金) 19:04:30ID:???再読み込みしてくれるから更新を検知してリロードするロジックやプログラムを
自分で書くことも出来るよ。
0784nobodyさん
2008/07/04(金) 20:22:20ID:???つかったことある？
■ このスレッドは過去ログ倉庫に格納されています