温莎城堡3.2解决性能问题

我们有一个使用温莎城堡多年的大型网络应用程序。该应用程序拥有约370个服务的组件注册。它们几乎全部属于根，即入口点控制器。当网络请求到来时，我们解析该入口控制器并让它处理请求。问题是解决根组件需要大约35毫秒。我会说这听起来对我来说非常重要。温莎城堡3.2解决性能问题

我的问题是，如果上述数字听起来很正常？任何人都可以给我提示我可以做些什么来提高解决时间吗？或者检查我是否做错了什么？

谢谢:)

来源

2014-09-27 Thuan

你是怎么评价这个的？在RELEASE模式下编译并在调试器外部运行时，是否对此进行了基准测试？ – Steven 2014-09-27 09:57:31

是的，我使用StopWatch来测量解析日志所需的时间并将其写入日志。在发布模式和调试器之外肯定。 – Thuan 2014-09-27 10:35:50

它需要多少时间来解决对象图取决于很多因素，如：

对象图的大小
注册的生活方式的组件和这些生活方式的位置（显然，如果根对象是单身人士，解析速度非常快）
您在构造函数中所做的工作量

所以没有进一步的信息，没有太多可说的。不过，我会说35毫秒。相当多，即使是温莎城堡。我在6个最常用的DI容器上运行了一个小型基准，同时解决了881个瞬态组件的对象图，最慢的容器（Ninject）花费了5毫秒，而最快的容器（Simple Injector）花了0.01毫秒（在我的机器上）解决这个问题图形。

Container  | ms. 
----------------+----- 
Simple Injector | 0.01 
StructureMap | 0.50 
Autofac   | 0.77 
Unity   | 1.04 
Castle Windsor | 3.96 
Ninject   | 5.03

从这个基准，我会说35毫秒。对于用Castle Windsor解决这个尺寸的对象图有点慢。因此，请确保your injection constructors are simple与检查null并存储传入的依赖关系无关。这样你可以compose your object graphs with confidence。

顺便说一句，你可以找到一个更广泛的基准here。

来源

2014-09-27 11:13:00 Steven

谢谢:)你的回答确实给了我一些有用的提示。我将验证我的代码库，稍后再回来:) – Thuan 2014-09-28 10:27:19

我们的一些组件需要创建实体框架的对象上下文。我们还使用子容器为每个请求添加更多组件，从而增加更多毫秒。所有其他构造函数对我而言并不昂贵。我的粗略估计是，所有这些繁重的操作都需要最多50％的时间。因此，看起来温莎自己的代码大约需要20ms，这仍然很多。 – Thuan 2014-10-13 13:31:27

@ Thuan：如果这太多了，请切换到更快的容器。 – Steven 2014-10-13 13:41:16

温莎城堡3.2解决性能问题

回答

相关问题