幅広い分野のJavaと名前空間なき脆弱なるPHP
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2006/04/25(火) 01:21:04ID:???まだまだほど遠い。
Javaを越えるには名前空間のサポート、Web以外の分野携帯電話、ドライバ開発、
GUI、COBOLをリプレースできるほどの金融システム、自動販売機、火星探査機
にも使えるようでなくては、PHPには未来はなく、VB同様いつまでたっても馬鹿に
される厨房向け言語に成り下がるであろう。
PHPの仕事は確実に増えているとはいえ、まだまだ、Javaに多い金融システムを
構築するほどの言語としては適していない。アクセス数だけが多い、
はてなダイアリーやmixi、Yahoo程度の小さなプログラムを作ることにしか
向いていないのだ。PHPだけで銀行口座の引き落としや銘柄の注文など
二重引き落としの恐れがありあぶなっかしくてやっていられない。
過去スレ：
【戦場は】PHP王とJava乞食【ｴﾝﾀｰﾌﾟﾗｲｽﾞ】
http://pc8.2ch.net/test/read.cgi/php/1140124172/
【5.1発表】PHP一色 さようならPerl【Javaを凌駕】
http://pc8.2ch.net/test/read.cgi/php/1134820417/l50
【明暗】金持ちPHP様・貧乏Perl様【格差】
http://pc8.2ch.net/test/read.cgi/php/1132681055/
【5.1登場】PHP時代到来 他言語終了【Perl即死】
http://pc8.2ch.net/test/read.cgi/php/1129715894/
優秀な言語が色々ある時代 粗悪PHPの出る幕なし
http://pc8.2ch.net/test/read.cgi/php/1127441561/
今はPHPの時代Perlがこの先生きのこるのは無理3
http://pc8.2ch.net/test/read.cgi/php/1116912721/
これからはPHPの時代Perlはもう終わりバイバイ2
http://pc8.2ch.net/test/read.cgi/php/1046194468/
Perlはもう時代遅れPHPの時代
http://pc2.2ch.net/php/kako/1036/10369/1036915437.html
0554nobodyさん
2006/06/07(水) 23:27:09ID:???0555nobodyさん
2006/06/07(水) 23:36:27ID:???0557nobodyさん
2006/06/08(木) 00:43:31ID:???鯖側プログラムでPHPってmod_phpしかないと？
鯖側プログラムでJavaってAPサーバを必要とするものしかないと？
0558nobodyさん
2006/06/08(木) 02:03:11ID:???> 鯖側プログラムでPHPってmod_phpしかないと？
何がありますか？
> 鯖側プログラムでJavaってAPサーバを必要とするものしかないと？
何がありますか？
お願いだからCGIなんて言葉出さないでよ。
0559nobodyさん
2006/06/08(木) 02:19:58ID:???重い処理をこなすにはJavaやPerlの方が優れてるわけだし。
0560nobodyさん
2006/06/08(木) 04:06:30ID:???Javaこわいです（＞＜）
0561nobodyさん
2006/06/08(木) 05:12:23ID:???0565nobodyさん
2006/06/08(木) 13:41:54ID:???どんなｼｮﾎﾞ鯖だよwwww
PHPで富豪的にｷﾒるのがﾊｲｶﾗなんだよwwww
0566nobodyさん
2006/06/08(木) 20:20:32ID:???0567nobodyさん
2006/06/08(木) 23:35:53ID:???それはそれでPHPらしくていいじゃない
0568nobodyさん
2006/06/09(金) 00:37:29ID:???0569nobodyさん
2006/06/09(金) 00:57:54ID:???0570nobodyさん
2006/06/09(金) 07:31:04ID:???APサーバで動くJavaに対して、
たかだかApacheのモジュールでしかないPHPは
比較になりません。
0571nobodyさん
2006/06/09(金) 07:38:36ID:???0572nobodyさん
2006/06/09(金) 08:07:40ID:???0575nobodyさん
2006/06/09(金) 10:29:11ID:???JavaやPHPやVBやC#から使用されるもの
言語とフレームワークをゴッチャにしてないか
0576nobodyさん
2006/06/09(金) 19:10:42ID:???Windowsサーバでしか動かないという縛りには興味なし。
もうPHPはJavaに寄生するかParrotに寄生するか、
もしくはZendがPHP用のAPサーバを作るのを待つしかないよ。
0577nobodyさん
2006/06/09(金) 20:05:34ID:???会社が合併する時に別 AP サーバで死ぬほど苦労するよ。
まぁ、Java の互換性問題は今にはじまった話ではないが。
0578nobodyさん
2006/06/09(金) 21:48:07ID:???Javaなら環境問題がない
PHPなら環境問題がない
全部嘘
確かに趣味でチョロチョロやる次元なら互換性を意識する事は少ない
しかし仕事で作るアプリとなると途端に細かい環境問題が多発する
そりゃもうWindowsもLinuxもUnixも変わらんですよ
互換性だの環境問題だのなんてのは今も昔も評価の対象にならない
0579nobodyさん
2006/06/09(金) 23:46:23ID:???だから、ある程度までなら互換性を語ってもいい気はする。
本職相手に言う台詞じゃないけど。
0582nobodyさん
2006/06/10(土) 12:35:05ID:???馬鹿はお前だPHP厨。
互換性を気にする必要がないならJavaでやりたい放題やりゃいいだろボケ。
PHPみたいな簡易言語なんか使ってるから脳が溶けるんだよアホが。
0583nobodyさん
2006/06/10(土) 12:50:47ID:???スレタイで持ち上げると必死になるのか?
0584nobodyさん
2006/06/11(日) 01:21:53ID:???互換性を気にする必要が無いならどの言語でもやりたい放題できる
互換性を気にする必要があるならJavaもPHPも使い物にならない
お前、脳味噌溶けて耳からこぼれてるんじゃないか？
0585nobodyさん
2006/06/11(日) 10:44:08ID:???0586nobodyさん
2006/06/11(日) 13:31:14ID:???＞互換性を気にする必要が無いならどの言語でもやりたい放題できる
＞互換性を気にする必要があるならJavaもPHPも使い物にならない
条件同じならAPサーバ擁するJavaが有利だなって言ってんだけど、
脳みそ溶けてなくなっちゃってるから分からない？
0587nobodyさん
2006/06/11(日) 16:10:49ID:???0589nobodyさん
2006/06/11(日) 19:15:53ID:???ほかにAPサーバが有利な点は？
0591nobodyさん
2006/06/11(日) 22:25:40ID:???負荷分散っていうか、好きなときにAPサーバを追加してシステムの処理量を増強させられる
スケーラビリティーとかはPHPはJavaに負けてるかなぁ。PHPでムリとは言わんが大変すぎ。
0592nobodyさん
2006/06/11(日) 22:27:57ID:???Javaと同じことが出来ないのは当然じゃないか？
0593nobodyさん
2006/06/11(日) 22:57:34ID:???前提でならまぁ意味はあると思うよ。
0594nobodyさん
2006/06/11(日) 23:12:17ID:???「PHP コネクションプーリング」でぐぐれ
それからJavaでプーリングしやすいのは、Servletだと１プロセスで処理を行うから。
Apache+PHPだとプロセスが複数作成され、そのプロセスごとにコネクションが必要となるから
プーリングされてないようにみえるけど、FastCGIのように１プロセスを使い回すようにすると
プーリングされる。
でもこの方法は共有サーバでは使いにくいから、ほとんど使われない。
逆にJavaは１台のサーバで百人が共有するという使い方ができない。
負荷分散は、poundつかうかApache2ならmod_proxy_balancerを使う。APサーバがないとできないことじゃないし、
APサーバの利点として強調するほどのことでもない。
0595nobodyさん
2006/06/11(日) 23:14:49ID:???PHPではたぶんできない。
0596nobodyさん
2006/06/11(日) 23:20:32ID:???イメージと違ってちょっと意外だった。
0597nobodyさん
2006/06/11(日) 23:23:30ID:???不可能とは言わないけどさ。
それから、FastCGIって1プロセス内だけで処理はしてないよね?
要はプロセスを複数起動してリクエストに待機するだけだからコネクションプーリングに関しては
mod_phpと基本的に変わらん気が。
0598nobodyさん
2006/06/12(月) 00:39:32ID:???0599nobodyさん
2006/06/12(月) 16:17:44ID:???お前は負荷分散がどういうものか理解しているのか？
鯖を複数置いてリクエストを分散すればそれでOKだと思っていないか？
0600nobodyさん
2006/06/12(月) 18:18:34ID:???Javaの利点だけを取り出して「PHPは糞」って言うのはバカ
PHPの利点だけを取り出して「Javaは糞」って言うのはアホ
0601nobodyさん
2006/06/13(火) 00:13:59ID:???それでOKじゃないの？
セッションを別鯖に引き継ぐとかの話が出てくると
耐障害性とか可用性とかの話だからまた別物だろ。
トランザクションとかの管理はDB側に持たせないと
どの道PHPでは使い物にならないから、
アプリ鯖は簡単に増やせそうに思うのだが。
0602nobodyさん
2006/06/13(火) 00:19:44ID:???>mod_phpと基本的に変わらん気が。
なんでやねん。
mod_phpはApacheの設定(max_clientsとか)に左右される。
apacheプロセスの寿命は結構短い。
FastCGIだとApacheとは無関係にプロセス数や寿命を設定できる。
プロセス数を少なく、寿命を長くすればそれでOK。
Javaのサーバは１プロセスマルチスレッドだから有利なのは確かだけど、PHPはPHP以外のソリューションと
組み合わせて利用できるから、Java屋が思ってるほど悪くない。
0604nobodyさん
2006/06/13(火) 00:33:49ID:???0605nobodyさん
2006/06/13(火) 00:58:32ID:???レガシーな負荷分散はそのイメージだよな
ハードウェアのロードバランサって言えばそれだし
だからそれはそれであり
Javaの各種フレームワークやASP.NETの負荷分散が実現するものには更に上のものがある
リクエストとレスポンスを分けるとか、各層のロジックの中で負荷の大きなプロセスだけを分散するとか、複数ページに渡るトランザクションを負荷分散しても一元的に管理できるとか、、、
mod_phpじゃ無理な高次元の負荷分散ができるわけで
0606nobodyさん
2006/06/13(火) 06:43:04ID:???0607nobodyさん
2006/06/13(火) 09:32:57ID:???です。だから Yahoo! や Wikipedia のような
超規模アクセス・サイトでは Java ではなく PHP を使います。
スケーリングが簡単。
0608601
2006/06/13(火) 09:33:21ID:???そんなのできるのか。Javaで食ってるのに知らなかった。
ってかEJBの事か。そんな大きな案件した事無い。
>>606
Poundでは>>605の言ってる不可分散は実現できないような気がするんだが。
みたところロードバランサ+SSLアクセラレーターのソフトウェア版じゃないのか？
0609nobodyさん
2006/06/13(火) 09:59:57ID:???こんな簡単なことも分からない方がいらっしゃるようですね。
嘆かわしいです（＞＜）
0610nobodyさん
2006/06/13(火) 10:01:41ID:???違う
分散したい負荷の種類が違うから
あそこは単純なリクエスト/レスポンスの負荷分散が目的だから、単純な処理機構を持つperlやphpをロードバランサで分散する手法を取っている
データコミットの分散も複雑ではないためにデータ層で受け止められるし
こういう目的では確かにphpやperlの方が楽
いわゆるEnterpriseな負荷分散は高負荷の処理を並列処理するのが目的だから、phpやperlとロードバランサでは目的が達成できない（実はできなくはないが面倒
こういう場合はフレームワークやAPサーバ/OSのレベルでサポートされるJavaや.NETの方が楽
適材適所
数スレ前から出てる当たり前の結論だがな
0611nobodyさん
2006/06/13(火) 10:06:14ID:???WebProgは最終出力がhttpなんだから、どんな処理系を使っても構築できないサイトはない
しかし、サーバ側処理の現実的な実装という意味では各処理系それぞれのadvantageがある
全てのサーバの処理能力が最速スパコンを超えるような爆速で、ネットワークもそのI/Oに負けない爆速なら負荷分散もへったくれもなく同期を取っても一瞬で処理が完了するだろうが、そうはいかないから色々な手法が存在する
WebProgは表側であるクライアント側なんて大した問題じゃなくて、裏側であるサーバ側が問題なんだよ
0612nobodyさん
2006/06/13(火) 11:17:59ID:???けどさ、現実的にはアイドルタイムが長いプロセスがしょっちゅう殺されたり、
余りのプロセスが足りなくなったから新しいプロセスを起動したりするよ。
0613nobodyさん
2006/06/13(火) 12:10:46ID:???PHPを貶めたいだけの書き込み乙。
0614nobodyさん
2006/06/13(火) 12:25:29ID:???現実的には一度立ち上げたfcgiプロセスをずっと使いまわす設定はありえないよ。
そうすると、最高負荷時を見込んでfcgiプロセスをあらかじめ用意することに
なるけど、最高負荷のときのメモリ負荷をずっと維持しつづけるということになるわけで、
これはあんまりといえばあんまりな設定だと思うけど...
おれ、プロパーなPHPerだよ。別に貶す意図はないよ。
0615nobodyさん
2006/06/13(火) 20:56:00ID:???>最高負荷のときのメモリ負荷をずっと維持しつづけるということになるわけで
ここがよくわからん。
最高負荷を見越して設定するのはよしとして、その最高負荷がなんでずっと維持されるん？
0616nobodyさん
2006/06/13(火) 22:23:19ID:???ごめん。メモリ負荷もそうなんだけど、
大量にプロセスを立ち上げた場合、プロセス間でコネクションを共有できないPHPだと
プロセスごとにコネクションを確保するから、あんまり接続数を節約できないなってことが言いたかった。
メモリ負荷は多分1プロセスごとにrssで4-5M程度だからまぁなんとかなるか。
まぁ、webサーバのプロセスのも同じくらいのメモリがいるけど、これは他のホストに追い出せるし。
ていうか、大量にプロセスを立ち上げた場合mod_phpとコネクションプーリングの点で
変わらないよね? Apacheもインスタンスの寿命を長く設定することはできるし、そもそも
なんで >>594 がFCGIだとコネクションプーリングの点で違いが出ると主張しているのかが
俺もよくわからないんだけど。
0617nobodyさん
2006/06/14(水) 01:57:57ID:???0618nobodyさん
2006/06/14(水) 14:36:43ID:???それでも Java よりも遥かに少ないメモリで PHP は動くのだけど。
0619nobodyさん
2006/06/14(水) 14:58:18ID:???どえらいものが上がってきました
SQLエスケープはナシ、
HTMLエスケープもナシ、
拡張子incも平気で使う…
これはPHP技術者の平均ですか？
それとも私がはずれを引いたのでしょうか…？
0620nobodyさん
2006/06/14(水) 16:47:55ID:???0622nobodyさん
2006/06/14(水) 17:35:00ID:???個人だったらそういうオープンなとこで募集かけるのは愚の骨頂
ツテやコネをつたって確実な人だけを選べ
会社だったらそういうオープンなとこで仕事を集めてるとこに頼むのは愚の骨頂
ツテやコネをつたって確実な会社だけを選べ
要は、海のものとも山のものとも知れないとこに頼むことが愚の骨頂なのだ
どうしても頼みたいのであれば、厳密なコーディングルールを提示すべき。
0623nobodyさん
2006/06/14(水) 19:56:23ID:???というか無料でもそんなのめったにお目にかかれない欠陥品なので詐欺だね。
0625nobodyさん
2006/06/14(水) 20:05:08ID:???作ったんじゃないかな。
受注が主な会社で技術力あって単価高い人はPHPやらせてもらえないんじゃないかな。
0626nobodyさん
2006/06/14(水) 20:59:02ID:???それをJava技術者の平均と聞けばいいの？
つか、Java案件でひどくないシステムを聞きたい。
0627nobodyさん
2006/06/14(水) 21:59:46ID:???Sunの営業に聞けば教えてくれるよ
Javaに限らず開発のお手本になるような事例ばかり
ただ、億単位の案件ばかりだけど
0628nobodyさん
2006/06/14(水) 22:15:21ID:???0629nobodyさん
2006/06/14(水) 22:16:04ID:???0630nobodyさん
2006/06/14(水) 22:16:55ID:???0631nobodyさん
2006/06/15(木) 01:24:00ID:???30万じゃなあ・・・アプリ開発をなめた値段だな。
おまえが>>619のような判断できるなら、なぜ発注するまえに相手の実力を確かめなかったんだ？それが不思議。
0633nobodyさん
2006/06/15(木) 08:09:35ID:???難しいかどうかいうまえに、やってみたのかよ。
やりもしない、自分で確かめる努力もしない、それで文句ばっかりつける。しかも安値でしか金出さない。
おまえ何様？
ああ、お客様か。
0634nobodyさん
2006/06/15(木) 08:13:28ID:???0635nobodyさん
2006/06/15(木) 08:56:16ID:???それすらせずに飯の種にしてる業者ｽｺﾞｽ
0636nobodyさん
2006/06/15(木) 10:29:16ID:???PHPerが良く言うじゃねーか
P H P は 何 で も 作 れ る 自 由 に 作 れ る
ってな
フリィダムに“基礎”も“常識”へったくれもねーだろーがｗｗｗｗｗ
>>619が自由なPHPerを縛れなかったのが悪いだけだYo!
0637nobodyさん
2006/06/15(木) 10:56:51ID:???0638nobodyさん
2006/06/15(木) 11:14:46ID:???0639nobodyさん
2006/06/15(木) 11:40:35ID:???とは言え要求定義に盛り込むべきだろう。
0640nobodyさん
2006/06/15(木) 15:53:11ID:???>>>615
>大量にプロセスを立ち上げた場合、プロセス間でコネクションを共有できないPHPだと
Javaだとプロセス間でコネクションを共有できるのか？スレッド間ならわかるが。
もしかしたらNIOあたり使えばできるかもしれんが、ふつうはやらんだろ。
>プロセスごとにコネクションを確保するから、あんまり接続数を節約できないなってことが言いたかった。
だからApacheとプロセスを分離できるFastCGIが有利と書いたんだが。
>ていうか、大量にプロセスを立ち上げた場合mod_phpとコネクションプーリングの点で
>変わらないよね?
だから大量のプロセスを発生させないためにFastCGIを使うんじゃないか。FastCGIを使ってるのになんで大量のプロセスを発生させる必要がある。
>Apacheもインスタンスの寿命を長く設定することはできるし、
だからFastCGIだとApacheとは別にプロセスの数と寿命を設定できると書いただろ。
MAX_CLIENTSが256だとしたら、Apacheプロセスは最大256個のプロセスが起動するけど、
FastCGIはそれとは無関係にプロセス数を設定できるんだから、これをごく少ない数にしておけば
DBコネクション数が爆発することはない。
>そもそも
>なんで >>594 がFCGIだとコネクションプーリングの点で違いが出ると主張しているのかが
>俺もよくわからないんだけど。
594に書いた通り。PHPのプロセスを使い回すんだから、プーリングされるようなもんじゃん。
おれはおまえが煽ってる理由がわからんよ。さようなら。
0641nobodyさん
2006/06/15(木) 16:10:28ID:???別に>>616が煽ってるようには見えんが。むしろお前さんのFastCGIマンセーのほうが鼻につく。
よくは知らんが、デメリットもあるわけでしょ？でなきゃ必ず使われるか、いっそ取り込まれるだろうし。
0642nobodyさん
2006/06/15(木) 17:37:53ID:???まぁそんなに怒らずにカルシウム摂って。
ああ、ごめんごめん。APサーバとの比較だから全ページに動的コンテンツがある前提だと思ってた。
だからApacheプロセス数 == FCGIプロセス数だと思ったのよ。
でも全ページに認証チェックとか、なにかしらの動的コンテンツが含まれる場合は
たとえそのページでDBに接続しないとしてもFCGIプロセスはHTTPコネクションの数だけ
必要になるわけで、そういう場合はmod_phpと変わらないよね。むしろリソースの無駄?
FCGIがはやってない理由はたぶん最近まで依存してたlibfcgiの開発が滞りがちだったせいじゃないかな。
0643nobodyさん
2006/06/16(金) 00:44:23ID:Ujb4g0OW0644nobodyさん
2006/06/16(金) 08:19:48ID:???0645619
2006/06/16(金) 18:26:38ID:???筋が悪いというか、設計自体が気持ち悪いので…
自分的にはちょっと高い勉強代でした
いい外注探すの難しいです（＞＜）
0646nobodyさん
2006/06/16(金) 18:29:47ID:???自社で育てろ
0647nobodyさん
2006/06/16(金) 18:40:10ID:???>よくは知らんが、デメリットもあるわけでしょ？でなきゃ必ず使われるか、いっそ取り込まれるだろうし。
デメリットがないとは誰も書いてないよ。脳内補完乙。
デメリットがなければ必ず使われるって、おまえの住んでる世界は平和だな。
>>642
>たとえそのページでDBに接続しないとしてもFCGIプロセスはHTTPコネクションの数だけ
>必要になるわけで、
なんで？１つのプロセスで複数のリクエストをさばくんだから、プロセス数＝HTTPコネクション数になるわけがない。
0649nobodyさん
2006/06/16(金) 20:57:17ID:???647は会社で誰も相手にしてくれないから
自分の意見が言えなくていらいらしてるんだろう。
そっとしておけ。
0650nobodyさん
2006/06/16(金) 21:06:51ID:???それより HTTPコネクション数＝FastCGIプロセス数 の理由を説明してくれ。
じゃないと議論が噛みあわん。
0651nobodyさん
2006/06/16(金) 21:09:10ID:???0652nobodyさん
2006/06/16(金) 21:11:05ID:???クライアントを待たせては本末転倒では? FCGIプロセスがApacheプロセスより少なければ
当然そうなるでしょ。
0653nobodyさん
2006/06/16(金) 22:19:48ID:???プロセスが立ち上がりすぎると、
プロセスの立ち上げや切り替えのオーバーヘッドが大きくなりすぎて
にっちもさっちも行かなくなるのは分かるよね？
ロードアベレージが30とか40とかいう泣ける状況の事ね。
そーゆー時には、やっぱ無停止プロセスがキューに
たまったリクエストをひたすら捌くのが効率いいのよ。
クライアントを待たせてしまうのは、望ましくないが仕方が無い事。
問題は、本質的な処理以上に無駄な処理が走ってしまう事で、
それを取り除くひとつの解がFCGIって言うだけの話だ。
■ このスレッドは過去ログ倉庫に格納されています