コード実行の速度：ASP.NET-MVC vs PHP
これについて同僚との友好的な議論がありますが、私の個人的な意見では、ASP.NET-MVCでコンパイルされたWebアプリケーションは、PHPで作成される同じプロジェクトよりも効率的/高速に実行されます。私の友人は同意しません。
残念ながら、私は自分の議論をバックアップするために使用できる確かなデータを持っていません。 （彼もしません）
これに対して、私はグーグルに答えを求めて彼が間違っていることを証明する証拠を見つけようとしましたが、ほとんどの場合、議論はどのプラットフォームで開発するのが良いか、コスト、セキュリティ機能などに変わりました...このため議論私は本当にそれのどれも気にしません。
スタックオーバーフローコミュニティが、PHPで開発されたまったく同じWebサイトとMVCを使用してASP.NETで開発されたWebサイトの一般的な生の速度/効率についてどのように考えているのか知りたいのですが。
2つのテクノロジーのパフォーマンスを比較する実際のシナリオで、実用的な例はありますか？
（一部の人にとっては、これは非常に無関係で馬鹿げた議論かもしれませんが、それは議論であり、S.O。の素晴らしい人々の答えを聞きたいです）
それぞれのスタックの違いは同じことを異なる方法で行うことになり、比較の目的で同じことをする場合、あまり現実的なテストではないため、比較するのは難しいです。
私が気に入っているPHPは、すべてのリクエストで読み込まれ、解釈されて破棄される最も基本的な形式です。これに関しては、CGIと非常によく似ています（約15年前であることを考えると驚くことではありません）。
現在、パフォーマンスを改善するためにさまざまな最適化が行われています。最も顕著な例は、APCによるオペコードキャッシングです（APCがPHP 6の標準部分になり、そのようなオプションモジュールではなくなります）今です）。
ただし、PHPスクリプトは基本的に一時的なものです。セッション情報は（通常）ファイルベースであり、相互に排他的です（session_start（）は、session_commit（）またはスクリプトが終了するまで、同じユーザーセッションにアクセスする他のスクリプトをブロックします）が、ASP.NETではそうではありません。セッションデータは別として、ASP.NETのアプリケーションコンテキスト内に存在するオブジェクトを持つのはかなり簡単です（そして通常）（または、ASP.NETに似ているJava）。
これは重要な違いです。たとえば、PHP（mysql、mysqli、PDOなどを使用）のデータベースアクセスは一時的（永続的な接続にもかかわらず）です。一方、.Net/Javaはほとんど常に永続的な接続プールを使用し、この上に構築して作成しますORMフレームワークなど、特定の要求を超えるキャッシュ。
バイトコード解釈プラットフォームとして、ASP.NETは理論的には高速ですが、PHPができることの制限は非常に高く、ほとんどの人にとっては無関係です。たとえば、インターネットでアクセスした上位20サイトのうち4つはPHPです。開発の速度、堅牢性、環境の実行コストなどは、スケーリングを開始するとき、理論上の速度の違いよりもはるかに重要になる傾向があります。
.Netには、プリミティブ型、型安全性、およびコードをPHPで実行できる速度よりも高速にするこれらの種類があることに留意してください。多少不公平なテストを行いたい場合は、両方のプラットフォームで100万個のランダムな64ビット整数の配列をソートします。 ASP.NETは、プリミティブ型であり、PHPの連想配列よりも単純な配列の方が効率的であるため、ASP.NETを強制終了します（PHP内のすべての配列は最終的に連想配列です）。さらに、32ビットOS上のPHPは、ネイティブの64ビット整数を持たないため、そのために非常に苦労します。
また、ASP.NETはプリコンパイルされますが、PHPはオンザフライで解釈されるため（オペコードキャッシングを除く）、違いはありますが、PHPの柔軟性があります。 _この点で良いことです。サーバーをバウンスさせずにスクリプトを展開できるのは素晴らしいことです。ちょうどそれをドロップし、それが動作します。ブリリアント。しかし、最終的にはパフォーマンスが低下します。
最終的には、実際には無関係な詳細とは何かを議論していると思います。
ASP.NETはより高速に実行されます。ASP.NET開発はより高速です。高速なコンピューターを購入し、本格的なビジネスWebアプリケーションを実行する場合は楽しんでください
ASP.NETコードは、リリースモードでビルド、最適化、キャッシュなどされている場合、PHPと比較してはるかに高速に実行されます。ただし、Webサイト（Facebookなどの大規模なプレーヤーを除く）では、ページレンダリング時間のほとんどは重要ではありません。データベースへのアクセスとクエリ。
データベースの接続では、ASP.NETの方がはるかに優れています。asp.netでは、通常、オブジェクトクエリをSQLサーバーデータベースのストアドプロシージャに変換するLINQを使用します。また、データベースへの接続は永続的であり、1つのWebサイトに1つであるため、再接続する必要はありません。
それに比べて、PHPは、リクエスト間のSQLサーバー接続を保持できず、接続し、dbからデータを取得して破棄します。データベースの再接続は多くの場合、ページレンダリング時間の20〜30％です。
また、Webアプリケーションの設定全体がasp.netのメモリに保持される各リクエストでphpに再ロードされます。 symfony/symfony2のような大きなエンタープライズフレームワークで簡単に見ることができます。多くのレンダリング時間はsymfonyの内部プロセスであり、asp.netが一度読み込むだけで、無駄な作業のためにサーバーを浪費しません。
ASP.NETは、オブジェクトをアプリケーションメモリのキャッシュに保持できます。PHPでは、オブジェクトをファイルに書き込むか、memcacheのようなハックを使用する必要があります。 memcacheの使用は、並行性と危険性の問題を扱う多くの作業です（ファイルにキャッシュを保存することには、並行性に関する独自の問題もあります-すべてのリクエストはApacheサーバーの新しいスレッドを開始し、多くのリクエストは一度に処理できます-それらの間の並行性について考える必要がありますスレッドでは、開発時間がかかり、常に機能するとは限りません。なぜなら、PHPには言語のミューテックスメカニズムがないため、どのような方法でもクリティカルセクションを作成できないからです。
aSP.NETには環境用にインストールされた2つの主要なフレームワーク（WebformsとMVC）があり、PHPでオープンソースフレームワークを取得する必要があります。 asp.NETのようなphpの標準フレームワーク。
ASP.NET言語は非常に豊富であり、標準ライブラリには非常に一般的な問題の解決策があります。ここでPHP標準ライブラリは...裸です...命名規則を1つ保持できません。
.NETには型があり、PHPは動的であるため、ソースコードを実行するか、単体テストを記述するまでソースコードを制御できません。
.NETには優れたIDEここでPHP IDEは平均的または平均的です（PHPStormはVS + resharperまたはそれなしでもなお悪い）
SymfonyのPHP足場は、ASP.NET足場が環境に統合されるとコマンドラインから起動されます。
私のような遅いコンピューター（1コア2,2ghz）がある場合、asp.netページの開発は、ソースコードの変更時にプロジェクトを再コンパイルする必要があるため、苦痛になります。ここでPHP code refreshすぐに。
PHP言語の構文は、C＃の構文に比べて未完成で、しっかりしておらず、裸です。 C＃の強力な型と多くの柔軟な言語機能は、開発をスピードアップし、コードのバグを減らします。
私の（ハードベンチマークされていない）経験では、Asp.Netは確かに競争することができます（そして、一部の分野では、生の速度の点でPHP。次の文は（この場合）有効です（私の意見では）：
- 言語xには低速でバグのあるサイトがあります（PHPまたはAsp.Net）
- 言語xには素晴らしく高速なサイトがあります（PHPまたはAsp.Net）
私が言おうとしていること：開発者（の才能）は、2つの（一部の抽象化された範囲でほぼ同等の）テクノロジーを選択するよりも全体的な速度に影響します。
実際、「全体的な速度」の比較は、非常に特定の専門分野（あなたが私たちに知らせていない）でない限り、何らかの形でお互いに追いつくことができるため、あまり意味がありません。
ASP.netと言います
考慮事項：
- ASP.netはプリコンパイルされています
- ASP.netは通常C＃で記述されており、PHPよりも高速に実行されるはずです。
確かに、違いはごくわずかです。両方に利点があります。PHPは展開がはるかに簡単で、IISだけでなく任意のサーバーで実行できます。ASP.netMVCが大好きです。
パフォーマンステストを行いました。
プログラム：10000000の数字の合計
与えられた出力は、phpがC＃よりも遅いことを証明しています............
最適化を行わないと、.netでコンパイルされたアプリはもちろんphpよりも「高速」に実行されます。しかし、あなたはそれが愚かで無関係な議論であることは正しいです。なぜならそれは自慢する権利を超えて現実の世界に関係がないからです。
一般に、ASP.Netは、PHPよりも特定のハードウェア上でパフォーマンスが向上します。 ASP.Net MVCは、さらに良い結果を出すことができます（ここでは、操作可能なWordにすることができます）。プラットフォームのほとんどは、エンタープライズ開発を念頭に置いて設計されています。テスト可能なコード、懸念事項の分離など。ASP.Netの肥大化の多くは、ページ内のオブジェクトスタック（ネストされたコントロール）に由来しています。プリコンパイルするとパフォーマンスは向上しますが、重要な問題になる可能性があります。 MVCは、Webフォームベースのビューエンジンを使用して、ネストを少なくする傾向があります（他のエンジンも利用可能です）。
Webアプリケーションで最大のスローダウンが発生するのは、リモートサービス、特にデータベースの永続性です。 PHPは、接続プーリングまたはメモリ内セッション状態の利点なしでプログラムされます。これは、memcachedおよび他のよりパフォーマンスの高いサービス層（.Netでも利用可能）で克服できます。
実際には、サイト/アプリケーションの詳細に依存します。このサイトでは、かなり控えめなハードウェアでMVCを実行することができます。 PHP=の下にある同様のサイトは、おそらく自重になります。他の考慮事項。IIS vs. Apache vs LightHTTPDなど。正直にphp vs. netは、生のパフォーマンスの違いよりもはるかに大きくなります。PHPは、asp.net mvcほどの大規模で複雑なアプリケーションには向いていません。他の何よりもVS + SCC。
私は両方のテクノロジー（ASP.Net c＃およびPHP5）の開発者エキスパートです。実際の本番環境で何年も働いて比較した結果、私の印象は次のとおりです。
まず第一に、それらを比較して値1.000.000を追加するループを作成することはできません。これは実際のケースではありません。
私の開発環境で実際の本番環境と比較しても同じではありません。例：開発では、ASP.NetはIISを使用しません。デフォルトでは、異なる最適化を持つ内部開発サーバーを使用します。devでは、並行性はありません。
だから私の意見は次です：
1.000.000回のC＃のループはより高速になります。
DBにアクセスし、画像を表示し、フォームなどを含む実際のページを提供します。ASP.NetはPHPよりも低速です。
ASPXページの重量はPHPよりも10倍重いため、最終ユーザーはページを取得するのにより多くの時間を待つことになります。
ASPXはPHPよりも開発に時間がかかります。これは、最後にお金があるため重要です。 smthgをチェックするたびにコンパイルして再起動する必要があるため、ASP.NetよりもPHPで35％高速に開発しています。
大規模なプロジェクトでは、ASP.Netを長期的に使用すると、エラーを回避し、複雑なアーキテクチャを使用できます。
Windows Servers、IIS、...のため、最終的には、ASP= PHPよりも多くのユーザーを保持するための強力なサーバーが必要です。同時ユーザーおよびPHPでは、同じサーバーで約30.000ユーザーを取得できます。
唯一の重要なことは、どちらがより高速であるかをループする場合ではありません。問題は、ウェブサイトが本物で運用中の場合、保持できるユーザーの数、ページの重さ（heavier ==ユーザーからの待ち時間の増加、サーバーの正味料金の増加、サーバーのディスク料金の増加、メモリ料金の増加サーバ）。同時実行でチェック時間を試してみると、uが表示されます。
それが役に立てば幸い。
私はあなたに同意する傾向があります（ASP.NET MVCの方が速い）が、友だちと友好的な賭けをして結果を共有してみませんか？ MySQLデータベースから派生した非常にシンプルなDYNAMICページを作成し、ページを何度もロードします。
たとえば、連続する主キーを含む1,000,000行のテーブルを作成し、2番目の列にランダムな＃を作成します。各サイトは、GETでプライマリキーを受け入れ、渡されたキーに基づいてランダム＃を取得し、動的に生成されたhtmlのいくつかのタイプでランダム＃を表示できます。
私は結果を知りたいです...そしてもしあなたがブログなどを持っているなら、他の世界もそうでしょう（この質問はいつも尋ねられます）。
通常のASPでもこのシンプルな小さなアプリを構築できればさらに良いでしょう。ここに興味があると私はあなたに私の電子メールを送ります。