CGI VS PHP VS JAVA

CGI PHP JAVA
WEB上でよく使われている主流系
この中で一番勝ってるのはどれだ!?
討論し合おうではないか！

>>172
亀レススマソ。そう言うレス、必ずつくと思いました。
各言語に最適化を行えば、それぞれがもっと高速化できると思います。
ただ今回のベンチは、「同じようなスクリプト」と、
「ほぼインストールしたまんまの環境」っていうところでやってみました。
だからあくまで参考データ。
だって俺そんなに各言語に詳しくないし。

ファイル操作はPHPでも可能だろボケが･･･。
ついでに言うと機能と言語デザインではJavaの方が優れている。
パールはJavaに追いつこうとした哀れな言語。
それに追いすがるジジイ達も哀れな群集。若者はPHPで十分、
ジジイは税金しか食わんから切り捨てろ。

C++に追いつこうとした哀れな言語じゃないんだ。

コネクションプーリングつかってないだけだったりしてな

とりあえずPerlはもう論外。
いまさら仕事でPerlはもうないでしょ。
PHPとJSPはまだ解らないね。
俺的には両方残る気がするけどね。
だって掲示板にJSP使う馬鹿いないっしょ！？
そう言うときはPHPだろうし。
用は規模によってPHPとJSPを使い分ける！
これが理想。

Perlは専ら趣味で利用

mod_perlマンセー

Javaアプレットってどうよ？
将棋クラブ24の奴とか見るとすげぇー
とか思ってしまうんだが。

yahoo将棋もjavaアプレットだが板違いだな

>>179
すまん、漏れ社内用にServlet/JSPで掲示板作った。
だって、今更PHPとかフリーのCGIとか格好悪いじゃん。

もっちょっとWebに興味ある香具師らが居れば、
PHP使っただろうけどな。
まぁ、開発なんて速攻で終わったし、
どっちでもいいんだが。

格好も何も外面からじゃ分からんし。

>>184
おまえtemplateって知ってますか？

>>185-186
俺は後で保守的な関係から
他人にソース見られた時のことを考えて言ってるんだよ。
遊びじゃねーんだよ、タコ。

>> どっちでもいいんだが。

どっちでもいいわりには
保守的な恥ずかしがりやさんなんですね。
_･)ぷっ

>184
友達少なそうな感じですね。
もうちょっと穏やかに受け取ったほうがいいですよ。

掲示板ぐらいで自慢げな１８４

可哀想な184がいるスレはここですね。

マジな話、servlet + jsp の保守性って、perl と大差無いような

MVCっぽくモデル切り出してちゃんとインタフェース設計すれば
java としてメンテし易くなるんだろうが
まあ掲示板ふぜいにそこまでやるのも無駄な話だ

ぶっちゃけCGIゲームを作るにはどの言語が最適なんだよう
僕にも解るように教えてくれよう
お願いだよう

C++

サーブレットとベンチとるなら、FastCGIも入れてよ〜。

www.bb-chat.tv
ってphpでできてるんだね。
レスポンスは早くってphpってすげぇじゃん！

>>196
宣伝乙。
もう来るな。

チャットレディーとして申し込みたいんだけどネカマでも大丈夫かしら

>>198
このまえネカマがいてびっくりしたよ。
でも、これphpだよな。flash+phpマンセー

>>197
いや待て！これ待機中の女の子の写真クリックすると
女の子のリアルタイム動画くさいのがflushで配信されてて
一瞬ビックリするぞ！
flushって動的に動画埋め込めるんだね…。

ホントにリアルタイム配信だわ
映像なしのチャットレディーはだめなのかしら？

PHPすげ〜な

サーブレットが美味いのはベンダがサーブレットAPIな
共通規格を取りまとめているところで
ぶっちゃけ他の言語でもアプリケーションサーバ+サーブレットAPI相当の
ものがあれば同じことできるし、パフォーマンスも中間コード使ってたら
同じようなもんでしょう。
ただベンダが規格取りまとめてないと自作orいろんな実装あって評価コスト
考えるとjavaが楽だと思ってしまうのがもったいない。

というわけでjava以外のアプリケーションサーバー、フレームワークで
実績あるもののリサーチ、評価を各言語のコミュニティが
さっさとやれ。

メモらせろ。

http://matsui.jpn.ph/computer/FastCGI.html
CGIスクリプトは何で書く？
FastCGIで10倍高速化

CGI::Fast - Fast CGI のためのCGIインターフェース
http://homepage3.nifty.com/hippo2000/perltips/CGI/Fast.html

既存の CGI をそのまま FastCGI 対応に
http://sugi.nemui.org/diary/20040723.html#p04

既存のCGIプログラムの修正を最低限にしてFastCGI対応にする方法について。
http://www.rubyist.net/~matz/20040723.html

ノロ亀recv攻撃て知ってます？
1バイトrecvしては10秒スリープするタイプのクライアントです。
もしもgazo.cgiがperlで動いてるとしますね。
gazo.cgiは100KB程度の画像をstdoutに書くとします。
ノロ亀recvするとperlのプロセスは終わるまでなかなか消えないんです。

それなら何使おうがApacheのプロセスがいつまでも残るから駄目ぽですな。
Apache2をworkerで運用したらworker未対応なmod_phpも駄目ですな。

javaといってもC並にピンキリだしな。
でもperlとPHPがゴミしか無い。
社内用途の内輪用ならperl/php/jspでもまだ限定的だけど、インターネットに公開しててperl/php/jspってのは全世界にスキルの低さを広報してるだけ。

一年も前のレスに馬鹿丸出しｗ

あのー、PHPとCGI/Perlってなにが違うんでしょうか？適応と鯖負荷と組み安さの面で。

教えてください。

#JSPとかASPとかCとかの選択肢はなしで。

5年前に立ったスレが浮上してきたのか。
>>211
CGI/Perlなんて書いてる時点で勉強してなさすぎ。
この板を1年ぐらいＲＯＭって下さい。

>>211
PHPはApacheのモジュールという意味かな
だったらCGIよりモジュールの方が負荷は小さいよ。
PHPもCGIで動かせば負荷は大きくなるしCGI/PHPはCGI/Perlより遅い。
Perlもモジュールなら負荷軽くなるしmod_perlの方がmod_phpより早い。

>>213
ですです。

で、CGIからモジュールにするとすべてにおいて速くなるというわけではないですよね？
あくまでスクリプトが走り始めるまでの時間が短縮されるだけで。
走り始めるまでの時間ってそんなに長いんですか？

>>214
とまっている人にバトンを渡すのがCGI
平走している人にバトンを渡すのがmod
走る速さは同じね。
トップスピードまでの時間の差はスクリプトのつくりによる。

2chもモジュールじゃなかったっけ？？

mod_perlは常駐するからさらに早くなるよ。

［WSJ］ Netscapeの生みの親がPHPを支持
http://www.itmedia.co.jp/enterprise/articles/0509/29/news066.html

「2005年におけるPHPは、1995年におけるJavaのようなもの」
――Netscape共同創設者のマーク・アンドリーセン氏は、JavaはWebアプリケーション構築において、
PHPに取って代わられると言う。

PHPってむしろ衰退しているイメージあるんだけど

俺的には平行線のイメージ。

>>215
ありがとうございます。
んで、｢トップスピードになるまでの時間｣というのはかなりでかいものなんですかね？
それと、｢トップスピートになるまでの時間｣を長くする要因はどんなものがあるんですか？

メモリに常駐するというのは、速いけれども、裏を返せばメモリを食うんじゃなかろうかとか思うわけですけども。

概念にこだわってると何も出来ないと思うよ。
変数の初期化やメモリ空間の確保、環境変数の取得などなど。
比較すればどちらが速いかだけど、結局はコーディング次第。
メモリは食う、鯖は石よりもメモリ。

>>212
>>211はこのスレを1年ぐらいＲＯＭって意見してるんだから答えてやれよｗ

mod_phpは
>変数の初期化やメモリ空間の確保、環境変数の取得などなど。
この辺関係ないでしょ

modとCGIの違いの話でそ。
PHPにもCGIモードはあるよ？

mod_phpは漏れなくデストラクトされるので。
PHPの場合、modとCGIの違いはインタプリタがロード済みってだけじゃないの？

PHPってCGIにすると恐ろしく遅い、

>>227
Perlはもっとおそいがな

CGIの遅さでは、Javaにかなうものはないだろう。

JavaはCGIを使わないからな

>>230　？

>>231は>>230が何を言ってるのか理解できないみたいだｗ

>>232
×xxxはCGIを使う
○xxxをCGIとして使う

まず>>228が大きな勘違いをしてる

>> 232
むしろ、>>230が>>229が何を言ってるか理解できないみたいだｗ

グダグダっぷりがﾜﾛｽw

以上を総合すると…

mod_perl＞mod_PHP≫PHP＞perl＞JSP

ってところか？

スピードは、mod_perl>mod_php>>perl/cgi>>>php/cgiな感じ。

正直、SAP R/3ともOracle Applicationsとも繋がらない時点で、Java以外は論外なんだが…。

PHPのバージョンが変わるとしばしば既存アプリが動かなくなるところが使えない。
PHPに食わしてもらってきたが、Javaと.NETの世界に行きそうです。
＃もうVerUP時にテストしたくないっす。PHPに疲れました。。。

「オープンソースだからベンダ非依存で技術の寿命が長い」って
伝説を流布したがっているけれど、実態は、後方非互換に気を使わない文化だから、
実は寿命短い。

バグがあっても自分でソースいじって治せるから、理論的には寿命がながいけどね。

>242

わかってるんだと思うが、

>自分でソースいじって治せる

くらいたちが悪いこともなくて。。。。
ソースなんていじりたくないです。いじれないことにしといて
できないことにしといたほうがなんぼ楽か....

そいやあ、javaでCGI、作ったことあるよ。
あいつもなんか動いてるみたいだなあ...7,8年になるかな。このスレより古い（笑）

実際、クローズドソースでバグがあったら、バージョンアップするしかないから。
一番長いところをみればオープンソースのほうが寿命が長い。
でも、一般的な利用者を見れば、開発が終わった時点で終わりだな。

システム寿命を比較すると、独自開発、次がクローズド、最後がオープンソース。
意外だろうけど、事実なんだな、これが。
例外は多数あるだろうけれども。

どっちが長いのかわかりません・・・

Apache の MaxClients(子プロセスの最大数) デフォルト設定は 150。
他のモジュールにも影響されるが、mod_perl 組み込み時、子プロセス1つのメモリサイズが 20〜30MB 程度になる。
よって、同時接続数 150 までアクセスされると 3G から 4.5G メモリを喰うことになる。

Perlはバージョンアップで仕様変更が少ないので殆ど手直しは必要ないが
他の人間が保守・改良・バグつぶしするのには向いてない。
PHPはバージョンアップで互換切られたりするが
他の人間が容易に習得でき、保守などが楽

俺は、PHPの方が好きだな。
他人とPerlで一緒に仕事するなんて、ありえない。

>>247
mod_perlを使いこなせていない奴はそうなるなw

>>248
それは言語に限らず組み方次第なわけだが。

ヘタレが書いたJavaのコード >>|超えられない壁|>> ヘタレが書いたPHPのコード>>>>>|超えられない壁|>>>>>ヘタレが書いたPerlのコード

>>247
Fedora core4ではデフォルトで10MBくらい。
メモリ使用量はMaxSpareServers × 10MB
お前の理論だとMaxClients100以上でmod_perl動かしているほとんどのサーバーは
F5連打されるとメモリリークしてしまうという愉快な状況になる。

狭義しかしらない日本人、乙

負け惜しみ、乙

↓、乙

え？俺？

↑、乙

>>257
乙

>>252
247の理論だとFedora4をデフォルトで動かしているサーバーは
メモリ1.5GB必要以上になる。
mod_perlはメモリ食うと聞いていましたがApacheもこんなにメモリ消費
するとは思いませんでしたｗｗｗ

そりゃ150プロセスも同時に走れば、どんなメモリ積んでも足らないだろう。
そういう意味で>>247の言ってることはあってる。
後、単にメモリを消費するのと、メモリリークはまったく別。>>252はアホ確定。

ここは必死なインターネットですね

>そりゃ150プロセスも同時に走れば、どんなメモリ積んでも足らないだろう。
Apacheが処理するプロセスとApache自体のプロセスは別物ですよ。
プログラム、Apache、UNIX
誠に残念ながらこれら全ての知識に欠けているようです。
初心に戻ってこんぴゅ〜た〜の基礎から勉強するのがよろしいかと思います。

あと>>257への感謝の気持ちを忘れずに。

>>263
で、メモリリーク、の意味は勉強たか？

メモリリークっていうのは、Cで変数の破棄し忘れとかで出来るもんだろ。
リクエスト毎に必ずプロセスが死ぬCGIやmodphpには縁のない話。
modperlだとプロセスが残るけど、それだったらF5連打でなくも、自然にリソース食い尽くす。
それと、modperlは1個のプロセスのサイズがデカいんだから、100とか150とか同時に走られたら持つわけないだろ。
どうやって少ないプロセス数に抑えて回していくかだろ。
modphpみたいに使い捨てじゃないんだから。

>リクエスト毎に必ずプロセスが死ぬCGIやmodphpには縁のない話。
CGIやmod_phpではそのプロセスで利用したメモリ等は全てデストラクトされますが
shared memoryを使用すれば当然プロセスが消滅した後もメモリは確保されたままなので
CGIでもメモリリークは発生します。

>modperlだとプロセスが残るけど、それだったらF5連打でなくも、自然にリソース食い尽くす。
mod_perl自体は新たにプロセスを作りません。fastcgiなら自ら生成するでしょう。
自然にリソースを食い尽くすのであればそれはバグです。バグリポートを出せば非常に喜ばれるでしょう。

>それと、modperlは1個のプロセスのサイズがデカいんだから、100とか150とか同時に走られたら持つわけないだろ。
「mod_perlに1個のプロセス」という概念は存在しません。また、モジュール自体のサイズはmod_phpの1/10程です。
同時にApacheプロセスが100〜150走らせるのは非常にトリッキーでありメリットも薄いためそのような設定で
運用しているサーバーはほとんど無いでしょう。

>>267
BEを忘れてますよ？

>>267
じゃあmod_perl環境下のApacheの子プロセス、と言い換えるよ。

話の始まりは>>247だぞ。MaxClients150のままでF5連打されたら、それは落ちる。
それはPerlプログラムの書き方が悪いって問題じゃない。
これはメモリリークとは関係のない話だ。

MaxClientsが10だろうと256だろうとApacheの消費するメモリの上限は増えませんが。

痛々ｼｽ

>>270
MPMによって変化量は違えどApacheのメモリ総使用量は増えるだろ。

>>270
> MaxClientsが10だろうと256だろうとApacheの消費するメモリの上限は増えませんが。
↑素で意味がわからないんだけど。どういうこと？

>>257は神に召されました。合掌！