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与通信的比例经常是数千比一。不论通过缓存或并发或其他技术，请降低这个比例，这将比改变数据结构或调整排序算法要更有效。
