我用过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应用程序，我发现由于线程之间的锁争用导致了巨大的性能问题……所以这个教训就是要仔细考虑锁定方案。我们最终让工作线程使用异步http处理程序来抑制太多的请求，否则应用程序就会不堪重负，崩溃并烧毁。这意味着大量的积压工作可能会堆积起来，但至少网站会继续运行。

我用过JMeter。除了测试web服务器，您还可以测试数据库后端，消息服务和电子邮件服务器。

看一下TestComplete。

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

我用过openSTA。

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

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

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

它是开源的，免费的。

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

这是给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.

我赞成开放的建议。我只想补充一点，它允许您使用SMTP来监视您正在测试的服务器。我们跟踪处理器负载、内存使用、发送的byes等等。唯一的缺点是，如果你发现某些东西有问题，想要修复它，它依赖于几个不再保持的开源库，所以获得源代码的编译版本比大多数OSS更棘手。

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

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

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

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

我试过WebLoad，它是一个很好用的工具。它带有一个测试脚本IDE，允许您记录用户在网站上的操作。当它在web服务器上执行压力测试时，它还会绘制一个图表。试试吧，我强烈推荐。

我玩JMeter。一个认为它不能不测试的是ASP。净Webforms。视图状态破坏了我的测试。我不知道为什么，但是有一些工具不能正确处理视图状态。我目前的项目是ASP。NET MVC和JMeter都能很好地与之配合。

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

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

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

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

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 :)

Visual Studio测试版2010(2008年也不错)。这是一个非常简单和强大的工具来创建web/负载测试。

在Windows服务器上使用此工具的好处是，您可以在报告中集成访问所有perfmon服务器统计信息。真的有用。

另一个好处是，在Visual Studio项目中，你可以集成一个“性能会话”来分析你网站的代码执行情况。

如果你在windows服务器上提供网页服务，这是最好的工具。

然而，使用多台机器来加载测试应用程序需要一个单独且昂贵的许可证。

为了简单的使用，我更喜欢ab(apache基准)和围攻，后来需要一个，因为ab不支持cookie，会从动态站点创建无休止的会话。

这两种方法都很简单:

ab -c n -t 30 url

siege -b -c n -t 30s url

围攻可以运行更多的网址。

最后一个攻城版本在攻城中打开啰嗦，这很烦人。您只能通过编辑该文件(/usr/local/etc/siegerc)来禁用它。

尝试了这里提到的所有方法，我发现卷曲加载器最适合我的目的。非常简单的界面，实时监控，有用的统计数据，从中我建立了性能图表。libcurl的所有特性都包含在内。

ab, siege, tsung, httperf，践踏，Pylot，请求日志分析器，perftools

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

我们已经开发了一个流程，将负载和性能测量视为头等重要的问题——正如你所说，把它留到项目的最后往往会导致失望……

因此，在开发过程中，我们包括非常基本的多用户测试(使用selenium)，它检查基本的疯狂问题，如中断的会话管理、明显的并发问题和明显的资源争用问题。重要的项目在持续集成过程中包含了这一点，所以我们得到了非常定期的反馈。

对于没有极端性能要求的项目，我们在测试中包含基本性能测试;通常，我们使用BadBoy编写测试脚本，并将它们导入JMeter，替换登录细节和其他线程特定的东西。然后我们将这些数据提升到服务器每秒处理100个请求的水平;如果响应时间小于1秒，通常就足够了。我们出发，继续我们的生活。

For projects with extreme performance requirements, we still use BadBoy and JMeter, but put a lot of energy into understanding the bottlenecks on the servers on our test rig(web and database servers, usually). There's a good tool for analyzing Microsoft event logs which helps a lot with this. We typically find unexpected bottlenecks, which we optimize if possible; that gives us an application that is as fast as it can be on "1 web server, 1 database server". We then usually deploy to our target infrastructure, and use one of the "Jmeter in the cloud" services to re-run the tests at scale.

同样，PAL报告有助于分析测试期间发生了什么—您经常会在生产环境中看到非常不同的瓶颈。

关键是要确保不只是运行压力测试，还要收集了解应用程序性能所需的信息。

这里提到了很多好的工具。我想知道工具是否可以回答这个问题:“如何对web应用程序进行压力测试?”这些工具并没有真正提供一种方法来强调Web应用程序。以下是我所知道的:

压力测试显示了Web应用程序如何在响应不断增加的用户数量时失败。压力测试显示Web应用程序在失败时如何运行。今天大多数Web应用程序——尤其是社交/移动Web应用程序——都是服务的集成。例如，当Facebook在2011年5月中断服务时，你无法登录Pepsi.com的Web应用程序。该应用程序并没有完全失败，只是用户无法使用它的大部分正常功能。

性能测试显示Web应用程序保持响应时间的能力，与有多少用户同时使用应用程序无关。例如，一个应用程序每秒处理10个事务，同时有10个并发用户，应该每秒处理20个事务，同时有20个用户。如果应用程序每秒处理的事务少于20个，那么响应时间就会变长，应用程序无法实现线性可伸缩性。

同样，在上面的例子中，每秒事务数应该仅仅是测试用例/工作流的成功操作。故障通常发生在较短的时间跨度内，这将使TPS测量过于乐观。失败对于压力和性能测试非常重要，因为它们也会在应用程序上产生负载。

我在TestMaker用户指南http://www.pushtotest.com/pushtotest-testmaker-6-methodology上写了PushToTest方法。TestMaker有两种版本:开源(GPL)社区版和TestMaker企业版(具有强大专业支持的商业版)。

弗兰克

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

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

冒着被指责为无耻的自我推销的风险，我想指出，在我寻求免费负载测试工具的过程中，我访问了这篇文章:http://www.devcurry.com/2010/07/10-free-tools-to-loadstress-test-your.html

要么我无法获得我想要的吞吐量，要么我无法获得我想要的灵活性。并且我想在测试后分析中轻松地聚合多个负载测试生成主机的结果。

我尝试了清单上的每一种工具，但令我沮丧的是，它们没有一种完全符合我的要求。所以我做了一个，并分享它。

这里是:http://sourceforge.net/projects/loadmonger

PS:熟悉城市俚语的人不会对这个名字做出恶意评论。我以前不是，但现在更世故了。

对于基于web的服务，请查看loader.io。

简介:

加载程序。IO是一个免费的负载测试服务，允许你用数千个并发连接来测试你的web应用程序/api。

它们也有一个API。

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

好消息是，在过去的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美元，就可以获得非常接近真实用户体验的负载。

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

Blaze meter有一个chrome扩展，用于记录会话并将其导出到JMeter(目前需要登录)。你也可以选择付钱让他们在他们的JMeter服务器集群上运行(他们的定价似乎比我刚刚停止使用的LoadImpact要好得多):

BlazeMeter Chrome扩展 关于它的博客条目

我和他们没有任何联系，我只是喜欢他们服务的外观，尽管我还没有用过付费版本。

我们最近开始使用Gatling进行负载测试。我强烈推荐使用这个工具进行负载测试。我们过去使用过SOASTA和JMETER。我们考虑加特林的主要原因如下:

记录仪对场景进行记录 使用Akka和Netty相比性能更好 Jmeter线程模型 DSL Scala相比Jmeter XML更易于维护 编写测试很容易，如果是scala也不用害怕。 报告

让我给你一个简单的例子来写代码使用加特林代码:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

但是你可以让它越复杂越好。加特林的突出特点之一是报告非常详细。

以下是一些链接: 加特林 加特林教程

我最近做了一个关于它的演讲，你可以在这里看一下: https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with-Gatling.pdf

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

看看LoadBooster(https://www.loadbooster.com)。它利用无头脚本浏览器PhantomJS/CasperJs来测试网站。Phantomjs将解析和渲染每个页面，执行客户端脚本。无头浏览器方法更容易编写测试场景，以支持复杂的AJAX重载Web 2.0应用程序、浏览器导航、鼠标单击和对浏览器的击键，或者等待DOM中存在元素。LoadBooster也支持硒HTML脚本。

免责声明:我为LoadBooster工作。

我也投票给jMeter，我想在@PeterBernier的回答中添加一些引用。

负载测试回答的主要问题是有多少并发 我的web应用程序可以支持哪些用户?为了得到正确的答案， 负载测试应该代表真实的应用程序使用情况，接近于 可能的。

请记住，jMeter有许多构建块逻辑控制器，配置元素，预处理器，监听器，…这对你有帮助。

你可以模仿真实世界的情况与jMeter，例如，你可以:

Configure jMeter to act as real Browser by configuring (concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding , ajax support ,... ) Configure jMeter to generate user requests (by defining number of users per second, ramp-up time, scheduling ,...) Configure lots of client with jMeter on them, to do a distributed load test. Process response to find if the server is responding correctly during test. ( For example assert response to find a text in it)

请考虑:

It is easy to start a real web application test with jMeter in minutes. The jMeter has a very easy tool which record your test scenario ( know as HTTP(S) Test Script Recorder). jMeter has lots of plugins at http://jmeter-plugins.org. The jMeter UI is swing based and has made good changes in jMeter 3.2. On the other hand please consider that JMeter GUI should only be used for test and debugging. It is not good practice to use it in GUI mode for actual test. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui. Configure and test your scenario and run it on non-gui mode. The are lots of reporting showing tools in jMeter (Known as listeners) but there are not meant to be on during test. You must run your test and generate reports ( .jtl files). Then you must use these tools to analyze result. Please have a look at https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats or https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm.

https://www.blazemeter.com/jmeter提供了非常有用的信息，可以帮助您配置测试环境。