【Java PHP CGI mod_perl】の使い分け for プロ
■ このスレッドは過去ログ倉庫に格納されています
JavaservletとPHPとCGIとmod_perlってどうやって使い分けてますか?
それぞれ長所、短所があるとおもうんですが、趣味ではなくて、お仕事で
やってる人の見解・意見を求む 先に挙げたcgi以外は、速いようですが一部不安があるのです。
自社の顧客専用の共有サーバで顧客のWEB運用する際に、
週一しかアクセスのないような管理画面等といったプログラムを
mod_perlやservlet、phpなどでメモリーに常駐させて大丈夫なもの
なのかと心配だったのです。
実際は、もっとそれぞれの長所短所を見極めればもっと最適な
使い分けがあると期待して書き込みました。皆さんのおっしゃる
通り使い分けなんかしなくてもいいのかもしれませんが‥
サーバを管理する立場であり、開発を発注する立場である方が
おられたら、どのように開発指示を行っているのかお話が聞ければ
幸いです。 >>1-100
はいはい下げるよ〜下げちゃうよ〜。
俺は本当に下げたいのかと問いたい、問い詰めたい、小・・・ブチッ >>22
お前は本当に下げられると思っているのかと問いたい、問いつめたい、小一時間t……バタッ 最後に添付する Perl と Servlet に 500 回リクエストを発行する
テストを5つ同時に実行した結果です。500回実行するのにかかった
時間が xx wallclock secs と表示されています。
[perl モジュール] mod_perl 1.21 (perl 5.005_58)/Apache 1.3.6
perl: 49 wallclock secs ( 1.56 usr + 0.63 sys = 2.19 CPU)
perl: 49 wallclock secs ( 1.56 usr + 0.54 sys = 2.10 CPU)
perl: 53 wallclock secs ( 1.58 usr + 0.57 sys = 2.15 CPU)
perl: 55 wallclock secs ( 1.69 usr + 0.64 sys = 2.33 CPU)
perl: 54 wallclock secs ( 1.54 usr + 0.59 sys = 2.13 CPU)
[servlet] Apache JServ 1.0/Apache 1.3.6, JDK 1.2.2 + HotSpot 1.0fcs
servlet: 76 wallclock secs ( 1.71 usr + 0.85 sys = 2.56 CPU)
servlet: 77 wallclock secs ( 2.08 usr + 0.69 sys = 2.77 CPU)
servlet: 78 wallclock secs ( 1.90 usr + 0.87 sys = 2.77 CPU)
servlet: 78 wallclock secs ( 1.99 usr + 0.76 sys = 2.75 CPU)
servlet: 78 wallclock secs ( 1.90 usr + 0.78 sys = 2.68 CPU)
[servlet] JSWDK 1.0 EA, JDK 1.2.2 + HotSpot 1.0fcs
servlet: 22 wallclock secs ( 1.20 usr + 0.29 sys = 1.49 CPU)
servlet: 27 wallclock secs ( 1.45 usr + 0.53 sys = 1.98 CPU)
servlet: 28 wallclock secs ( 1.48 usr + 0.48 sys = 1.96 CPU)
servlet: 28 wallclock secs ( 1.53 usr + 0.53 sys = 2.06 CPU)
servlet: 28 wallclock secs ( 1.58 usr + 0.60 sys = 2.18 CPU)
[CGI] Apache 1.3.6 (perl 5.005_58)
cgi-bin: 647 wallclock secs ( 1.58 usr + 0.57 sys = 2.15 CPU)
cgi-bin: 665 wallclock secs ( 1.63 usr + 0.54 sys = 2.17 CPU)
cgi-bin: 671 wallclock secs ( 1.52 usr + 0.61 sys = 2.13 CPU)
cgi-bin: 673 wallclock secs ( 1.65 usr + 0.62 sys = 2.27 CPU)
cgi-bin: 673 wallclock secs ( 1.52 usr + 0.57 sys = 2.09 CPU)
>>24
なんつーか、全体的にバージョンが低いのはなぜ。。。
チャットを作る場合
CでCGI,mod_perl,PHPどれが速くて軽いですか? Cでアパッチのモジュール作るのが一番はやいはず。
あとはあなたの腕次第YO! ごめん。
サーバも含めてCでつくる方が多分早い。
さらに究極を求めるならハードウェアから設計するのもありか・・・。
あなたの腕次第YO! 共用サーバーなのでCでCGI,mod_perl,PHP(Apacheのモジュール)しか選択肢がありませんYO! じゃあそのサーバーを軸にハイブリッドP2Pチャットできまり!
あとはあなたの腕次第だYO。 >>32
PHPよくしらんけど、意図しないコードをレスポンスで投げる可能性ない? Apacheで
http://***.com/~(User Account)/
という感じでUserDirを切る際servlet(jakarta-tomcat)
の環境も提供できるようにする方法ってあるの?
たとえば
http://***.com/~(User Account)/test.jsp
って感じで。 チャットは、会話の内容をファイルに書き出さないでメモリー上で処理するようにするとそれなりに速いなり
> 35
サーブレットの場合はアパッチにモジュールを組み込む必要があり、サーブレット特有のプロパティーズ系ファイル
でマウントポイント等を設定するようになっていたと思いますが、わたしは2年以上前までしかやっていないので
現状はなんともいえないネー。 > 37(間違ってたみたい)
サーブレットのモジュールがアパッチに組み込まれていれば、
サーブレットの.confファイルはアパッチの設定ファイルからインクルードされるので
そこで指定できるマウントポイント以下のjspゾーンは直接書けそうですネ。
######## servlet.conf ###
ApJServAction .jsp /zonejsp/gnujsp
ApJServMount /zonejsp /zonejsp 将来的に大きな業務が発生するかもしれぬ可能性を考慮すると、Servlet使い
たいんだけど、サーバー運用者からは、「Servletはサーバーのメモリを
食いまくるのでPHPで」なんて言われている。
でもPHPって開発効率(ぱっと作るにはいいけど)、言語としての将来性が不安。
Tomcat ってそんなに不安定なの?
どうなんだろー? PHPの将来を不安するころまでクライアントが同じ仕様でページを維持してくれるかの
方が不安でしかたない。 >>40
単体のサイトに関してはせいぜい寿命が3年程度で大幅なリニューアルが
行われると思うので、今、流行の言語を使用することで特に問題はないと思う。
…が不安なのは、PHPの普及が今後拡大していくか否かですよ。
大規模なシステム開発での主流言語になりえるとは思えないけど、じゃあこのまま
のポジションでずっと行くの?っていう話。 PHPって、小中規模でも何種類かのRDBMS(のクライアント)を同時に扱う場合って苦手だよな。
あのHTTPDのデブり方は尋常じゃない。 >>44
コネクションプーリングしてるんだから、しかたないと思うんだけど..。
Javaだと違うの? 大規模 JAVA
中小器 PHP、PERL
生産性 PHP・PERL>JAVA
分散機能 JAVA>PHP
かな?
現在、apache+perl+mysqlで個人サイトを運営して
います。access_logを見ると、一日平均のアクセス数は、
*.htmlなどのページへのアクセス:700回
*.cgi, *.plへのアクセス数:200回
このような状況で、mod_perlをインストールするメリットは
ありますでしょうか? >>47
そのPerlプログラムがmod_perl環境下で正常に動作するかどうかが一番の問題。
正常動作するならPerlによるCGIの問題点をほとんど解消できるんだからメリットでしょ。
スコープを意識したコードでも、書き方によっちゃー全然ダメな場合もあるよ。 mod_prelとPHPの違いについて誰か教えてくれ。
>スコープを意識したコードでも、書き方によっちゃー全然
>ダメな場合もあるよ。
mod_perlを使う場合はに、全てのCGI(xxx/cgi-bin/ ディレ
クトリーにある全てのperl code)を同時にmod_perl化
(mod_perlがcodeを読み込むディレクトリーに移動)
しなければ、いけないのですか? それとも、問題のない
CGIコードから順々にmod_perlディレクトリーに移し、
問題があるコードはCGIで稼働させる、という経過処置
は技術的に可能でしょうか? >>50
大抵の所は拡張子で動作分けしてる。
「.cgi」なら通常のperl、「.mpl」ならmod_perlみたいに。 >正常動作するならPerlによるCGIの問題点をほとんど
>解消できるんだからメリットでしょ。
CGIが「毎回、perlを起動して、perl codeをコンパイルする
ために遅い」というのが、問題点として挙げられますが、私の
個人サイトでは、1000行程度のperlコードをCGIで運用してい
ますが、この「遅さ」というのが実感できないでおります。
同じコンピュータ(Mac OSX)で、Tomcatを動かしてい
ます。Tomcatで運用しているServeletは100行程度なのに、Tomcatが最初に起動して、Serveletを読み込んでい
る時間は、8秒前後かかっています。
どうして、apache+Perl CGIでは、「「毎回、perlを起動
して、1000行程度のperl codeをコンパイルする」にもかか
わらず、Tomcat+Serveletの起動時のような長い時間がかか
らないのでしょうか? >>50
あるディレクトリ以下はmod_perlを有効する、って事でしょ?
perlディレクトリではmod_perl
cgi-binディレクトリでは通常のまま、みたいな。
これは出来ますよ。
>>53
>Tomcatで運用しているServeletは100行程度なのに
>Tomcatが最初に起動して、Serveletを読み込んでい
>る時間は、8秒前後かかっています
それはservletのコーディングに問題があるのでは?
普通servletは早いですよ。
でもmac OSXは使わないのでわからないっす。 > それはservletのコーディングに問題があるのでは?
> 普通servletは早いですよ。
一度、Tomcatが立ち上がってしまえば、serveletの
実行は速いのですが、Tomcatの起動(再起動)に8
秒前後かかっています。
apachectl gracefulでapacheを再起動させても、
topで確認できるCUPの使用量は一瞬で0になり
ますが、Tomcatを再起動すると、8秒前後、CUP
の使用量が50%を超え続けます。apache再起動の
後に、1000行前後のperl CGIを実行しても「8秒
前後」待たされることもありません。
もしかしてApacheと連携させてない?
連携させれば解決でしょ。
>もしかしてApacheと連携させてない?
Tomcatは、Apacheと連携させています。
私の発言の趣旨は、Tomcatの起動が遅い、という
ことではありません。ある程度の大きさのアプリケー
ションであれば、起動時間が長くかかるのは当然です。
それなのに、perl-CGIの起動時間だけ、なぜ短いのかが
不思議に思い、質問したわけです。本当に、CGI-perl
は、毎回、perlを起動して、perlスクリプトをコンパイル
しているのでしょうか?
1日200くらいのアクセスだから軽いの。
1時間200以上のアクセスになってきたら体感できる。
っていうか、ApacheとTomcatを連携させているなら、常にTomcatは起動してるんだぞ?
起動に8秒以上かかるって尋常じゃないって。Webサービスとして成り立っていないスピード。
普通のPerlによるCGIだったら毎回コンパイルしてるよ。何を疑ってんの?
ちょっと回答する気がなくなってくるね。。。 57はTomcatを再起動してるんじゃねーの。
JavaVMの起動で遅くなってる予感。 >57はTomcatを再起動してるんじゃねーの。
わざわざTomcatを再起動するのは、時間を計るためで、
通常の運用では、再起動はしません。
>普通のPerlによるCGIだったら毎回コンパイルしてるよ。
>何を疑ってんの?
私が疑っているのは、アクセス回数の低い状況では、
コンパイル済みのPerl-CGIがメモリーにキャッシュされ
ているために、起動+実行速度が速いのではないか、とい
うことです。もしも、そうだとすると、アクセス回数の低い
サーバーでは、mod_perlをインストールしても、実行速度
があがらない、という可能性はありませんか? だから、普通のCGIはキャッシュされねーっつうの!
可能性もクソもないんです。 アクセス回数が低い&最近の鯖の性能向上で
体感できないんじゃないか?
TomcatのほうはJSPのコンパイルのことを
言ってたらぶっとばす! >TomcatのほうはJSPのコンパイルのことを
>言ってたらぶっとばす!
もし↑だったら俺もぶっとばす!
なんか読解力のない厨が混じってるような気がしないでもないが。
>>61
PerlインタプリタやスクリプトがディスクI/Oのキャッシュ(=メモリ)に
キャッシュされる可能性はあるが、通常のCGIを経由して起動されたPerlでは
ソースコードの内部コードへのコンパイルは毎回行われる。
その処理がJavaVMの起動に比べて圧倒的に速いというだけのことだ。
従って、実際のスクリプトを処理するコストに比べ、
コンパイルとプロセスforkのコストが比較的大きくない限り
(まあ通常はプロセスforkのコストが大きいわけだが)mod_perlを導入する
メリットはあまりない。 >PerlインタプリタやスクリプトがディスクI/Oのキャッシュ
>(=メモリ)に キャッシュされる可能性はあるが、通常の
>CGIを経由して起動されたPerlでは ソースコードの内部コー
>ドへのコンパイルは毎回行われる。
なるほど、I/Oのキャッシュの可能性はあるわけですね。
なぜ「キャッシュ」というのに、こだわったかと言えば、
「Googleの検索が速いのは、毎回、検索を実行しているのでは
なくて、よく行われる検索は、その検索結果がキャッシュされ、
それが再利用されているから」という話を聞いたことがあり、
検索結果のキャッシュが可能ならば、コンパイル済みのPerl-
CGIをキャッシュする方が簡単にでくる、と(素人なりに)考
えたためです。
>>67
まあそれを実現しているのがmod_perlのApache::Registryなわけで。
プロセスforkのみ回避してコンパイルは毎回行うApache::PerlRunというものが
存在している理由は即ち一般にコンパイルのコストよりもプロセスforkのコストの
方が高いからなんだがね。
いずれにせよ、同時複数アクセスがリソースを奪い合うとかそういう状況でないと
大した恩恵はないな。 ━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━― ∧_∧
ピュ.ー ( ^^ ) <これからも僕を応援して下さいね(^^)。
=〔~∪ ̄ ̄〕
= ◎――◎ 山崎渉
__∧_∧_
|( ^^ )| <寝るぽ(^^)
|\⌒⌒⌒\
\ |⌒⌒⌒~| 山崎渉
~ ̄ ̄ ̄ ̄ ∧_∧ ∧_∧
ピュ.ー ( ・3・) ( ^^ ) <これからも僕たちを応援して下さいね(^^)。
=〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
= ◎――――――◎ 山崎渉&ぼるじょあ (⌒V⌒)
│ ^ ^ │<これからも僕を応援して下さいね(^^)。
⊂| |つ
(_)(_) 山崎パン PHPも5まで来るとついにオブジェクト指向言語になっちゃうんだねぇ。
でもさぁ、ここまでやると最大の利点だった生産性が下がっちゃうんじゃないの?
Javaservletで作るのと変わらん気がするんだが・・・。
> オブジェクト指向言語に生まれ変わるPHP5
> ttp://www.atmarkit.co.jp/flinux/special/php5/php5a.html PHPはOOPできるようになるんだが、実際そうやって書かれることは稀と予想、、。 つーか、さらっとしか読んでないが、型チェックがないのに、仮想関数とか
入れてどうすんの?っていう疑問 >>84
だよね。作者の自己満足としか思えない。いかにも中途半端。
これが決定打になって、PHP のユーザは ruby, python へ移行していくだろうね。 >>86 >ruby, python へ移行
Javaならともかく、それは考えにくいな。
PHPは明かに変な言語だけど、ウェブでのメリットは大きいから。
この辺でみなさんに質問。
2005年にあなたがメインで使っているであろう言語は?
そして時々使用するであろうサブの言語は?
おれはメインがJavaでサブがPHPかな。
Javaはサーブレットからアプレットまで広く使い分けられるし、PHPはコマンドラインでもそれなりに使えるようになってきたから。 ああ、もちろん職場の方針も織り込み済みでよろしく。
>>88
職場はJava以外にないな。
個人的にはPHPがラクでいいけどな。 struts的なframeworkはPHPにあるんですか? >>91
こんなの見つけましたよ
http://openlab.dino.co.jp/
・ID/PASSによるユーザ認証
・10levelsのリニアなユーザ権限
・確実なSQLを生成する、SQLビルダ
・テンプレートエンジンとそのカスタムタグ
・フォームのバリデーション、テンプレート連携
・携帯電話(iモードなど)対応コンテンツ作成、PCとのハイブリッドコンテンツの作成
・Wikiエンジンを搭載したコンテンツ管理システム
【ゴールデンレス】
∩ ・∀・)∩∩ ´∀`)∩ このレスを見た人はコピペでもいいので
〉 _ノ 〉 _ノ10分以内に3つのスレへ貼り付けてください。
ノ ノ ノ ノ ノ ノそうすれば14日後好きな人から告白されるわ宝くじは当たるわ
し´(_) し´(_) 出世しまくるわ体の悪い所全部治るわでえらい事です
マカーっていつもアフォだな。氏ねよ。
プロつーか飯喰ってる香具師なら、単価高いJava以外選択枝無いだろ。
PHPなんてデザの範疇だ。 PHPでそれなりに書けるようになっただけの自称プログラマが、
安易にSOHOに手を出し始めて、適当な仕事を安く上げて単価を下げている件 そんな案件捨てておけい
PHP SOHO 月60万 自称プログラマー
って得意気に言うじゃない
それプログラマーの最底辺ですから〜!! 「PHP作者がYahoo!にいる」と言うとなんか凄そうだけど、Yahooの
Rasmus Lerdorf氏はPHP/FIの原作者であって、PHP3のエンジンや
Zend Engineはほとんど手がけていないんだよな。 >>98
PHPだけで月60万も出るならJavaなんてとっくに消えてる罠 PHP SOHOで年500万って一般企業の大卒1年目以下のレベルだよなぁ C/C++/C#、JavaScript、Java、VB、PHP
な俺ですら、月20万だ。
PHPだけで60万も出るかよw 月30もらえれば十分だよ・・・という俺はどれに集中したらいいでしょうか。 >>99
PHP/FIはアイデアとしてすばらしかったけど、PHP3以降どんどんクソになっていってないか? >>101
SOHOなら、年500万ってことは、サラリーマンの年400万程度かな。 >>91
mojavi(だっけ)とかいいんじゃん
俺も、特殊な要望がない限り、何の言語でもいいと思うな。
ちゃんとしたの出来上がるなら。
個人的にはJavaが好き。
フレームワークとかいっぱいあって飽きないから。
って、ASP使ったことないんだけどね。エヘ って>>91、2003/09/13
(((;;゚д゚))) >>53 をもう一度掘り起こしてみようっと。
同じサービスを提供する、servlet と Perl のコードをそれぞれ書いた。
Apache 以外起動していない状態から、コードが実際に web サービスとして
クライアントに提供されるまでの所要時間は
servlet → 8 秒
Perl → 一瞬
となった。
この違いは何なのか?つーか Tomcat の起動が 8 秒くらいかかるんだけど
この 8 秒ってどうしても必要なの? 逆に、Perl 側で必要無いのはなんで?
俺漏れ Tomcat の役割あんま知らない。。。誰か解説よろ。。。 >>110
…TomcatはApacheと一緒に事前に起動しておくものだよ…。 だから、なんで、8秒も時間がかかるナニカを
特別に用意しなきゃいけないの?って事じゃね?
Perlはperlだけでうまくやってくれるのに、って。
いや、最初の8秒くらい気にすんなよって言いたいんだろうけどさ。
んでオレ思うに、JSPは重長広大なサービスを
比較的手軽に提供できるわけだな。
それこそ、一旦tomを起動しちまえば、セッション管理とか
えーと、よく分かってないけど、色々tomの野郎がやってくれるらしい。
8秒ってのは、そのための初期投資だよ、と。
そういう事でいいんだろ? えーとだからあれだ。自転車と自動車。
自転車は玄関を出て車庫に行って自転車にまたがって、スタート。
どこにでも行ける。細かいところにも手が届く。
自動車は玄関を出て車庫に行って自動車に乗り込んでシートベルトを
しめてエンジンをかけてドゥルンドゥルン、ブレーキを離しつつ
アクセル踏み込んで、ようやくスタート。
一旦スタートしてしまえば、速い。超速い。高速道路とか構わない。やばい。
どうだ。だめか orz JSPしか使わないんじゃ、JavaAPサーバ入れる価値無いのでは。 >>110
ところでWebサービスって言葉の意味知ってますか? まぁわざわざJava使って嬉しいのは、個人的には
マルチスレッドの扱いやすさかね。
要求するコード記述が厳密なのもスキ。
(暗黙的な型変換をあまりしない)
DI・AOPが充実してきたのもポイント。
言い出したらキリがないが、Javaでできることのほうが多いはず。
まぁPHPで大抵はことたりるんだけど。
>>117
> DI・AOPが充実してきたのもポイント。
おいおい。見事に世間に踊らされてるな。
型が厳密でコンパイル時に確定できるのがメリットだったのに
実行するまで何が起こるか分からなくなってしまうんだぞ。正気か? ソフトウェア開発には、しばしば交わっているがたいていは分かれている、
5つの世界がある。
その5つとは:
1.パッケージ
2.インターナル
3.組み込み
4.ゲーム
5.使い捨て
スクリプト言語の得意分野は、5.
プログラマーのSOHOは経費かからないから、売り上げがそのまま自分の収入になるよ。
だって、PCとネット環境さえあれば仕事できるんだもん。
■ このスレッドは過去ログ倉庫に格納されています