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

Question

我有一个相当大的ASP.NET MVC / WebApi Web应用程序（~100KLOCS），它在负载下有点嘎嘎作响（大约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

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

那里的任何人都有值得分享的真实故事或疤痕吗？或者有关如何判断Ninject是否是瓶颈的建议？

Answer 1

我知道我对这个问题有点迟了，而且我确定你已经得出了一些结论，但这是我最近发现自己要求很多的东西。 Ninject肯定不是最快的，但它（在我看来）是我用过的最灵活和可扩展的框架，与之合作是一种绝对的快乐。我从未遇到过用Ninject解决的IoC问题。

这真的是一种折衷。当我使用灵活性和可扩展性是关键的客户端时，通常是面向内部的业务应用程序，我使用Ninject。当我从事小型集中组件（其中性能是关键的，大容量的外部Web服务）时，我会像SimpleInjector一样使用更快的东西。然而，当我需要做一些更高级的事情时，我一次又一次地发现它缺乏，最终最终取而代之。然而，当我将我的方法调整为微服务风格的方法时，我开始在较小的框架中看到更多的价值。

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

Answer 2

＆＃34;值得它＆＃34;只能由你决定。您是否在自己的网站上运行了一个分析器，以查看最严重的瓶颈在哪里？甚至可能不是Ninject是你最糟糕的罪犯。

当然，对于许多人来说，任何可以休息一段时间的地方都是值得的。但很多都取决于你的用法。例如，如果您通常仅注入少量具有浅依赖图的对象，您可能不会看到很多好处。但是，如果你有数百个对象的深度依赖图，那么你可能会看到很多好处。

SimpleInjector不太可能很快被抛弃，因为主要的开发者是一个众所周知的人。

StructureMap是另一个不错的选择，虽然它在性能方面处于中等水平，但它得到了良好的支持并且拥有良好的社区。

Answer 3

任何人都再次在这个问题上徘徊，不妨尝试一下DryIoC。性能更接近SimpleInjector，但可扩展性更高。 MS实际上将它用于一些后端服务，Azure Durable函数就是其中的一个。