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

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

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

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

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

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

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

我用过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).

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

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

我们最近开始使用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

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

因此，在开发过程中，我们包括非常基本的多用户测试(使用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报告有助于分析测试期间发生了什么—您经常会在生产环境中看到非常不同的瓶颈。

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