Java は PHP よりも消費電力が少ないという噂を耳にしました。私は現在、ほとんどのアプリを PHP に基づいている会社で働いています。消費電力が問題になったことは一度もありませんが、問題になる可能性がある大規模なプロジェクトに取り組んでいます. 私たちは Web 開発用の PHP を愛用しており、そのような噂がどのように広まる可能性があるのか、またそれが本当なのかどうか疑問に思っています。
私が聞いた例では、Facebook がまさにその理由で Java に切り替えているというものでした (ただし、Google でこのようなものを見つけることはできません)。
私の顧客が私にこの質問をしているので、それが本当なら証拠が欲しい.
コンピュータは、Java を実行しているのか PHP を実行しているのかを特に気にしません。消費電力はほぼ同じです。次に、問題はパフォーマンスの問題になります。1 つのサーバーでより多くの要求を処理できれば、必要なサーバーが少なくなり、消費電力も少なくなります。あるいは、Web スケール アプリケーションを実行していない場合は、リクエストをより迅速に処理し、アイドル状態により多くの時間を費やすことで、消費電力を削減します。
純粋な Java と純粋な PHP を考えると、静的に型付けされた JIT 言語としての Java の方がもちろん高速です。問題は、チームメンバーと利用可能な開発努力を考慮して、どちらをより速く作成できるかということです.
私の見解では、最善の方法は、言語を混在させ、Terracotta などの既存の Java ベースのインフラストラクチャ ツールを使用してパフォーマンスの重要な部分を構築し、より機敏に複雑なものを構築することですが、それほど重いビジネス ロジックやプレゼンテーション ロジックは構築しないことです。
私はそれが言語だけの問題であることを本当に疑っています。
問題のプラットフォームには非常に多くのばらつきがあり、一般的な比較は意味がありません。いくつかの変動点を挙げます。
非常に多くの変数を有用なメトリックに分離できるとは思えません。同じハードウェアを使用して (すべてのプラットフォームの選択に注意して) 同等のアプリケーションを 2 つ選び、それらを比較できるのは、せいぜい 2 つです。次に、最悪のものを改善して、より良いものを上回ります。適切な測定は、1 時間あたりのワット数と 1 秒あたりのリクエスト数の両方になると思います。
ただし、 Ants の回答(彼に賛成)に記載されていることは重要な点です。より少ないハードウェアで同じ量の要求を処理できるため、十分な需要がある場合、パフォーマンスの高いプラットフォームは常に電力効率が高くなります。
しかし、どのプラットフォームのパフォーマンスが優れているかは、単に言語に依存するだけでなく、上記の事柄 (およびその他) にも依存します。
Google 検索を行うまでは、この質問に驚きました。思いもよらなかった、深刻な問題です。
今考えると、電気代は誰が負担するかという問題になると思います。Sun の Java 戦略は、サーバーを販売することでした。バック エンドはビッグ アイアン、フロント エンドはシン クライアントです。
おそらく、Flex のようなテクノロジーにより、より多くの作業がクライアントに戻され、電気料金のより多くの割合がクライアントに残されます。
しかし、エネルギー使用による言語のランキングを見ると驚かれることでしょう。
非常に興味深い質問です。私はそれを投票しています。
なんて魅力的な問題でしょう。多数の言語でアプリケーションを作成し、それらを同一のハードウェアにデプロイして、消費電力を測定するのは興味深いことではないでしょうか? ぜひ見てみたいです。
本当に夢中になっているなら、アプリの各部分でメモリと CPU が消費されている場所を示すだけでなく、最もエネルギーが使用されている場所も示すパフォーマンス監視ツールはどうでしょうか?
今、この質問にもう一度投票できたらいいのにと思います。
ここでの多くの比較質問と同様に、それが正しいかどうかを実際に判断するには、おそらくベンチマークを考え出す必要があります。
lesswatts.org には、アプリケーションの電源管理に関する情報と、Linux システムの電力消費に関するその他の側面がいくつかあります。補足として、彼らはPHPを使用しているように見えるので、それ自体に価値があるかもしれません:)
彼らは、PowerTOPを使用して、どのアプリケーションが最大の電力消費を引き起こしているかを判断する必要があることを繰り返しており、少なくともアイドル状態からのウェイクアップをチェックしていることをスクリーンショットから確認できます。
ほとんどの場合、Web サーバーはアイドル状態で、非常に短い時間「サービスを提供」し、次にサービスを提供する接続を待機する状態に戻ります。その点で、PHP はプロセス全体にほとんど貢献しません。提供する部分だけです。したがって、実際のベンチマークは、特定の Java ベースの Web サーバーと、同様のページを提供する Apache/PHP との比較だったのではないでしょうか。その場合、実際には PHP と Java を公平に比較することはできません。実際のページを提供していると見なされる 2 つのどちらも、通常、一度に数ミリ秒しかアクティブではありません。接続を選択またはポーリングしている実際のWebサーバーが、電力を浪費していると思います。
エネルギー消費とは、ワットの消費電力を意味しますか?
100% 確信はありませんが、これが事実であるとしても、これはプログラムの実行時間の 0.01% で実行されるコードの一部を最適化することに似ていると思います。
切り替えによって引き起こされる問題 (生産/リリース プラットフォームの変更、学習曲線の時間の損失、新しいビジネス ソフトウェアのコストなど) は、かなり劇的なものになります。真剣で企業固有のビジネス分析タスクとそれに対応する結果を除いて、そのような重要な決定が行われることはありません.
ただし、これは興味深い議論になるはずです。
より効率的なコードは、電力を含むより少ないリソースを消費します。一般に、Java はより高速で効率的な実装を備えているため、他のすべての要因が一定であれば、Java はおそらくサーバー上で実行されるエネルギーの消費量が少なくなります。
しかし、他のすべての要因は一定ではありません。PHP を使用するか Java を使用するかの決定に基づいて、何が変わるかわかりません。たとえば、Java は開発に時間がかかります。これは、Java プログラマーがコンピューターを長時間オンにしておくことを意味し、それによる電力使用量がサーバーの節約を上回る可能性があります。
あなたがGoogle、Amazon、または数千のサーバーから毎日文字通り数十億のリクエストを処理する他の会社である場合、私はこれについて心配します. そうしないと、エネルギー消費について肯定的な主張を行うほど規模が大きくないため、関連するすべての要因を含めることは不可能であるため、生産性を高めるのと同じように、あなたが行う決定は非生産的である可能性があります.
関連する例として、デスクトップの背景を黒に設定すると電力を節約できるという噂が数か月前に広まりました。黒 == 光がないと考えていたので、あまり光を使用していませんでした。Google（この種の研究を生産的にするのに十分な電力使用量を持つ数少ない企業の1つ）は、いくつかの実験を行い、いくつかの研究を行い、LCDスクリーンは何があっても白色光を生成し、ピクセルに2番目の電流を通すことでそれをフィルタリングすることを発見しました.別の方法で。したがって、ピクセルを黒に設定することで、フィルターを最大に設定し、実際には可能な限り多くのエネルギーを使用します. 最も省エネなデスクトップの背景 (少なくとも LCD 画面では) は白です。バックグラウンド。しかし、白い背景は目に悪いので、デスクトップの背景を白に設定する人は少なく、背景を黒にすると節電になるという噂はいまだに根強く残っています。
つまり、簡単に言えば、これについて心配することは、良いことよりも害を及ぼす可能性が高いということです。
多くの大企業が、データセンターのリソースに対する需要の増加に苦労していることを理解しています。これらには、床面積と消費電力の両方が含まれます。したがって、アプリケーションの合理化、低リソース消費を支持する戦略が採用されていると私は十分に信じています。
Java、PHP、またはその他の実装テクノロジの使用が消費電力の決定要因になる可能性が高いかどうかは、私には明らかではありません。
たとえば、Interpreted Basic、Java、および C でリソース消費を最適化する特定の関数を実装した場合、ほとんどの実行リソースが必要になると予想されます。
確固たる証拠を確認する必要がありますが、純粋なインタープリター言語は Java よりも多くを消費する可能性があり、JIT などを使用した場合でも、C よりも多くを消費する可能性があると私は信じることができました。
ここで、Java よりも C での開発に労力がかかり、Basic よりも Java での開発に多くの労力が費やされたと考えてみてください (純粋に仮説として、これが事実であると言っているわけではありません)。そのリソース消費に対して、開発と保守の労力をどのようにトレードオフしますか?
本当にトリッキーです。誰かが消費電力を理由に Java のみに移行していると言ったら、もっと知りたいと思います。その際の費用はいくらですか？損益分岐点はどこにありましたか？[ところで - 私はほとんど Java だけで仕事をしています。「私たちは勝った、私たちの能力がどれだけ低いかを見てください!」と言えるようになりたいと思っています。]
これは、ベンチマークについて述べたように、比較のためのルールを設定しない限り、答えるのが難しい質問です。
たとえば、Java3D のファーストパーソン シューティング ゲームを PHP の Web ページと比較するのは不公平です。Java が負けるからです。
Java フレームワークを見る場合、Tomcat + JDK 6 + JSP Apache + PHP Scala + Lift フレームワークの 3 つを比較することをお勧めします。
Scala は Java バイトコードにコンパイルされるので含めました。
どちらが勝者になるかはわかりません。私は Scala に賭けますが、同じアプリケーションが実装されていることを確認してから、電力使用量を比較してください。
apache と PHP は Java よりもメモリ使用量が少ないように見えるため、おそらく PHP が勝つでしょうが、Scala と PHP を実際に比較することはできません。
私にとって大きな未知数は、同じ Java コードを呼び出すと、既にネイティブ コードに変換されているため、より高速に実行されることですが、Java を利用するには JSP をプリコンパイルする必要があることです。
しかし、Web2.0 テクノロジーを使用すると状況が変わります。大部分の負荷がブラウザにかかるため、大規模な JavaScript アプリケーションを使用している場合は、サーバー呼び出しを行うだけで、サーバーの電力使用量が削減されます。レンダリング作業はブラウザに渡されます。その時点で、Java 用の JIT が有効になるはずであり、Java または Scala のほうが電力使用量が少ないと予想されます。
大きなテストである IMO は、マシンのサイズを縮小した場合と同じパフォーマンスが得られるかどうかを確認することです。したがって、負荷分散された PHP または Java 用の 3 台のコンピューターが必要な場合、1 台の Scala マシンで同じパフォーマンスであれば、scala (Lift を使用) が勝ちます。
電力効率は、それ自体が 1 つの分野です。通常、パフォーマンスを測定することが最善の方法です (同じハードウェアを前提として)。異なるハードウェアが比較されている場合、それはまったく別の球技です。
したがって、同じハードウェアが与えられた場合、ソフトウェア スタックが別のソフトウェア スタックよりも優れたパフォーマンスを発揮できる場合、パフォーマンスの優れたソフトウェア スタックは、他のソフトウェア スタックよりも「要求ごと」に消費する電力が少ないことを意味します。パフォーマンスの違いが十分に大きく、サーバーをより少ない数に統合できる場合、それはさらに大きな勝利です!
他にも多くの考慮事項があります。
データセンター サーバーは、冷却されたデータセンターに収容されていると考えてください。サーバーは熱を発生し、ハードウェアを保護するために熱を除去する必要があります。A/C ユニットの粒度は無限ではありません。それらの効率は通常、ボリュームに付随します。したがって、サーバーの数を 2 から 1 に減らすと、1 台のサーバーの消費電力を節約できたかもしれませんが、おそらく冷却コストはあまり節約できませんでした。しかし、アーキテクチャを変更することで 100 台のサーバーを削減できるとしたら、それは大きな節約になります。
ハードウェアと周辺機器 最も電力効率の高い SW スタックを使用し、それを Pentium 4 サーバーで実行する = 愚かさ ;) 最もエネルギー効率の高いソフトウェアは、非効率的なハードウェアを補うことはできません。ここでの興味深い教訓の 1 つは、「電力についてはハードウェア担当者に任せてください」です。アプリケーションを市場に投入することを心配しています。アプリケーションが収益を生み出すことができる場合、いつでも最新の 16 コア Core 5 ヘキサデカ CPU を購入して、即座にエネルギー効率を得ることができます ;)
仮想化 アプリケーションのボリュームが少ない場合、マルチコア システムで実行される仮想マシンに統合することで、最もエネルギー効率の高い SW スタックでアプリケーションを書き直してスタンドアロン サーバーで実行するよりも多くのエネルギーを節約できます。
プログラマーの時間 「最も電力効率の良い」ソフトウェア スタックに精通したプログラマーが必要です。それが適切なツールであるかどうかを検討する必要があります。プログラマーはコンピューターを使用してソフトウェアを開発しますが、開発に時間がかかるほど (不適切なツールに制約されている場合)、より多くの電力が消費されます。言うまでもなく、あなたは彼らにもっと多くの時間を支払わなければなりません。ここでのコストは桁違いに高いため、これは通常、エネルギー消費に関する懸念を上書きします。
あなたの唯一の懸念がエネルギー効率である場合は、はい、バッグ内のすべてのツールを使用してそこに到達してください. しかし、ほとんどの場合、それは全体的なスキームの 1 つの小さな変数にすぎず、コストも最小になります。
これは、どの言語が最もパフォーマンスが良いかという問題と同じです。さて、ほとんどのプログラマーが接触するほぼすべてのプロジェクトについてです。システムをどのように作成するかは、使用されるテクノロジーよりもはるかに重要です (システムの仕様が適切である場合)。
パフォーマンスに関する言語の選択は、組み込みシステムと科学者にとって私見です。解決する問題に応じて言語を選択しますが、CPU の効率性についてはほとんどありません。
繰り返しになりますが、システムの効率性を決定するのは、システムをどのように設計して記述するかです。
この質問に関する多くの側面はすでにここで詳細に調査されていますが、少なくとももう1つ調べる必要があります。
典型的なPHPWebアプリケーションは、PHP実行環境（またはコンテキスト）が要求間で永続的ではないという理由だけで、ある要求から次の要求に多くの労力を複製します。
通常のJavaWebアプリケーションには、追加の手順やキャッシュの無効化なしで状態を直接保持する機能があるため、たとえば、PHPスタイルの重複SQLクエリを実行して、リクエストごとに同じ情報をフェッチする必要はありません。代わりに、Java Webアプリケーションは、現在の分析の複雑な情報をヒープ上のネイティブデータ構造に格納することがよくあります。このデータ構造には、ミリ秒単位ではなくナノ秒単位でアクセスされます。
プロセッサがこれらの基本的なデータアクセス機能を実行するために必要な作業が大幅に少なくなるため、この作業に必要な顧客価値の単位あたりの電力は少なくなります。
明らかに、現代のコンピューティング技術は以前よりもはるかに多くのリソースを使用しており、これは電力消費に直接関係しています。従来型のソケットを使用してネットワーク経由でバイナリ データを転送し、100Mhz プロセッサがそれを処理するようになると、データが XML テキストに変換され、http 経由で同じ Web サービス経由で渡されるソフトウェア スタックができました。ソケット、そしてまともなパフォーマンスを得るために、なぜRAMのスポッドを備えた3Ghzプロセッサが必要なのか疑問に思います:)
それが問題です。それについてできる唯一のことは、コードをより効率的にすることです。通常、これは低レベルの言語を使用し、汎用フレームワークやライブラリへの依存度を下げることを意味します。やむを得ない場合は、ソフトウェア スタックを階層化しようとしないでください。
現代のプログラミングはこれを好みません。プログラマーの生産性向上、安価なプログラマーの採用、常にコードのリエンジニアリング (つまり、コードの書き換え) が行われているため、コードは簡単に作成 (および場合によっては保守) する必要があります。結果として、最高の結果を得るには、これらの要因をトレードオフする必要があります。これを行う業界標準の方法は、用途に応じてシステムを単純に混合することです。
現在、究極のパフォーマンスは C/C++ コードであり、プログラマーの究極の生産性はスクリプト言語のようです。したがって、両方の理想的な最善の方法は、主要なビジネス ロジックを Python などのスクリプト言語で記述し、それを使用して C/C++ で記述された専用の「パワー ヘルパー」を呼び出すことです。より高いパフォーマンスが必要な場合は、基礎となる C/C++ でより多くのコードを記述できます。RAD の迅速な開発がさらに必要な場合は、スクリプト言語でさらに記述します。
OP に対する私のアドバイスは、Java で書き直すことではありません。全体的にはパフォーマンスが向上する可能性がありますが、コストがかかりすぎて、それだけの価値がない可能性があります。代わりに、アプリの集中的な部分を可能な限り効率的に書き直して、既存の PHP から呼び出します。次に、全体的なアーキテクチャを見て、非効率的なプロトコルとデータ構造への依存を減らします。たとえば、XML を JSON に置き換えると、同じ機能を利用できますが、データの解析と再フォーマットに必要なデータ サイズとリソースはごくわずかです。