新的对象此刻添加到缓存中。

新的对象最终返回给请求。

一种正规的性能调优方法──基于等待的调优(5)

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

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

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

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

后退调优

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

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

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

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

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

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

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

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

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

总结

性能调优曾经是“艺术性”多于“科学性”，但是通过结合抽象分析和尝试并 产生错误，基于等待的调优方法已经证明能够使该过程更具科学性和更有效率。 基于等待的调优首先执行一个应用架构的等待点分析，以此定位有可能导致请求 等待的某个技术。等待点来自两方面：基于层次的等待点，代表着跨越应用层次 的转换；基于技术的等待点，代表着可能提高或降低性能的技术，比如缓存、池 和通讯基础设施。一旦定位好了一系列等待点，调优过程就此开始：开放所有基 于层次的等待

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!