NinjectからLightInjectへの移行中にWebアプリケーションのパフォーマンスが大幅に改善されない

Question

私たちは実稼働のWebアプリケーション（ASP.NET MVC）を持っています。アプリケーションは2年前に開発され、DI容器としてNinjectを使用しました。

パフォーマンスはresultsであり、NinjectをLightInjectに置き換える意欲がありました。私たちは他の小規模なWebアプリケーションでこれをやっていました。その前に、技術的なロードブロッキングはないと確信していました。

別のコードブランチで、Ninjectを変更してLightInjectで正常に置き換えました。 WebアプリケーションはLightInjectをDIコンテナとして適切に使用しています。

今興味深い部分がありますが、私たちは何を得ましたか？

私は、（科学的ではない）迅速なパフォーマンス分析を行うことを考えました。だから私はPrefix（これは素晴らしいツールです）を私の開発ボックスに使い、両方のバージョンのWebアプリケーションを手動で実行してタイミングをキャプチャしました。最初の実行と平均時間を無視して、各ページを10回ランニングします。

結果はそれほど有望ではないと私はなぜだろ作ったのですか？測定されたUIページの

1. レス数：

   は、私はこれらの結果を得るために、以下の可能性があるかもしれないと思います。

2. 使用されるパフォーマンス測定手法はマニュアルで科学的ではありません。
3. ウェブアプリケーションでDIコンテナを使用した方法は、NinjectまたはLightInjectを使用するかどうかは関係ありません。これが当てはまる場合、置換することは望ましくありません（置換は完全なアプリケーションに影響します）。これを確立するには、より科学的な結果が必要です。

サーバでプレフィックスを使用すると思っていましたが、AWS Elastic Beanstalkでホストしています。

私たちの場合、LightInjectに切り替える価値があるかどうかを確認するには、パフォーマンスマトリックスが必要です。

これに関するご提案はありますか？

Answer 1

ここでは、IoCベンチマークで見られるのと同じようなパフォーマンスの違いは見込まれません。 Webアプリケーションではこれほど多くのことが起こっているので、その差はごくわずかであると主張するのは魅力的かもしれません。その考え方は滑りやすい傾きかもしれません。追加されるすべてのコストは、ますます急速に増加し続ける合計のうち、より小さい部分についてますますカウントされます。ミリ秒ごとにカウントされます。 .Netコア用の新しいWebサーバーであるKestrelを見てみると、スループットとメモリ使用の両方に関して最大​​のパフォーマンスを搾取するための極端な対策が講じられています。メモリの割り当てと同時実行性の効率も測定すべき重要な要素です。