此文是前文的后续，内容是在前轮性能测试的调优后，进行的调优结果验证。演示了如何对比两轮测试的结果，如何分析突然出现波动的原因，如何根据大量的数据验证调优的效果、验证能否达到预期性能目标，以及更重要的思考过程。这是一个比较不错性能测试调优后验证的实例。可以清楚看到专业人事，对性能调优后的数据，进行客观的比较，分析，再进一步判断调优的效果。故分享之。
由于本人能力不够，很多术语，不太明确其中文翻译，如大家看到有错误，请不吝赐教。例如，在文章图片中% Difference in XXXX 和5.Per.Mov.Avg不知道是如何计算，又该如何翻译的好。
Spike - 数据增加明显，形成一个尖，暂译：波动
Peak - 数据到达最大值，暂译：高峰或者峰值
Degradation / Degrade - 性能变差，暂译：退化
Job - 定期执行的后台程序或服务，暂译：作业
原文连接: http://apmblog.compuware.com/2013/07/11/an-integrated-approach-to-load-test-analysis-part-2-the-follow-up-test/
以下为正文
本文由Andreas Grabner共同撰写，他是Compuware的APM卓越中心的团队负责人(Team Lead for the Compuware APM Center of Excellence)。
在之前的一篇文章中，我演示了如何做更深入的分析 - 合并了由Compuware APM网络负载测试工具(Compuware APM Web Load Test，以下简称WLT)得到的外部网络负载测试结果和由Compuware PureStack技术收集硬件设备的状态数据。但是，现在我们已经测试过系统一次，在“解决”我们发现的问题之后，如果我们再次进行测试，那又会出现什么呢？使用前一轮测试时相同的参数，再运行一轮测试，就知道性能得到显著改善？我们系统能够达到期望的负载目标吗 - 支持200个虚拟用户，很少或者没有性能退化？
此文将带领你一步一步，比较两次负载测试的结果再判断调优之后性能的改善（或退化）。
第1步：根据第一次测试的结果，确定问题和进行调优
在4月14日的负载测试期间，我和Andreas Grabner发现我们网站在高负载下，有显着的性能问题，这时的负载已远超目前水平，即使是在APM社区网站人气最高时的负载水平。这些问题是造成负载水平达不到开发团队想要达到的目标 - 200个虚拟用户。
汇总的数据视图展现4月14日的负载测试中的外部和内部性能指标
在4月14日负载测试执行时，我们发现了一些环境问题。系统团队记录下关键问题包括：
部署关键的APM社区程序到其他的机器，以防止某一层的性能负面地影响到其他层(Deployment of critical APM Community applications to different machines to prevent the application performance of one layer negatively affecting another laye)
优化应用程序层 - APM社区网站的页面生成方式，以降低CPU使用率
优化Confluence的缓存设置，当加载常用的对象时，可以减少来回查询数据库次数
增加虚拟机的CPU分配，以便他们能够处理更多的负载。
第2步：再次运行测试（使用相同的参数！）
一旦这些调整完成后，根据第二轮测试的结果，在调优后的环境上，验证是否能够达到预期的目标 - 200 虚拟用户并发，且没有响应时间退化的现象。第二轮负载测试被安排在整整1周后，即4月21日，并使用第一轮测试时相同的参数（负载增压(load ramping)的细节设置参考前一篇文章）。使用相同的测试参数（负载增压，测试脚本，测试位置，测试数据等）是至关重要的，只有如此，测试结果的对比才有意义(Using the same test parameters (load ramp, test scripts, testing locations, databanks, etc.) is critical in order to allow a like-for-like comparison to occur.)。任何测试参数的偏差，会影响到最终结果，影响对应用程序环境的判断，可能导致对调优的不真实的信任（或怀疑）。
当4月21日这轮负载测试完成后，我们开始分析测试结果，初步的数据（更高的吞吐量，更快的响应时间，更低的CPU占用率和更低的数据库负载），表明这轮负载测试比前一轮的测试更为成功。这个初步结论是基于性能图表（包含了我们分析4月14日测试时曾使用的相同的数据），这个图表直接对比其关键数据，突出在两轮测试执行之间，性能表现是否存在了巨大的变化。
