出于性能方面的原因，是否值得替换Ninject？

Question

我有一个大小合理的ASP.NET MVC/WebApi web应用程序(大约100KLOCS)，它在负载(大约每天1 1MM请求)下有点崩溃。例如，一个页面通常需要2-3秒的加载时间，这与最优页面相差很远。当我开始寻找可能的瓶颈时，我不禁注意到，我的IOC容器Ninject被评为最慢的，有一个非常健康的差距：

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

有没有其他人在这个位置上尝试过用LightInject、SimpleInject或其他类似的东西来替代Ninject？这样的努力值得吗？Ninject似乎是最受欢迎的，有很多社区和框架支持，我一点也不想把自己挂在一个最终不受支持的项目上。除此之外，我不确定如何测试在真实的应用程序中，IOC容器的性能是否会被注意到。

有没有人有什么值得分享的真实故事或伤痕？或者是关于如何判断是否为瓶颈的建议？

Answer 1

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

这真的是一种权衡。当我使用灵活性和可扩展性是关键的客户端时，通常是面向内部的业务线应用程序，我使用Ninject。当我在性能非常关键的小型组件上工作时，例如面向外部的大容量web服务，我会使用更快的东西，比如SimpleInjector。然而，当我需要做一些更高级的事情时，我会一次又一次地发现它的不足，并最终替换它。然而，当我将我的方法调整为微服务风格的方法时，我已经开始看到较小框架的更多价值。

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

Answer 2

“值得”只能由你来决定。您是否在站点上运行了分析器，以查看最严重的瓶颈在哪里？你最大的罪魁祸首可能还不是Ninject。

当然，对许多人来说，在任何地方你都可以节省一些时间。但这在很大程度上取决于您的使用情况。例如，如果您通常只注入几个具有浅依赖图的对象，您可能不会看到太多好处。但是，如果你有数百个对象的深度依赖图，那么你可能会看到很多好处。

SimpleInjector不太可能很快被抛弃，因为主要的开发人员是一个知名的家伙。

StructureMap是另一个很好的选择，虽然它在性能上居于中游，但它得到了很好的支持，并且有一个很好的社区。

Answer 3

任何人再一次在这个问题上徘徊，可能也想尝试一下DryIoC。性能更接近SimpleInjector，但更具可扩展性。微软实际上将其用于一些后端服务，Azure持久功能就是其中之一。