对 Web Flow 应用程序进行负载测试与其他 Web 应用程序的负载测试类似——我们将使用负载测试工具来模拟不断增加的并发客户端访问级别，以捕获关键的性能统计数据。

在使用 Web Flow 时，负载测试有几个重要的考虑因素：

1. 负载测试必须维护独立的“Cookie 存储区域”，以便每个客户端请求都可以携带独立的 HTTP 会话。
2. 我们需要一种机制来从初始响应中提取唯一的 Flow Execution Key，并将其用于自定义同一 Flow 会话中的后续请求。

Apache JMeter 是一个开源的性能测试工具，可以满足以上两个考虑因素。

对于 1)，我们在每个测试组的根目录下添加一个 HTTP Cookie 管理器（HTTP Cookie Manager）来执行 Web Flow 功能。Cookie 管理器确保每个模拟客户端请求都有自己独立的 Cookie，与其他客户端请求无关，从而允许 Servlet 容器通过 jsessionid Cookie 来跟踪独立的 HTTP 会话。

对于 2)，我们在启动流程的 HTTP 请求元素（HTTP Request Element）之后立即添加一个正则表达式提取器（Regular Expression Extractor）。该提取器的目的是解析 HTTP 响应，使用我们提供的正则表达式定位特定的文本，并将其作为变量提供给后续的 HTTP 请求元素使用。下面是正则表达式提取器的一个配置示例：

引用名称（Reference Name）：flowExecutionKey 正则表达式（Regular Expression）：name="_flowExecutionKey" value="(.*)" 模板（Template）：$1$ 匹配编号（Match No.）：0

使用上述配置后，我们就可以在后续属于同一流程会话的 HTTP 请求元素中嵌入变量 ${flowExecutionKey} 了。

现在，我们用它来对 Web Flow 进行负载测试。为了正确地执行具有代表性的 Web Flow 功能，我创建了一个示例 Web Flow 应用程序，模拟了一个包含 6 个步骤的购物车流程，收集用户的送货地址、配送选项、信用卡信息、账单地址、订单确认信息，以及最后的订单摘要。该流程中的各个步骤包括数据绑定和验证、视图状态（view states）、动作状态（action states）、决策状态（decision states）以及子流程状态（sub-flow states）——这些都是我们在典型的 Web Flow 应用程序中会期望找到的东西。然而，该应用程序使用了存根（stubs）而不是实际的数据库访问代码，以避免在整体统计数据中包含这些数字。在此测试中，我们希望只关注 Web Flow 本身。

构建应用程序并创建 JMeter 脚本后，我添加了一个聚合报告（Aggregate Report）元素，用于记录不同负载水平下测试的性能统计数据。

在我的运行 Ubuntu 的联想 T60 双核笔记本电脑上，使用 Apache Tomcat 5.5 作为 Servlet 容器，并配置为最多支持 150 个并发连接，我观察到了以下结果：

实际的负载测试应该在真实的硬件上，并且基于真实的用例进行。没有其他方法可以替代。然而，我们可以从上述数字中得出一些结论。

上述数字表明，在执行核心 Web Flow 功能时，即使并发用户数显著增加，吞吐量仍然保持稳定。90% 用户的响应时间保持在一秒以内。最差的响应时间会随着负载的增加而上升，但考虑到用于测试的硬件不足，这并不令人意外。

使用上述技术，您可以对自己的 Web Flow 应用程序进行负载测试。

swf-shoppingcart-regexp.txt