出于性能原因,是否值得更换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

“值得”只能由你自己决定。您是否在站点上运行分析器来查看最严重的瓶颈在哪里？最严重的罪犯甚至可能不是 Ninject。

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

SimpleInjector 不太可能很快被放弃，因为主要开发人员是一位知名人士。

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