Question

上下文

我们希望使用“重播”Web服务器访问日志来生成负载测试。我想起了JMeter，因为我最近阅读了关于在云中使用jmeter的博客文章（例如，启动了一些Amazon EC2实例来生成负载）

多年来，我听说过JMeter重播访问日志的能力，但在审核此功能时，我发现了以下内容。

Access Log Sampler

DOES：
- 重新创建会话，即处理jsessionId令牌（认为它尝试通过IP地址估算会话数）;
不要：
- 处理POST数据（即使您可以配置apache / tomcat将后期数据写入访问日志，jmeter访问日志采样器只处理'常见'日志格式）。

发布数据对于重建实际负载会有很长的路要走。

此外，该文档将访问日志采样器描述为“alpha代码”，即使它已有8年历史。它似乎没有积极维护。（这比Gmail的测试版要长。）

HttpPerf

另一篇博客文章向我指出了httpperf工具。我已经开始阅读它了：

博客：http://www.igvita.com/2008/09/30/load-testing-with-log-replay/
httpperf：http://code.google.com/p/httperf/

摘要

从真实用户数据生成负载测试“脚本”的最佳方法是什么？
最适合你的是什么？
各种工具的优点和缺点？

Answer 1

JMeter + HTTP原始请求+原始数据源对我来说效果很好

Answer 2

我将介绍如何使用名为Yandex Tank的LT工具解决此问题它可以处理简单的access.log，但也只能处理'GET'请求。当需要发出其他类型的请求时，我们使用其他弹药格式（ammo是一个包含我们要发送给服务器的所有请求的文件）。例如：

342
POST / HTTP/1.1^M
Host: xxx.xxx.xxx.xxx:8080^M
Connection: keep-alive^M
Keep-Alive: 300^M
Content-Type: multipart/form-data; boundary=AGHTUNG^M
Content-Length: 1400^M
Connection: Close^M
^M
--AGHTUNG^M
Content-Disposition: form-data; name="fp"; filename="fp_tank"^M
Content-Type: application/octet-stream^M
Content-Transfer-Encoding: binary^M
...
--AGHTUNG--^M

第一行的数字（'342'）是后续请求的大小。请求是原始格式。您可以用您喜欢的语言编写一个简单的脚本，从access.log生成这样的弹药文件，然后将其用于负载测试。

这种弹药格式使其非常灵活。例如，this代码从FCGI日志生成弹药（POST主体在Base64中编码）。但另一方面，您需要手动处理会话。

Answer 3

您可以使用ZebraTester轻松地使用POST 数据重播访问日志。它有许多类似于JMeter的插件，并且还能够添加内联脚本，您可以使用这些脚本轻松地从访问日志中定位POST有效负载，URL，时间戳等。您可以直接从本地工具运行负载测试，或将录制的脚本复制到SaaS portal以运行大量的虚拟用户负载测试

访问日志重放进行负载测试？ Jmeter陷阱和竞争对手

3 个答案: