回归验证：最好在应用的生产周期中阶段性的验证用户行为，以防止用户行为 改变或者引入新的功能或工作流导致用户行为改变。

最后一步，也是经常被忽视的一步，就是反思。根据实际用户行为来反思评估 的精确性是很重要的，因为只有通过反思，用户行为才能更便于理解，评估在以 后的应用中才能得到提高。没有反思，相同的错误会一犯再犯，最终会增加调优 的工作量。

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

基于等待的调优方法

建好了负载测试，接下来就是决定把调优精力放在何处。大多数调优指南都会 提到“性能比率”或者度量之间的关系。例如，某调优指南可能强调说缓存命中 率应该达到80%或者更高，因此负载测试应用时调整缓存大小直到命中率达到80% 。然后处理列表上的下一个度量值，但是不要忘记验证调整新的参数不会影响之 前已经调好的其他参数。

这项工作不仅困难而且效率很低。例如，调整缓存命中率到80%可能是件好事 ，但是存在一些更重要的问题：

该应用如何依赖于缓存（与该缓存交互的请求比例是多少）？

这些请求对应用中的其他请求有多大影响力？

被缓存的条目的本质是什么？它们真的需要缓存吗？

基于等待的调优方法提出了一个新的思想，即分析应用的业务交互和实现这些 交互的底层结构，然后优化这些业务交互的处理。第一步是分析应用的架构以定 位实现业务请求的相关技术。每一个技术代表一个“等待点”，或者说在应用的 这个地方，请求可能需要等待一些事情才能继续处理。例如，如果一个请求执行 了一次数据库查询，则它必须从连接池中获取一个数据库连接—如果连接池里没 有可用的连接，则该请求必须等待直到有连接可用。同样，如果某请求调用了一 个web服务，而那个web服务维护了一个请求队列（对应一个线程池处理请求）， 这会潜在的导致请求等待直到一个处理线程可用。

从以上称之为等待点分析的方法中，可以定位两种类型的等待点：

基于层次的等待点

基于技术的等待点

本节首先概述了基于等待点的架构分析方法，然后分别研究了不同类型的等待 点。

等待点架构分析

从上面讨论中得出的最重要的结论就是性能调优必须在应用架构的环境中执行 。这也是调优性能比率为何如此低效的一个原因：主观的调整一个性能参数到一 个最佳值，对应用可能是好事也可能是坏事——因为这可能会也可能不会有利于 最终用户体验。

基于等待点的分析是一个分析应用中主要请求处理路径的过程，借此定位潜在 影响该请求可能会等待的资源。在等待点分析实践中最有效的办法是定位并标出 应用中核心处理路径。这包括一个请求可能访问的所有层次、请求交互的所有外 部服务、被做成池的所有对象和全部缓存对象。

基于层次的等待点

一个请求穿过一个物理层，比如在web层和业务层之间切换，或者调用外部服 务器，比如web服务，每当这种时候，都意味着伴随着转换，这里存在一个隐式等 待点。如果服务器在某一时刻只处理单个请求是没有效率的，因此他们使用了多 线程方法。典型的，一个服务器在某个socket端口监听访问的请求——每当收到 一个请求它就会把请求放在队列中，然后返回监听其他请求。请求队列对应着一 个线程池，负责从队列中提取请求并处理。图2描述了对于三层结构（web服务器 、动态web层和业务层）的执行过程。

图 2 基于层次的等待点

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

因为请求穿越层次的动作会引起请求队列，由相应的线程池处理，这种线程池 也是一个潜在

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