负载测试方法

　　启动一个性能调优实践的先决条件是创建一整套合适的负载测试集合。每一个负载测试必须满足以下两点：

　　•代表性，必须体现最终用户的业务场景（或期望的场景）

　　•均衡性，必须符合最终用户不同行为的比例分配

　　也就是说，负载必须能够按照最终用户的实际操作比例来模拟用户动作。为了说明均衡最终用户动作的重要性，请看下面这个例子：在保险索赔部门，员工执行以下操作：

　　1.用户上午八点登陆系统。

　　2.上午每人平均处理五个索赔请求。

　　3.大约80%的用户忘记在吃饭之前注销账号，导致session过期。

　　4.午饭后，用户重新登录系统。

　　5.下午每人平均处理五个索赔申请。

　　6.下班之前生成两个报告。

　　7.80%的用户回家前注销账号。

　　如果负载生成器把压力均匀分布在不同的服务请求上又会怎么样呢？在本例中，用户登陆和注销功能会接收与处理与理赔请求相同的负载。如果是1000个并发用户，登陆功能会很快崩溃，导致企业投资建立一个能够处理这种负载的登陆组件，而实际上这种负载根本不会发生。更糟糕的是，本例中由于最大的瓶颈看似存在于登陆功能上，所以调优的努力会侧重该功能，而忽视索赔处理功能。总之，一个非均衡的负载可能导致调优过程错误的关注于支持那些绝不会发生的负载的组件，而不是那些真正需要调优的部分！

　　判断一个负载对于应用是均衡的和代表性的标准，对于测试一个已存在的应用（或者一个新版本）还是一个全新的应用是不同的。

　　已存在应用

　　已存在应用跟一个全新应用相比，一个明显的优点是：真实的用户行为可以在实际生产环境中观察获得。根据请求的本质和它们如何被应用定义，可以通过两个选择定义最终用户行为：

　　•访问日志

　　•最终用户体验监视器

　　对于大多数基于web的应用来说，访问日志提供了足够的资源分析服务请求的本质和它们的均衡关系。

　　Web服务器可以配置成抓取最终用户请求信息并存储在一 个日志文件中，称之为“访问日志”（因为该文件通常命名为“access.log”）。使用访问日志定位用户行为的关键是应用交互需要能够通过不同的 URI来区分。例如，如果之前例子的动作采用类似“/login.do”、“/processClaim.do”、“/logout.do”的URI，那 么我们可以非常容易的在访问日志中发现这些行为并确定它们的比例。更进一步，通过最频繁的URI来排序访问日志可以快速发现占比例前n%的的若干请求，这 个“n”%应该在80%左右。

　　访问日志是文本文件，可以手动检查（不是一个很有效率的任务），可以通过编程解析，也可以通过工具来分析。对此有很多商业解决方案，不过Quest Software有一个产品Funnel Web Analyzer，虽然多年以前已经终止开发，但是由于其很受欢迎的命令，公司就作为将其作为自由软件重新发布。Funnel Web Analyzer可以分析大多数访问日志并显示用于创建合适负载测试的信息。

　　一些应用不像上面提到的那样简单，其用户交互无法很容易的通过一个URI来定位。例如，考虑一个包含前端控制器servlet的应用，该servlet接受一个XML有效信息——并且其业务处理逻辑就存在于该信息中。在本例中，需要另外的工具来侦测其有效信息以判断其符合哪个业务场景。这可以通过使用 servlet过滤器或者一个称为最终用户体验监视器的硬件设备来完成。

　　不管用户行为是如何获得的，它都是开始任何性能调优实践之前的关键先决条件。