检查这些事务，该作业是每小时执行的更新作业，同步缓存的用户对象以及用户目录数据库(user directory database)。这需要相当长的也值得重视的时间，因为我们APM社区系统中有65000多个用户。该更新的作业导致了很多对象的创建和销毁 - 因此增加的内存和GC活动。

　　同步作业是性能下降的根本原因，导致高GC活动，消耗了大量的CPU以及增加内存分配

　　通过4月14日，4月21日的两轮负载测试，找出系统无达到200虚拟用户目标的不少的问题。但是现在，我们知道阻碍达成这个目标的罪魁祸首，因此努力在高负载下，集中精力减少或消除此更新作业对系统的影响。

　　结论

　　在这两轮测试中，无论你是如何衡量“成功的”负载测试，通过汇总测试中内部和外部硬件的指标，我们现在知道，4月14日的负载测试之后进行的调优，使得系统在预定作业会导致了严重性能下降的情况下，能够每分钟处理额外40%~50%的事务，支持多达167个虚拟用户。

　　只有有了这个数据才能转为可操作项，因为我们有一个程序能将防火墙内部采集到的数据，很轻松地整合外部负载测试工具的结果数据。这样，尽管是在非常受控的情况，也成为分析系统性能的一个因素。(This data was only able to be turned into actionable information because we had a process in place that allowed results captured from inside the firewall to be easily aligned with the external results from the load test system. By doing this, the customer, albeit in a very controlled form, becomes a factor in the analysis of system performance.)

　　通过创建一个完整的性能角度，PureStack比只提供负载下系统技术指标的，提供得更多。当进行结果分析时，PureStack视用户体验的重要性如CPU，数据库和应用程序处理请求数一般。根据用户体验的重要性，然后决定如何划分问题的优先级和如何解决他们。这些对最终用户有影响的问题提供了真实世界的反馈 - 您的应用程序在峰值期间所出现性能问题的真实成本(The importance of the user experience then dictates how infrastructure issues are prioritized and resolved, as the effect these issues have on end users provides real-world feedback into the true cost of performance issues that occur to your application during peak periods)。

　　根据负载测试中的数据，可以确定系统需要的额外修改，特别是页面呈现方面，需要进一步降低CPU负荷，使系统能够达到和保持负载峰值为200的虚拟用户。随着Confluence应用软件的升级 - 2013年7月初部署的程序 - 达到预期的目标。但假设这是不够的，一旦系统已经稳定运行，2013年7月将会有对新Confluence系统的额外负载测试。并且通过使用4月14日和21日的负载测试中同样事务的路径，将对新系统进行验证，以确认升级能带来所期望的性能表现。

版权声明：本文出自 在劫录 的51Testing软件测试博客：http://www.51testing.com/?166582

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。