performance - 出于性能原因，是否值得更换 Ninject？

Question

我有一个合理大小的 ASP.NET MVC/WebApi Web 应用程序(~100KLOCS)，它在负载下吱吱作响(大约 1MM 请求/天)。例如，加载一个页面通常需要 2-3 秒，这与最佳状态相差很大。当我开始四处寻找可能的瓶颈时，我不禁注意到 Ninject，我的 IOC 容器，被评为最慢的一个非常健康的边缘:

http://www.palmmedia.de/Blog/2011/8/30/ioc-container-benchmark-performance-comparison
https://github.com/ninject/ninject/issues/84

有没有其他人处于这个位置并尝试将 Ninject 替换为其他东西，例如，LightInject , SimpleInject ，或类似的东西？值得付出努力吗？ Ninject 似乎是最受欢迎的，有很多社区和框架支持，我一点也不急于让自己参与一个最终将不受支持的项目。除此之外，我不确定如何测试以查看在现实世界的应用程序中，IOC 容器的性能是否会受到关注。

有没有人有任何真实世界的故事或伤疤值得分享？或者关于如何判断 Ninject 是否甚至是瓶颈的建议？

Answer 1

我知道我在这个问题上有点晚了，我相信你已经得出了一些结论，但这是我发现自己最近问得很多的问题。 Ninject 当然不是最快的，但它(在我看来)是我用过的最灵活和可扩展的框架，使用它绝对是一种乐趣。我从未遇到过 Ninject 无法解决的 IoC 问题。

这真的是一种权衡。当我与灵活性和可扩展性是关键的客户合作时，通常是面向内部的业务线应用程序，我使用 Ninject。当我在处理性能至关重要的小型组件时，例如面向外部的大容量 Web 服务，我会使用像 SimpleInjector 这样更快的东西。然而，当我需要做一些更高级的事情时，我一次又一次地发现它缺乏，最终最终替换它。然而，当我将我的方法调整为微服务风格的方法时，我开始在较小的框架中看到更多的值(value)。

您会看到性能提高，听起来就像您看到的音量类型一样。但是这种性能提升的感知值(value)完全取决于您对灵活性和 Ninject 提供的其他功能的重视程度。