幅広い分野の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
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って言うだけの話だ。
0655nobodyさん
2006/06/16(金) 22:35:30ID:???なぜそういう結論に到達するのかがわからないぞ？
俺が言ってるのは
【サービス停止】という絶望的な状況よりも
【サービス遅延】という「最低でも処理は行われる」状況のほうが
良いだろうという話なんだが。
つまり100の処理能力があるサーバーで、最悪の状況のときに
50の実処理と50の本質的でない処理が行われる構造(mod_php)
80の実処理と20の本質的でない処理が行われる構造(FCGI)
と、どっちを選択するかって言う話なんだが…。
ちなみに数値は適当な。
もちろん、遅延が絶対に許されない状況なら、
それと含めてハードウェアの多重化も必要になるだろうが。
0656nobodyさん
2006/06/16(金) 22:40:50ID:???それは...なんだか負け惜しみっぽくね?
いきなりそんな特殊な状況をもちだすのは詭弁くさくないか?
まぁ、それなりにありえない状況ではないけど、ロードアベレージが30あるなら
FCGI導入よりより先にやることがあらぁね。
0657nobodyさん
2006/06/16(金) 22:45:51ID:???そうさねｗ
けど、プロセス立ち上げるコストが、無停止プロセスに処理させるよりも重いのは事実だよ。
ページの立ち上がりはFCGIのほうが早い。
0658nobodyさん
2006/06/16(金) 22:58:02ID:???0659nobodyさん
2006/06/16(金) 22:59:53ID:???0660nobodyさん
2006/06/16(金) 23:02:17ID:???ちなみに俺は >>653,>>655,>>657 なんだが
FCGIなんて一度も使ったことねぇし、mod_phpも使った事がないwww
中途半端なUNIXの知識で、一般論をぶち上げただけですのであしからず。
0661nobodyさん
2006/06/16(金) 23:10:19ID:???0662nobodyさん
2006/06/17(土) 01:21:38ID:2dWsqYjlAPサーバ使って高性能Webアプリを簡単に作った方がいいんじゃねーの？
0663nobodyさん
2006/06/17(土) 01:52:40ID:???相互に動作保証取られていなかったりそれぞれの求めるバージョンに限界があったりで、ちょっと高度なことしようとすると下手なパッケージソフト（つかM$製品）より自由度が低い。
Javaはかなり大きなレベルでパッケージになっているためPHPのような悩みが少ない。確かにAPサーバが大きく重いという批判はあるが、今回の様な案件ではそれが有利に働く。
適材適所とは言うければ、会社にある100以上のPHP/Java案件の技術評価レポートを見る限りは、PHPは「小物」「玩具」のレベルを超える期待はできないと感じた。
0664nobodyさん
2006/06/17(土) 03:12:30ID:???0665nobodyさん
2006/06/17(土) 03:16:07ID:???また、このiの上の最後の糸が大多数の人々がPHPに中へ興味を感じさせた
という強いを抱くことを読んだ後に、開発は賛成論ネーム空間です。
私たちが最後のもののうちの1つを失わせたネーム空間の撤去によって、
私たちは完全に即座の企業である必要があります。説明させてください。
全面的に視界を支援するためにオブジェクト・モデルを変更しさらに
抽象的な方法およびインターフェースを持っていることによって、私たちは、
UMLツールを備えたPHPコードを設計することを可能にする言語水準に達
しました。不運にも、今、ネーム空間は見当たりません、私たちは専用グル
ープ化するメカニズムを欠きます。そのような配合は、パッケージ代案(それが
抜けている言語で)としてしばしば使用されます。、そしてその結果責任組織
および組織しているハイ・レベル・ソフトウェア・アブストラクト際に役割を果たす。
その問題に戻ること。削除されるまで、それらがそうだったように、ネーム空間に関
する2つの大問題があります。最初にそこに、今ちょうど作動しない輸入に関する
問題です。ここで、iは、nooneが注意したと言うに違いありません、に関して、まだ、単に、ので
0666nobodyさん
2006/06/17(土) 03:20:09ID:???にまだ注意したと言うに違いありません。これは、今のところそれを落とすことが最良の
解決だっただろうと言いました。さらに、PHPの後の時/バージョンに輸入の働くバージ
ョンを加えることは、今問題だったでしょう。第2の問題は支援です、の「:」3のオペレー
ターとのもめごとを引き起こしたネーム空間で。このiに関して、そうは実際に単に言うこ
とができる、かつて理解されたnoone、なぜそれは、それをインプリメントした奴に加えて
必要でしたか。西洋ナシ開発者さえ、彼らがその必要を持っていると言いませんでした。
それら(iが誤解していない場合)については、
それがonyでした、1つの、goodieを持つのによい私のために、単に1つの可能な解決への
このleeds:輸入なしでネーム空間を中へ戻す「そして:」支援してください。現在のエンジン
の中で実際の問題を解決した後。その後、私たちは作動する輸入を加えることができま
した。「それが壊れていないので、輸入は「固定することができない」」と既に言われていた
とともに。i、可能な解決を示す必要を感じます。第一に、i、それが壊れていたので、実
際に私たちが持っていた輸入に興味を持ちません。
0667nobodyさん
2006/06/17(土) 03:22:27ID:???にとって、これは、輸入ステートメントが活発なネーム空間へ選択されたシンボル
を輸入するべきであることを意味します。解決は輸入品用の専用ハッシュ・テーブ
ルを持ち、オリジナルの記号テーブルが要求されたシンボルを伝えない場合に限り
それらを使用することであると思うので、私は、これが何でも上書きするとは予想し
ません。この解決が扱うことができないものはすべてソフトウェア設計によるエラーで
す。既に目標ハッシュ・テーブル中のシンボルに邪魔をするシンボルを特に輸入する
ことは、そのような悪い設計を防ぐためにエラーに帰着するかもしれません。さらに、
多数の輸入ステートメントが矛盾に帰着する場合、エラーを放射するのは簡単です。
PHPが強いタイプされた語調ではないので、私は、言及された問題に加えて
実際のエラーを見ません。
0669nobodyさん
2006/06/17(土) 13:11:36ID:???>処理能力を上げるためにコネクションプーリングとかを導入するのに
>クライアントを待たせては本末転倒では? FCGIプロセスがApacheプロセスより少なければ
>当然そうなるでしょ。
ならないよ。
１つのFCGIプロセスで複数のリクエストをさばくから、Apacheプロセスが多かろうが関係ない。
もしこれでクライアントを待たせることになるのなら、Apache+Tomcatの組み合わせでも同じことになる。
もしmod_perlと比較していってるのであれば、mod_perlの実行時間がFCGIに移るだけ。Apacheプロセス数は関係ない。
FCGIプロセスがApacheプロセスより少なければなぜクライアントを待たせることになるのか、説明求む。
おまえにとっては「当然そうなる」のかもしれんが、おれにはわからん。
0670nobodyさん
2006/06/17(土) 13:25:02ID:???>>663
>PHPに限らないが、OSS系はオープンだから拡張性があるとか他のツールでどんな機能も補えるとか言うけど、
>相互に動作保証取られていなかったりそれぞれの求めるバージョンに限界があったりで、ちょっと高度なことしようとすると下手なパッケージソフト（つかM$製品）より自由度が低い。
「自由度が低い」という表現以外は肯定できる。ソース読んでパッチ作ればいいから自由度は限りなく高いんだけど、
そんなことしなくて済むならそれにこしたことはない。
ただ、Javaの商用アプリケーションサーバを数個使ったけど、どれもJDKのバージョンとかOSのパッチとかすごく細かく指定してきて、
それ以外だとすぐにサポート対象外としやがる。
例えばApacheとアプリケーションサーバを組み合わせて使ってるんだけどApacheのセキュリティパッチ当てたら
「そのApacheのバージョンは弊社ではサポートしていませんのでサポート対象外となります。」
とかいわれた。
これも自由度が低いから、どっちもどっち。
0671nobodyさん
2006/06/17(土) 13:46:35ID:???ガンガングングンズイズイ上昇
0672nobodyさん
2006/06/17(土) 17:44:37ID:???そうなの?
たとえば、Apacheが2つのプロセスで同時に２つのコネクションをさばいていて、
そのどちらもがFCGIでの処理をしなきゃ行けない場合、FCGIプロセスが一個だけなら
どちらかのコネクションは待たされると思ってた。違うの?
0673nobodyさん
2006/06/17(土) 22:41:46ID:???お前らの職場はどーよ？
0674nobodyさん
2006/06/17(土) 23:21:23ID:???「PHPを外注したらまともに動く物が納入されるなんて
理屈で考えてありえないって分かってるでしょ？
なんでそーゆー事するんですか」
って本気で切れたのも原因かもなwww
0678nobodyさん
2006/06/18(日) 17:05:49ID:???×もう少し日本語を勉強しなPHP厨ｗ
△もう少し日本語を勉強しな、PHP厨ｗ
○その通りです。ありがとうございました。
0679nobodyさん
2006/06/18(日) 17:23:12ID:???うちではPHPに関しては何も変わっていない
引き合いも外注も売上も粗利も会社の利益全体に対する割合もここ数年30%前後で同じ
Javaはフレームワークを問わず一昨年あたりから若干下降線
ASP.NETが一昨年あたりから急上昇
perlはここ数年下がるばかりで保守中心だが小規模安定稼働が多いため移行は少ない
ASPはビジネスアプリが多いため殆どASP.NETや他の環境へ移行し保守も数件を残すのみ
ColdFusionはFlash関係で若干あるがほぼFLEXに移行
その他いくつか特殊な言語や環境があるが全部で数件程度なので略
0680nobodyさん
2006/06/18(日) 21:50:56ID:???■ このスレッドは過去ログ倉庫に格納されています