第4步：结果分析和下一步

　　在4月21日测试Confluence / Atlassian的处理过程没有突然的波动（连同数据库的波动）的，是由于在运行的负载测试期间，移除了应用程序层定期执行的作业(job)。这个作业会影响到系统和用户体验，当Andreas审查他的数据，很快就确认出这个作业问题。一旦这个作业被确认是造成这个问题的元凶，4月21日测试时它就被移除掉了，完全消除了这个早在4月14日测试时遇到的性能瓶颈。

　　教训：不要在流量高峰期安排会影响系统的作业；找到流量最低的一个时间段，并在此时间段执行这些作业，以便尽可能最少的游客受到影响。

　　正如我们在这篇文章的开始说的，表面上看，4月21日的负载测试比4月14日的测试，更加成功。然而目前，尽管21日的负载测试性能表现有所提升，结果仍然显示出还有其他性能问题有待解决。问题表现在负载测试运行后90分钟，在09:40和09:50之??间，响应时间出现非常奇怪的波动。

　　当系统开始性能退化，它会体现在这3个关键指标：WLT平均响应时间；WLT每分钟的交易；CPU利用率。当正在运行的事务开始需要更长的时间来执行，同时网络到应用层请求数下降和测试工具中每分钟执行事务数下降，在下面的图表可以看到它的根本原因，此图去掉了一些数据(decreasing both the number of incoming web requests to the application layer and the number of transactions per minute executed by the load generation system, the root cause can be seen in the chart below, which removes some of the data series)。

　　当167个虚拟用户时，是系统的临界值，之后突然10分钟内性能下降，然后恢复后，测试稳定在200个虚拟用户（点击图片见大图）

　　在负载测试进行到09:40时，这个性能下降期间被检测出来，同时：

　　WLT工具达到167个虚拟用户

　　网络服务器的CPU使用率达到100％

　　WLT工具的每分钟事务数为平均130

　　Confluence的网络请求达到每分钟135次（这是APM社区网站的应用程序）

　　有趣的是，10分钟后，这个问题彻底消失了，除了事务响应时间。响应时间没有回到波动前的水平，而是现在的平均响应时间比波动前的平均值要高出近20秒。随着系统到了200个虚拟用户顶峰时，并没有额外的负载增加，看着其他指标立即回到波动前的水平 - 尤其是每分钟事务数和每分钟请求数，非常有趣。因此，波动后随着这33个虚拟用户增加，系统表现出又直接受到CPU瓶颈的影响，更高的负载并不能增加在应用程序层处理的请求数量。

　　抛开这些数据(Out of this sea of metrics)，我们看到的是对比4月14日的测试，4月21日的负载测试时程序性能变现的确有所提升，但第二轮测试仍无法达到预期目标 - 200个虚拟用户，存在一个瓶颈，导致性能急剧下降。

　　分析退化

　　要找到阻碍4月21日测试达到目标（200个虚拟用户并且没有或很少性能退化）的CPU瓶颈的根源，我们必须更深入一些，检查服务器端的指标，特别是那些和应用程序服务器的健康状态相关的指标。事务数下降是伴随系统出现的问题，当系统达到167个虚拟用户(The dip in transactions throughout the system is aligned with the issue captured when the system hit 167 VUs.)。现在的问题是：事务处理数下降和事务响应时间增加是这种负载下的结果？还是性能下降真正根源的一个症状？

　　服务器端的数据显示，高垃圾回收(Garbage Collection)可能是一个问题，因为当系统性能下降，这个自动的过程凑巧地也同时发生了。很显然，当网络服务器的CPU已经被耗尽时，再执行一个非常有影响的任务，会导致性能大幅下降。

　　当负载增加，GC的增加是正常的 - 但有一个不寻常的波动正是当我们看到的这个事务数量下降

　　检查在应用程序服务器具体的事务响应时间，很容易发现潜在问题。下面的图表显示，“又一个”后台作业依然在每隔一小时周期性地压榨已经被耗尽系统的CPU。

　　当虚拟用户经历性能下降时，后台作业每隔一小时执行一次，占用CPU的300S