我们已经开始使用Spring AOP来处理应用程序中的横切关注点(目前是安全性和缓存)。
我的经理担心这种技术会对性能产生影响,尽管他完全理解其好处。
我的问题是,您是否遇到过由AOP引入的性能问题(特别是Spring AOP)?
我们已经开始使用Spring AOP来处理应用程序中的横切关注点(目前是安全性和缓存)。
我的经理担心这种技术会对性能产生影响,尽管他完全理解其好处。
我的问题是,您是否遇到过由AOP引入的性能问题(特别是Spring AOP)?
我使用它时没有问题,但是我的应用和你的应用可能不一样。
如果你在一个非常紧密的循环中使用它进行调用,那么很有可能会对性能产生显著的影响。如果它只是被用来每个请求检查一次安全性并缓存各种东西,我认为它不太可能有显著的影响,但这就是为什么你应该测试和基准测试“你自己”的应用程序。
我知道“用你自己的应用程序测试”可能不是你想要的答案,但这很可能是你猜到的答案 :)
您可以在这里找到我的开源项目:Puresharp API .net 4.5.2+之前是NConcern .NET AOP Framework
如果您正在使用某个框架来处理方面,可能会出现一些性能问题。接下来,如果您在某个框架上创建抽象,并且方面处理是从框架中完成的,则很难找到与性能问题相关的问题原因。如果您真的关心性能和小时间片更关心,我建议编写自己的方面。没有人想要重新发明轮子,但有时为了更好而言,这可能是最好的选择。您可以编写AOP联盟抽象的自己的实现。
您是否曾经想过,有一种AOP工具可以在您需要时在运行时向对象添加方面?.Net上已经有了这样一个工具 "Add Aspects to Object Using Dynamic Decorator" (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx)。我相信你也可以为Java编写类似的工具。
我在当前项目中的批处理过程中使用了Spring AOP来进行事务管理数据库。
起初,我们认为不会出现性能问题,但是没有考虑到我们要调用数据库数千次。 AOP中的一个方面调用不会对性能产生太大影响,但将其乘以数千倍后,结果显示新系统比旧系统更差,因为这些额外的方法调用。
我认为AOP是一个很好的系统,但请注意您的应用程序中添加了多少方法调用。
11年后,看看这种情况是如何堕落的。
例如:绝大多数人认为在某个方法中放置一个简单的@Transactional spring java注释,并让spring在调用方和被调用方代理组件之间建立桥梁是可以的和正常的。现在他们有了20多个堆栈帧的不可调试的“魔术”代码。JIT编译器被迅速超越,不能再尝试内联,或者最终导致内存膨胀,产生大量生成的类。
在这个“框架用户”时代,懒惰没有界限。难怪微不足道的http调用的端到端时间从100毫秒变成了10秒。难怪你需要2GB才能运行一个糟糕的servlet容器,而以前只需要128MB。更不用说日志异常堆栈跟踪的成本了...