在过去,我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。

只要让少数开发人员在主页上使劲敲一下,就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面,甚至更多——在发布之后。

我使用的工具的URL是Microsoft Homer(又名Microsoft Web Application Stress Tool)和Pylot。

这些工具生成的报告对我来说没有多大意义,我花了很多时间试图弄清楚站点能够支持什么样的并发负载。这总是值得的,因为最愚蠢的错误和瓶颈总是会出现(例如,web服务器配置错误)。

你做了什么,你使用了什么工具,你的方法有什么成功?对我来说,最有趣的部分是提出某种有意义的公式,用于从压力测试应用程序报告的数字中计算应用程序可以支持的并发用户数。


当前回答

我发现IBM Page Detailer也是一个有趣的工具。

其他回答

此外,还有一个很棒的开源纯python分布式和可伸缩的locust框架,它使用了greenlets。它很擅长模拟大量同时使用的用户。

我使用FunkLoad获得了不错的结果:

易于编写用户交互脚本 报告很清楚 可以监视服务器负载

尝试ZebraTester,它比jMeter更容易使用。我已经使用jMeter很长一段时间了,但是负载测试的总设置时间总是一个问题。虽然ZebraTester不是开源的,但我在过去六个月节省的时间弥补了它。他们还有一个SaaS门户,可以使用他们的负载生成器快速运行测试。

来这个派对有点晚了。我同意Pylot是目前最好的开源工具。它使用简单,是由一个伟大的人(科里·戈德堡)积极工作。作为OpenQA的创始人,我也很高兴Pylot现在被列在了我们的主页上,并使用了我们的一些基础设施(即论坛)。

然而,我最近也认为负载测试的整个概念是有缺陷的:在应用程序变得如此复杂的情况下,模拟HTTP流量是一件令人痛苦的事情。这就是我创建商业工具BrowserMob的原因。它是一个外部负载测试服务,在回放负载时使用Selenium来控制真实的web浏览器。

与正常的负载测试技术相比,这种方法显然需要更多的硬件,但在使用云计算时,硬件实际上相当便宜。这样做的一个很好的副作用是编写脚本比普通的负载测试容易得多。你不需要做任何高级的正则表达式匹配(就像JMeter要求的那样)来提取cookie、. net会话状态、Ajax请求参数等等。因为您使用的是真正的浏览器,所以它们只是做它们应该做的事情。

很抱歉公然推销一个商业产品,但希望这个概念对一些人来说是有趣的,至少让他们考虑一些新的方法来处理负载测试,当您有一堆额外的硬件时!

我用过openSTA。

这允许与网站的会话被记录,然后通过相对简单的脚本语言回放。

您可以轻松地测试web服务并编写自己的脚本。

它允许您以任何您想要的方式将脚本放在一个测试中,并配置迭代的数量、每次迭代中的用户数量、引入每个新用户的递增时间以及每次迭代之间的延迟。将来还可以安排测试。

它是开源的,免费的。

它生成了许多报告,这些报告可以保存到电子表格中。然后,我们使用数据透视表来方便地分析和绘制结果。