这是一个低效的过程，如果大多数请求都要执行这些步骤，那么缓存肯定会降低性能。缓存必须调整到足够大以小化缓存的“不命中率”，一次不命中意味着需要执行前面提到的七个步骤，但是也不能太大导致占用太多JVM内存。如果缓存需要非常非常大才能满足性能需要，那么好是重新考虑被缓存对象的实质和它们到底是否值得缓存。

　　类似对象池，外部资源池，比如数据库连接池，也必须足够大以满足请求不会被迫等待池中的一个连接变为可用状态，但是也不能太大，导致应用浪费外部资源。“后退调优”一节讨论了如何决定这些池的佳大小，但是在本节的上下文中，牢记它们代表了一个明显的等待点。

　　调优通讯基础设施远远超出了本文讨论的范围，因为其具体实现因产品不同而存在明显的区别，这包括诸如MSMQ、MQSeries、TIBCO等主流产品。但是请记住，如果一个应用与某消息服务器交互，它必须经过合适的调优或者它也代表了一个等待点。

　　后一个明显影响JVM性能的等待点是垃圾收集。它不太适用本文中描述的等待点分析过程(检查一个请求，定位导致该请求等待的技术)，但是由于它可以对性能产生显著的影响，所以把它列在这里。不同的JVM实现和不同的垃圾收集策略决定了垃圾收集如何执行，但是在很多情况下，一次主垃圾收集(或者说标记—清除—压缩垃圾收集)可能导致整个JVM暂停直到垃圾收集完成。一个显著提高JVM性能的办法是优化垃圾收集。如果想了解更多垃圾收集的信息，请加入GeekCap讨论应用基础设施调优。

　　后退调优

　　现在关于基于层次的和基于技术的等待点的一切都介绍完了，后一步是优化每一个等待点的配置。这一步有时被称为“后退调优”，其思想非常简单：

　　开放所有基于层次的等待点和外部依赖池——也是配置它们允许过多的负载经过服务器。

　　根据应用生成均衡的和具有代表性的服务请求。

　　定位首先透支的等待点，通常是外部依赖，比如数据库。

　　减小配置以控制等待点允许足够的负载经过外部依赖而不透支。

　　调整所有其他基于层次的等待点，发送足够的负载经过服务器，大化受限制的等待点，但是也不让请求等待。

　　允许所有其他请求在业务逻辑层之上等待，比如web服务器端。

　　此处的原则是应用应该发送一定数量的负载给它的外部依赖资源以大化它们的使用率又不导致透支—并且所有其他等待点应该合理配置以发送足够的负载给这些受限制的等待点。例如，如果数据库对每一个应用服务器多支持50个连接(例如，配置池容纳40或45个连接)。接下来，如果80个线程产生40个数据库连接，则应用的线程池应配置为80。后，web服务器在任意时刻应该发送不超过80个请求给每一个应用服务器。

　　所有基于技术的等待点，比如对象池、缓存和垃圾回收，应该调整到大化请求的吞吐量使得尽可能快的穿越服务器或者基于层析的等待点之间。

　　总结

　　性能调优曾经是“艺术性”多于“科学性”，但是通过结合抽象分析和尝试并产生错误，基于等待的调优方法已经证明能够使该过程更具科学性和更有效率。基于等待的调优首先执行一个应用架构的等待点分析，以此定位有可能导致请求等待的某个技术。等待点来自两方面：基于层次的等待点，代表着跨越应用层次的转换;基于技术的等待点，代表着可能提高或降低性能的技术，比如缓存、池和通讯基础设施。一旦定位好了一系列等待点，调优过程此开始：开放所有基于层次的等待点和外部依赖池，产生均衡的和具有代表性的负载，然后后退调优，收紧等待点以大化该请求薄弱的一环的性能，但是不要透支。基于等待的调优方法在生产环境中已经一次又一次得到了证明，不仅仅是高效的，而且允许性能工程师快速实现可度量的性能优化。