进程间通信影响应用响应时间

Inter-Process Communication Affects Application Response Time

响应时间对软件的可用性至关重要。等待一些软件系统响应会让人心烦,尤其是当我们与软件交互时遇到循环重复的刺激和响应。我们会觉得这个软件是在浪费时间,还影响我们的生产率。然后,因为响应时间短而被赞赏的情况却很少,尤其是当代的应用。很多关于性能管理的文献仍然聚焦于数据结构和算法,问题是在某些情况下可能有用,但在当今的多层企业级架构的应用中,不大可能改善性能。

当性能成为应用程序的一个问题时,我个人的经验是,检查数据结构和算法并不能改善现状。响应时间更多依赖于无数个远程进程间通信(IPC)行为。尽管存在本地瓶颈,但大量的远程IPC才站主导地位。每个远程IPC都会对总体产生一些不容小觑的延迟,每个单独的延迟都会累加起来,尤其在它们按顺序运行时特别明显。

最佳案例就是应用对象-关系映射的程序中采用“波纹加载”。波纹加载描述了多个数据库调用的执行顺序,以选择用于构建对象图所需的数据(看一下Martin Fowler’s的《企业级应用架构模式》中的懒加载)。当数据库客户端是呈现中间应用服务器的网页时,这些数据库就会在单线程中被频繁地顺序调用。每个小延迟的积累,汇集成巨大的响应时间。甚至是一个数据库仅花10ms,一个页面需要调用1000次(虽然不常见),就能展现出将近10秒钟的响应时间。另一个例子是WEB服务的调用,来自浏览器的HTTP请求,分布式对象调用,请求应答消息,以及在自定义网络协议上的数据交互。越多的远程IPC所需的响应就越多,响应时间也就越长。

有一小部分相对明确且众所周知的策略可以降低远程IPC每次处理的数量。其中之一是简约原则,优化两个进程间的接口,以便于用最小的交互来交换各自手上的目标数据。另一个策略是尽可能并发IPC,以便于让总体响应时间由最长延迟的IPC驱动。第三个策略是缓存之前的IPC结果,以便于用本地缓存来代替之后的IPC请求响应。

当你在设置一个应用程序的时候,要警惕每个IPC响应延迟的数量。在分析低性能的应用程序时,我发现IPC与通信的比例经常是数千比一。不论通过缓存或并发或其他技术,请降低这个比例,这将比改变数据结构或调整排序算法要更有效。

0%