ASP.NET Core はどれだけ速いのか — Spring・Django との比較と、gRPC が Rust を上回るという事実

「バックエンドは何で書くのが速いのか」という問いは、いまも技術選定のたびに蒸し返されます。Python や Java が定番とされる一方で、ASP.NET Core が主要ベンチマークの上位に定着している事実は、意外と知られていません。さらに gRPC のスループット比較では、システム言語の代表格である Rust をも上回る結果が報告されています。本記事では、公開ベンチマークの数字をもとに ASP.NET Core の実力を整理し、その速さがどこから来るのか、そして実運用でどこまで意味を持つのかまでを解説します。

「速いフレームワーク」をどう測るか

Web フレームワークの性能比較で最もよく参照されるのが TechEmpower Framework Benchmarks です。ここには大きく2種類のテストがあります。ひとつは「Hello World」に近い最小応答だけを測る単純なもの、もうひとつは JSON シリアライズ・データベースクエリ・複数更新・HTML 生成（Fortunes）といった実アプリに近い処理を測る複合的なものです。前者は素の1秒あたりのリクエスト数（req/s）を見るのに向き、後者は「総合スコア」として重み付けされます。

この違いは重要です。単純な req/s だけを見るとフレームワーク間の差は小さく見えますが、DB アクセスや更新を含む複合テストになると差が開いていきます。以下ではまず ASP.NET Core・Java Spring・Python Django の 総合的な立ち位置を確認し、続いて gRPC のスループット、最後に「その数字を実運用でどう受け止めるか」までを見ていきます。

ASP.NET Core・Spring・Django の実力差

TechEmpower の総合スコアでは、ASP.NET Core は最上位グループに位置します。最速フレームワークを 100 とした相対値で見ると、ASP.NET Core が 70 台後半に届くのに対し、Java Spring は 20 前後、Python Django は 1 桁台にとどまります。同じ「Web フレームワーク」でありながら、複合ワークロードでは 10 倍以上の開きが生まれることも珍しくありません。

ここで一点、誤解しやすいポイントを補足します。素の「1秒あたりのリクエスト数」だけを取り出すと、ASP.NET Core と Spring の差はもっと小さく見えることがあります。これは Hello World 級のテストではフレームワーク層の差が表面化しにくいためです。実際に DB クエリや更新、シリアライズを重ねる複合テストになって初めて、ランタイムとライブラリの作り込みの差が総合スコアとして現れます。フレームワークを選ぶときは、単一の req/s ではなく 自分のワークロードに近いテストを見るべきだ、というのが実務的な結論です。

gRPC では .NET が Rust をも上回る

さらに象徴的なのが gRPC のスループット比較です。言語横断で gRPC 実装を計測している grpc_bench プロジェクトの結果では、.NET が Rust・C++・Go・Java を抑えて 最上位のスループットを記録した例が報告されています。最小のプロトコントラクトを使い、各実装を Docker コンテナに閉じ込め、負荷生成には ghz を使う——という揃った条件下での計測です。

「Rust より .NET が速い」と聞くと違和感を覚えるかもしれません。もちろん この差は僅差で、実装のバージョンや実行環境しだいで簡単に前後します。ここで受け取るべきメッセージは「.NET が常に Rust より速い」ではなく、マネージドランタイムである .NET が、システム言語と同じ土俵で互角に戦える水準にあるという事実です。GC を持つ言語がここまで来たこと自体が、近年の .NET の進化を物語っています。

なぜ ASP.NET Core / .NET はここまで速いのか

この速さは、特定の魔法ではなく ランタイムとライブラリの地道な積み重ねから来ています。大きく4つの土台があります。

• Kestrel と System.IO.Pipelines——軽量な Web サーバー Kestrel が、受信バイト列を余分なコピーなしで処理する。HTTP/2 上の gRPC もこの基盤に乗る。
• Span<T> / Memory<T> によるゼロコピー——ヒープ割り当てを避けることで、GC の負荷とレイテンシのばらつきを抑える。
• ソースジェネレーター——JSON シリアライズやルーティングをコンパイル時に生成し、リフレクションを排除する。Native AOT とも相性がよい。
• GC・JIT・Native AOT——Server GC と階層型 JIT（動的 PGO）が実行時に最適化し、Native AOT を使えば起動も速く常駐メモリも小さくなる。

注目すべきは、これらが 言語機能ではなくプラットフォーム側の進化だという点です。つまり、既存の C# 資産を書き直さなくても、.NET のバージョンを上げるだけで多くの恩恵を受けられます。レガシーからの移行が「性能への投資」にもなるということです。

ベンチマークを鵜呑みにしない

ここまで数字を並べてきましたが、実務では ベンチマークの順位をそのまま鵜呑みにしないことも同じくらい大切です。理由は2つあります。

ひとつは、ベンチマーク上位のコードは徹底的にチューニングされていること。バイト列を直接書き出す最適化や、応答サイズのハードコードなど、ベンチ専用の作り込みが入っていることも多く、日常のアプリコードとは別物です。もうひとつは、実アプリの応答時間の多くはフレームワーク外で決まることです。

数十万 req/s を出せるフレームワークでも、N+1 クエリやインデックス不足があれば体感速度は簡単に台無しになります。多くのアプリケーションにおいて、速さを決めるのは言語ではなく DB 設計とキャッシュ戦略です。だからこそ順序が大事で、まず計測してボトルネックを特定し、そこから直すのが鉄則です。

とはいえ、フレームワークの速さが無意味なわけではありません。高トラフィックのサービスでは、スループットの差が必要なサーバー台数、ひいてはインフラコストに直結します。「2台で済むところを10台に増やす」判断は、規模が大きいほど効いてきます。.NET は、この コスト効率と開発生産性を両立できる選択肢だと言えます。

まとめ — 速さと生産性を両立する選択肢

公開ベンチマークが示すのは、ASP.NET Core が Spring や Django を大きく上回り、gRPC では Rust とも互角に戦えるという事実です。しかもそれを、C# という 型安全で生産性の高い言語のまま実現できます。既存の .NET 資産を持つ組織にとって、最新の .NET へ移行することは、性能とコスト効率への投資でもあります。数字に振り回されず、自分のワークロードで計測しながら、その強みを引き出していきましょう。

参照元

• Performance benchmark and requests per second comparison between ASP.NET Core, Java Spring and Python Django（r/dotnet の議論）
• LesnyRumcajs/grpc_bench — gRPC 実装の言語横断ベンチマーク
• TechEmpower Framework Benchmarks

よくある質問

ASP.NET Core の gRPC は Rust より速いのですか？

公開ベンチマーク（grpc_bench）の一例では、.NET の gRPC が Rust をわずかに上回る結果が報告されています。差は僅差で環境により前後しますが、マネージドランタイムの .NET がシステム言語と互角に戦える水準にあることを示しています。

ASP.NET Core と Spring・Django では req/s はどれくらい違いますか？

TechEmpower の総合スコアでは ASP.NET Core が最上位グループ、Java Spring は中位、Python Django は下位です。DB アクセスや更新を含む複合テストほど差が開きます。

ベンチマークの結果は実運用にそのまま当てはまりますか？

当てはまりません。実アプリの応答時間の多くは DB クエリや外部通信で決まります。フレームワークの速さはサーバー台数・コストに効きますが、体感速度はまず DB 設計とキャッシュを見直すのが先です。

パフォーマンスチューニングの全体像は .NET パフォーマンス最適化 完全ガイド にまとめています。あわせて Native AOT ガイド や Minimal API のスループット最適化 もご覧ください。