建好了负载测试，接下来就是决定把调优精力放在何处。大多数调优指南都会提到“性能比率”或者度量之间的关系。例如，某调优指南可能强调说缓存命中率应该达到80%或者更高，因此负载测试应用时调整缓存大小直到命中率达到80%。然后处理列表上的下一个度量值，但是不要忘记验证调整新的参数不会影响之前已经调好的其他参数。
这项工作不仅困难而且效率很低。例如，调整缓存命中率到80%可能是件好事，但是存在一些更重要的问题：
• 该应用如何依赖于缓存（与该缓存交互的请求比例是多少）？
• 这些请求对应用中的其他请求有多大影响力？
• 被缓存的条目的本质是什么？它们真的需要缓存吗？
基于等待的调优方法提出了一个新的思想，即分析应用的业务交互和实现这些交互的底层结构，然后优化这些业务交互的处理。第一步是分析应用的架构以定位实现业务请求的相关技术。每一个技术代表一个“等待点”，或者说在应用的这个地方，请求可能需要等待一些事情才能继续处理。例如，如果一个请求执行了一次数据库查询，则它必须从连接池中获取一个数据库连接—如果连接池里没有可用的连接，则该请求必须等待直到有连接可用。同样，如果某请求调用了一个web服务，而那个web服务维护了一个请求队列（对应一个线程池处理请求），这会潜在的导致请求等待直到一个处理线程可用。
从以上称之为等待点分析的方法中，可以定位两种类型的等待点：
• 基于层次的等待点
• 基于技术的等待点
本节首先概述了基于等待点的架构分析方法，然后分别研究了不同类型的等待点。
等待点架构分析
从上面讨论中得出的最重要的结论就是性能调优必须在应用架构的环境中执行。这也是调优性能比率为何如此低效的一个原因：主观的调整一个性能参数到一个最佳值，对应用可能是好事也可能是坏事——因为这可能会也可能不会有利于最终用户体验。
基于等待点的分析是一个分析应用中主要请求处理路径的过程，借此定位潜在影响该请求可能会等待的资源。在等待点分析实践中最有效的办法是定位并标出应用中核心处理路径。这包括一个请求可能访问的所有层次、请求交互的所有外部服务、被做成池的所有对象和全部缓存对象。
文章来源于领测软件测试网 https://www.ltesting.net/