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

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

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

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

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


当前回答

这是一个老问题,但我认为新的解决方案值得一提。Checkout LoadImpact: http://www.loadimpact.com。

其他回答

这是给JMeter的另一票。

JMeter是一个开源的负载测试工具,用Java编写。它能够测试许多不同的服务器类型(例如,web, web服务,数据库,基本上使用请求的任何东西)。

然而,一旦你开始面对复杂的测试,它确实有一个陡峭的学习曲线,但它是非常值得的。您可以非常快速地启动并运行,这取决于您想要进行哪种类型的压力测试,这可能没问题。

优点:

Open-Source/Free tool from the Apache project (helps with buy-in) Easy to get started with, and easy to use once you grasp the core concepts. (Ie, how to create a request, how to create an assertion, how to work with variables etc). Very scalable. I've run tests with 11 machines generating load on the server to the tune of almost a million hits/hour. It was much easier to setup than I was expecting. Has an active community and good resources to help you get up and running. Read the tutorials first and play with it for a while.

缺点:

The UI is written in Swing. (ugh!) JMeter works by parsing the response text returned by the server. So if you're looking to validate any sort of javascript behaviours, you're out of luck. Learning curve is steep for non-programmers. If you're familiar with regular expressions, you're already ahead of the game. There are large numbers of (insert expletive) idiots in the support forum asking stupid questions that could be easily solved if they'd give the documentation even a cursory glance. ('How do I use JMeter to stress-test my Windows GUI' shows up quite frequently). Reporting 'out of the box' leaves much to be desired, particularly for larger tests. In the test I mentioned above, I ended up having to write a quick console app to do some of the 'xml-logfile' to 'html' conversions. That was a few years ago though, so it's probable that this would no longer be required.

我用过Grinder。它是开源的,非常容易使用,并且非常可配置。它是基于Java的,脚本使用Jython。我们在一个。net web应用程序上运行了它,所以不要认为它只是一个Java工具(从本质上讲,任何web压力工具都不应该与它所使用的平台绑定)。

We did some neat stuff with it... we were a web based telecom application, so one cool use I set up was to mimick dialing a number through our web application, then used an auto answer tool we had (which was basically a tutorial app from Microsoft to connect to their RTC LCS server... which is what Microsoft Office Communicator connects to on a local network... then modified to just pick up calls automatically). This then allowed us to use this instead of an expensive telephony tool called The Hammer (or something like that).

无论如何,我们还使用该工具来查看应用程序在高负载下的运行情况,它在查找瓶颈方面非常有效。该工具内置了报告,以显示请求花费的时间,但我们从未使用过它。日志还可以存储所有响应或自定义日志。

我强烈推荐这个工具,非常有用的价格…但是期望用它做一些自定义设置(它有一个内置的代理来记录脚本,但它可能需要自定义来捕获会话之类的东西……我知道我必须自定义它以利用每个线程的唯一会话)。

我们使用提到的微软工具——微软Web应用程序压力工具。这是我用过的最简单的工具。它在许多方面都受到限制,包括只能在手动创建的测试中命中端口80。但是,它的易用性意味着它确实被使用了。

我们用其他工具(包括OpenSTA和链接检查蜘蛛)来补充这个工具的负载。

从我的初步评估来看,JMeter看起来不错,我希望它能包括在我们未来的持续集成中。但是,JMeter是复杂的,推出起来并不简单。

我建议提出另一个关于解释MS压力工具结果的问题。

You asked this question almost a year ago and I don't know if you still are looking for another way of benchmarking your website. However since this question is still not marked as solved I would like to suggest the free webservice LoadImpact (btw. not affiliated). Just got this link via twitter and would like to share this find. They create a reasonable good overview and for a few bucks more you get the "full impact mode". This probably sounds strange, but good luck pushing and braking your service :)

既然这个问题还没有解决,我不妨发表一下看法。

好消息是,在过去的5年左右的时间里,开源工具已经真正成熟并在这个领域起飞了,坏消息是还有很多这样的工具。

以下是我的想法:-

Jmeter vs Grinder

Jmeter是由XML样式规范驱动的,该规范是通过GUI构造的。

Grinder在多线程Java框架中使用Jython脚本,因此更面向程序员。

这两个工具都可以处理HTTP和HTTPS,并有一个代理记录器让您开始。 这两种工具都使用Controller模型来驱动多个测试代理,因此可伸缩性不是问题(给定对云的访问)。

哪个更好:-

这是一个艰难的呼叫,因为使用这两种工具的学习曲线是陡峭的,因为您进入了更复杂的脚本需求,如url重写、相关性、为每个虚拟用户提供唯一数据以及模拟第一次或返回用户(通过操作HTTP头)。

也就是说,我会从Jmeter开始,因为这个工具有很多追随者,网上有很多使用这个工具的例子和教程。如果和当你遇到一个“路障”,这是你不能“轻易”用Jmeter做的事情,然后看看Grinder。好消息是,这两个工具都有相同的Java需求,“混合搭配”解决方案也不是不可能。

添加了一些新的东西——运行多个Selenium WebDriver实例的无头浏览器。

这是一种相对较新的方法,因为它依赖于现在可以从云中提供的资源的可用性。使用这种方法,一个Selenium (WebDriver)脚本在多线程的无头浏览器(即WebDriver = New HtmlUnitDriver())驱动程序中运行。

根据经验,亚马逊M1小实例可以执行大约25个“无头浏览器”实例。

这意味着,当您将功能测试脚本重新定位为性能测试脚本时,所有的相关性、url重写问题都将消失。

与Grinder或Jmeter等HTTP驱动程序相比,由于需要更多的虚拟机来驱动负载,因此可伸缩性受到了影响。也就是说,如果你想要驱动500个虚拟用户,那么使用20个亚马逊小实例(每个实例每小时6美分),每小时只需1.20美元,就可以获得非常接近真实用户体验的负载。