过去，我使用 Microsoft Web Application Stress Tool 和 Pylot 对 Web 应用程序进行压力测试。 我编写了一个简单的主页、登录脚本和网站演练（在电子商务网站中将一些商品添加到购物车并结账）。
只要与少数开发人员一起努力打开主页，几乎总能找到主要问题。 更多的可扩展性问题将在第二阶段出现，甚至在发布后还会出现更多。
我使用的工具的 URL 是 Microsoft Homer（又名 Microsoft Web 应用程序压力工具）和 Pylot。
这些工具生成的报告对我来说从来没有多大意义，我会花费很多时间试图弄清楚该站点能够支持哪种并发负载。 这总是值得的，因为最愚蠢的错误和瓶颈总是会出现（例如，Web 服务器配置错误）。
您做了什么，使用了哪些工具，以及您的方法取得了哪些成功？ 对我来说最有趣的部分是提出某种有意义的公式，用于根据压力测试应用程序报告的数字来计算应用程序可以支持的并发用户数。
In the past, I used Microsoft Web Application Stress Tool and Pylot to stress test web applications. I'd written a simple home page, login script, and site walkthrough (in an ecommerce site adding a few items to a cart and checkout).
Just hitting the homepage hard with a handful of developers would almost always locate a major problem. More scalability problems would surface at the second stage, and even more - after the launch.
The URL of the tools I used were Microsoft Homer (aka Microsoft Web Application Stress Tool) and Pylot.
The reports generated by these tools never made much sense to me, and I would spend many hours trying to figure out what kind of concurrent load the site would be able to support. It was always worth it because the stupidest bugs and bottlenecks would always come up (for instance, web server misconfigurations).
What have you done, what tools have you used, and what success have you had with your approach? The part that is most interesting to me is coming up with some kind of a meaningful formula for calculating the number of concurrent users an app can support from the numbers reported by the stress test application.
发布评论
评论（30）
您大约一年前问过这个问题，我不知道您是否仍在寻找另一种方法来对您的网站进行基准测试。 然而，由于这个问题仍未标记为已解决，我想建议免费的网络服务 LoadImpact （顺便说一句。不附属）。 刚刚通过 Twitter 获得此链接，并希望分享此发现。 它们创建了一个合理的良好概述，并且只需多花几美元，您就可以获得“全面影响模式”。 这可能听起来很奇怪，但祝你好运，推动和制动你的服务:)
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 :)
我使用过The Grinder。 它是开源的，非常易于使用，并且非常可配置。 它基于 Java，并使用 Jython 作为脚本。 我们针对 .NET Web 应用程序运行了它，因此不要认为它只是一个 Java 工具（就其本质而言，任何 Web 压力工具都不应该与其使用的平台绑定）。
我们用它做了一些巧妙的事情...我们是一个基于网络的电信应用程序，所以我设置的一个很酷的用途是通过我们的网络应用程序模仿拨号，然后使用我们拥有的自动应答工具（这基本上是一个教程） Microsoft 的应用程序连接到他们的 RTC LCS 服务器...这是 Microsoft Office Communicator 在本地网络上连接的服务器...然后修改为自动接听电话）。 这样我们就可以使用它来代替昂贵的电话工具“The Hammer”（或类似的东西）。
无论如何，我们还使用该工具来查看我们的应用程序在高负载下的表现，并且它对于查找瓶颈非常有效。 该工具内置了报告来显示请求花费的时间，但我们从未使用过它。 日志还可以存储所有响应等，或自定义日志记录。
我强烈推荐这个工具，对于价格来说非常有用......但期望用它进行一些自定义设置（它有一个内置代理来记录脚本，但它可能需要自定义来捕获会话之类的东西......我知道我必须对其进行自定义以利用每个线程的唯一会话）。
I've used The Grinder. It's open source, pretty easy to use, and very configurable. It is Java based and uses Jython for the scripts. We ran it against a .NET web application, so don't think it's a Java only tool (by their nature, any web stress tool should not be tied to the platform it uses).
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).
Anyways, we also used the tool to see how our application held up under high load, and it was very effective in finding bottlenecks. The tool has built in reporting to show how long requests are taking, but we never used it. The logs can also store all the responses and whatnot, or custom logging.
I highly recommend this tool, very useful for the price... but expect to do some custom setup with it (it has a built in proxy to record a script, but it may need customization for capturing something like sessions... I know I had to customize it to utilize a unique session per thread).
冒着被指责无耻自我推销的风险，我想指出，在寻求免费负载测试工具时，我阅读了这篇文章：http://www.devcurry.com/2010/07/10-free-tools-to-loadstress-test-your .html
要么我无法获得我想要的吞吐量，要么我无法获得我想要的灵活性。 我想在测试后分析中轻松聚合多个负载测试生成主机的结果。
我尝试了列表中的每一个工具，但令我沮丧的是，它们都没有完全达到我想要的效果。 所以我建造了一个并分享它。
这是： http://sourceforge.net/projects/loadmonger
PS：没有关于名称的讽刺评论来自熟悉城市俚语的人。 我以前不是，但现在稍微世俗了一些。
At the risk of being accused of shameless self promotion I would like to point out that in my quest for a free load testing tool I went to this article: http://www.devcurry.com/2010/07/10-free-tools-to-loadstress-test-your.html
Either I couldn't get the throughput I wanted, or I couldn't get the flexibility I wanted. AND I wanted to easily aggregate the results of multiple load test generation hosts in post test analysis.
I tried out every tool on the list and to my frustration found that none of them quite did what I wanted to be able to do. So I built one and am sharing it.
Here it is: http://sourceforge.net/projects/loadmonger
PS: No snide comments on the name from folks who are familiar with urban slang. I wasn't but am slightly more worldly now.
我使用 FunkLoad 得到了很好的结果：
I had good results with FunkLoad :
我赞同 opensta 的建议。 我只想补充一点，它允许您使用 SMTP 来监视正在测试的服务器。 我们跟踪处理器负载、使用的内存、发送的再见等。唯一的缺点是，如果您发现某些东西损坏并想要进行修复，那么它依赖于几个不再保留的开源库，因此需要进行编译源版本比大多数 OSS 更棘手。
I second the opensta suggestion. I would just add that it allows you to do things to monitor the server you're testing using SMTP. We keep track of processor load, memory used, byes sent, etc. The only downside is that if you find something boken and want to do a fix it relies on several open-source libraries that are no longer kept up, so getting a compiling version of the source is more tricky than with most OSS.
我们使用提到的微软工具——Microsoft Web Application Stress Tool。 这是我用过的最简单的工具。 它在很多方面受到限制，包括只能在手动创建的测试中访问端口 80。 但是，它的易用性意味着它确实得到了使用。
我们使用 OpenSTA 和链接检查蜘蛛等其他工具来补充该工具的负载。
从我最初的评估来看，JMeter 看起来不错，我希望将其包含在我们未来的持续集成中。 但是，JMeter 的推出非常复杂且不易。
我建议提出另一个关于解释 MS 压力工具结果的问题。
We use the Microsoft tool mentioned - Microsoft Web Application Stress Tool. It is the easiest tool I have used. It is limited in many ways, including only being able to hit port 80 on manually created tests. But, its ease of use means it actually gets used.
We supplement the load from this tool with other tools including OpenSTA and link check spiders.
JMeter looks good from my initial evaluation, I hope to include it in our continuous integration going forward. But, JMeter is complex and non trivial to roll out.
I'd suggest opening another question regarding interpreting the MS stress tool results.
Visual Studio 测试版 2010（2008 也不错）。 这是一个非常简单且功能强大的工具，可以用来创建网络/负载测试。
针对 Windows 服务器使用此工具的好处是，您可以集成访问报告中的所有 perfmon 服务器统计信息。 真的很有用。
另一个好处是，通过 Visual Studio 项目，您可以集成一个“性能会话”，该会话将分析您网站的代码执行情况。
如果您从 Windows 服务器提供网页，那么这是最好的工具。
然而，使用多台机器对应用程序进行负载测试需要单独且昂贵的许可证。
Visual Studio Test Edition 2010 (2008 good too). This is a really easy and powerful tool to create web/load tests with.
The bonus with this tool when using against Windows servers is that you get integrated access to all the perfmon server stats in your report. Really useful.
The other bonus is that with Visual Studio project you can integrate a "Performance Session" that will profile the code execution of your website.
If you are serving webpages from a windows server, this is the best tool out there.
There is a separate and expensive licence required to use several machines to load test the application however.
我发现 IBM Page Detailer 也是一个有趣的工具。
I found IBM Page Detailer also an interesting tool to work with.
我用过 openSTA。
这允许记录与网站的会话，然后通过相对简单的脚本语言进行回放。
您可以轻松测试 Web 服务并编写自己的脚本。
它允许您以任何您想要的方式将脚本放在测试中，并配置迭代次数、每次迭代中的用户数量、引入每个新用户的启动时间以及每次迭代之间的延迟。 测试也可以安排在未来。
它是开源且免费的。
它会生成许多可以保存到电子表格中的报告。 然后，我们使用数据透视表轻松分析结果并绘制图表。
I've used openSTA.
This allows a session with a web site to be recorded and then played back via a relatively simple script language.
You can easily test web services and write your own scripts.
It allows you to put scripts together in a test in any way you want and configure the number of iterations, the number of users in each iteration, the ramp up time to introduce each new user and the delay between each iteration. Tests can also be scheduled in the future.
It's open source and free.
It produces a number of reports which can be saved to a spreadsheet. We then use a pivot table to easily analyse and graph the results.
我尝试过 WebLoad 它是一个非常简洁的工具。 它附带测试脚本 IDE，允许您记录网站上的用户操作。 当它在您的网络服务器上执行压力测试时，它还会绘制一个图表。 尝试一下，我强烈推荐它。
I tried WebLoad it's a pretty neat tool. It comes with and test script IDE which allows you to record user action on a website. It also draws a graph as it perform stress test on your web server. Try it out, I highly recommend it.
这是一个老问题，但我认为更新的解决方案值得一提。 查看 LoadImpact：http://www.loadimpact.com。
This is an old question, but I think newer solutions are worthy of a mention. Checkout LoadImpact: http://www.loadimpact.com.
我们开发了一个流程，将负载和性能测量视为首要关注点 - 正如您所说，将其留到项目结束往往会导致失望......
因此，在开发过程中，我们包括非常基本的多用户测试（使用selenium），检查基本的疯狂问题，例如损坏的会话管理、明显的并发问题和明显的资源争用问题。 重要的项目将其纳入持续集成过程中，因此我们会定期收到反馈。
对于没有极端性能要求的项目，我们的测试中包含了基本的性能测试； 通常，我们使用 BadBoy 编写测试脚本，并将它们导入 JMeter，替换登录详细信息和其他特定于线程的内容。 然后，我们将其提升到服务器每秒处理 100 个请求的水平； 如果响应时间小于 1 秒，通常就足够了。 我们开始并继续我们的生活。
对于性能要求极高的项目，我们仍然使用 BadBoy 和 JMeter，但投入大量精力来了解测试平台上服务器（通常是 Web 和数据库服务器）的瓶颈。 有一个很好的分析 Microsoft 事件日志的工具，它对此有很大帮助。 我们通常会发现意想不到的瓶颈，如果可能的话我们会对其进行优化； 这为我们提供了一个在“1 个 Web 服务器、1 个数据库服务器”上尽可能快的应用程序。 然后，我们通常会部署到目标基础设施，并使用“云中的 Jmeter”服务之一大规模重新运行测试。
同样，PAL 报告有助于分析测试期间发生的情况 - 您经常会在生产环境中看到截然不同的瓶颈。
关键是确保您不仅运行压力测试，而且还收集了解应用程序性能所需的信息。
We have developed a process that treats load and performance measurenment as a first-class concern - as you say, leaving it to the end of the project tends to lead to disappointment...
So, during development, we include very basic multi-user testing (using selenium), which checks for basic craziness like broken session management, obvious concurrency issues, and obvious resource contention problems. Non-trivial projects include this in the continuous integration process, so we get very regular feedback.
For projects that don't have extreme performance requirements, we include basic performance testing in our testing; usually, we script out the tests using BadBoy, and import them into JMeter, replacing the login details and other thread-specific things. We then ramp these up to the level that the server is dealing with 100 requests per second; if the response time is less than 1 second, that's usually sufficient. We launch and move on with our lives.
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.
Again, PAL reports help to analyze what happened during the tests - you often see very different bottlenecks on production environments.
The key is to make sure you don't just run your stress tests, but also that you collect the information you need to understand the performance of your application.
查看 TestComplete。
Take a look at TestComplete.
还有一点需要注意的是，对于我们的 Web 应用程序，我发现由于线程之间对锁的争用，我们遇到了巨大的性能问题……所以道德是要非常仔细地考虑锁定方案。 我们最终让工作线程使用异步 http 处理程序来限制太多请求，否则应用程序将不堪重负并崩溃。 这意味着可能会堆积大量积压的订单，但至少该网站会保持正常运行。
One more note, for our web application, I found that we had huge performance issues due to contention between threads over locks... so the moral was to think over the locking scheme very carefully. We ended up having worker threads to throttle too many requests using an asynchronous http handler, otherwise the application would just get overwhelmed and crash and burn. It meant a huge backlog could pile up, but at least the site would stay up.
尝试 ZebraTester，它比 jMeter 更容易使用。 我已经使用 jMeter 很长时间了，但负载测试的总设置时间始终是一个问题。 尽管 ZebraTester 不是开源的，但我在过去六个月中节省的时间弥补了这一点。 他们还有一个 SaaS 门户，可用于使用负载生成器快速运行测试。
Try ZebraTester which is much easier to use than jMeter. I have used jMeter for a long time but the total setup time for a load test was always an issue. Although ZebraTester isn't open source, the time that I have saved in the last six months makes up for it. They also have a SaaS portal which can be used for quickly running tests using their load generators.
这里提到了很多好的工具。 我想知道工具是否可以回答以下问题：“如何对 Web 应用程序进行压力测试？” 这些工具并没有真正提供对 Web 应用程序施加压力的方法。 以下是我所知道的：
压力测试显示了 Web 应用程序在为越来越多的用户提供响应时如何失败。 压力测试显示 Web 应用程序在失败时如何运行。 当今的大多数 Web 应用程序（尤其是社交/移动 Web 应用程序）都是服务集成。 例如，当 Facebook 于 2011 年 5 月发生故障时，您无法登录 Pepsi.com 的 Web 应用程序。 该应用程序并没有完全失败，只是用户无法使用其正常功能的很大一部分。
性能测试显示 Web 应用程序保持响应时间的能力，与同时使用该应用程序的用户数量无关。 例如，如果应用程序每秒处理 10 个事务（有 10 个并发用户），则应在有 20 个用户的情况下每秒处理 20 个事务。 如果应用程序每秒处理的事务少于 20 个，则响应时间会变得更长，并且应用程序无法实现线性可扩展性。
此外，在上面的示例中，每秒事务计数应该仅包含测试用例/工作流的成功操作。 故障通常发生在较短的时间跨度内，并且会使 TPS 测量过于乐观。 失败对于压力和性能测试很重要，因为它们也会在应用程序上产生负载。
我在 TestMaker 用户指南中编写了 PushToTest 方法，网址为 http://www.pushtotest.com /pushtotest-testmaker-6-方法。 TestMaker 有两种版本：开源 (GPL) 社区版本和 TestMaker Enterprise（具有强大专业支持的商业版本。）
-Frank
There are a lot of good tools mentioned here. I wonder if tools are an answer the question: "How do you stress test a web application?" The tools don't really provide a method to stress a Web app. Here's what I know:
Stress testing shows how a Web app fails while serving responses to an increasing population of users. Stress testing shows how the Web app functions while it fails. Most Web apps today - especially the Social/Mobile Web apps - are integrations of services. For example, when Facebook had its outage in May 2011 you could not log onto Pepsi.com's Web app. The app didn't fail entirely, just a big portion of its normal function become unavailable to users.
Performance testing shows a Web app's ability to maintain response times independent of how many users are concurrently using the app. For example, an app that handles 10 transactions per second with 10 concurrent users should handle 20 transactions per second at 20 users. If the app handles less than 20 transactions per second the response times are growing longer and the app is not able to achieve linear scalability.
Also, in the above example the transaction-per-second count should be of only successful operations of a test use case/workflow. Failures typically happen in shorter timespans and will make the TPS measurement overly optimistic. Failures are important to a stress and performance test since they generate load on the app too.
I wrote up the PushToTest methodology in the TestMaker User Guide at http://www.pushtotest.com/pushtotest-testmaker-6-methodology. TestMaker comes in two flavors: Open Source (GPL) Community version and TestMaker Enterprise (commercial with great professional support.)
-Frank
Blaze Meter 有一个 chrome 扩展，用于记录会话并将其导出到 JMeter（当前需要登录）。 您还可以选择付钱给他们，以便在他们的 JMeter 服务器集群上运行它（他们的定价似乎比我刚刚停止使用的 LoadImpact 好得多）：
我与他们没有任何关联，我只是喜欢他们服务的外观，尽管我还没有使用付费版本。
Blaze meter has a chrome extension for recording sessions and exporting them to JMeter (currently requires login). You also have the option of paying them money to run it on their cluster of JMeter servers (their pricing seems much better than LoadImpact which I've just stopped using):
I don't have any association with them, I just like the look of their service, although I haven't used the paid version yet.
尝试了这里提到的所有内容，我发现 curl-loader 最适合我的目的。 非常简单的界面、实时监控、有用的统计数据，我可以从中构建性能图表。 包含 libcurl 的所有功能。
Trying all mentioned here, I found curl-loader as best for my purposes. very easy interface, real-time monitoring, useful statistics, from which I build graphs of performance. All features of libcurl are included.
我们最近开始使用加特林进行负载测试。 我强烈建议尝试这个工具进行负载测试。 我们过去使用过 SOASTA 和 JMETER。 我们考虑 Gattle 的主要原因如下：
Jmeter 线程模型
让我给您提供使用加特林代码编写代码的简单示例：
但是您可以使其尽可能复杂。 加特林突出的功能之一是非常详细的报告。
以下是一些链接：
加特林
加特林教程
我最近对此进行了演讲，您可以在这里查看演讲：
https:// docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with-Gadling.pdf
We recently started using Gatling for load testing. I would highly recommend to try out this tool for load testing. We had used SOASTA and JMETER in past. Our main reason to consider Gatling is following:
Jmeter Threading model
Let me give you simple example to write the code using Gatling Code:
However you can make it as complicated as possible. One of the feature which stand out for Gatling is reporting which is very detail.
Here are some links:
Gatling
Gatling Tutorial
I recently gave talk on it, you can go through the talk here:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with-Gatling.pdf
此外，还有一个很棒的开源纯 python 分布式且可扩展的 locust 框架，它使用 greenlets。 它非常适合模拟大量并发用户。
Also, there is an awesome open-source pure-python distributed and scaleable locust framework that uses greenlets. It's great at simulating enormous amount of simultaneous users.
这是对 JMeter 的另一次投票。
JMeter 是一个开源负载测试工具，用 Java 编写。 它能够测试许多不同的服务器类型（例如，Web、Web 服务、数据库，以及基本上使用请求的任何服务器）。
然而，一旦你开始进行复杂的测试，它确实有一个陡峭的学习曲线，但这是非常值得的。 您可以非常快速地启动并运行，并且根据您想要进行的压力测试类型，这可能没问题。
优点：
缺点：
Here's another vote for JMeter.
JMeter is an open-source load testing tool, written in Java. It's capable of testing a number of different server types (for example, web, web services, database, just about anything that uses requests basically).
It does however have a steep learning curve once you start getting to complicated tests, but it's well worth it. You can get up and running very quickly, and depending on what sort of stress-testing you want to do, that might be fine.
Pros:
Cons:
我也投票给jMeter，我想在@PeterBernier 的答案中添加一些引用。
请记住上述内容，jMeter 有许多构建块逻辑控制器、配置元素、预处理器、听众，...可以在这方面为您提供帮助。
您可以使用 jMeter 模拟现实世界的情况，例如您可以：
并发资源下载、浏览器缓存、http headers，将 jMeter 配置为充当真正的浏览器、设置请求超时、cookie管理、https支持、编码、ajax支持,... )每秒用户数、启动时间、调度code> ,...)assert响应以在其中查找文本）请考虑：
监听器），但在测试期间并不意味着要打开。 您必须运行测试并生成报告（.jtl文件）。 然后你必须使用这些工具来分析结果。 请查看 https://www.blazemeter .com/blog/jmeter-listeners-part-1-basic-display-formats 或 https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm。https://www.blazemeter.com/jmeter 有非常好的实用信息来帮助您配置你的测试环境。
I vote for jMeter too and I want add some quotes to @PeterBernier answer.
Keep above in mind, jMeter has many building blocks Logical Controllers, Config Elements, Pre Processors, Listeners ,... which can help you in this.
You can mimic real world situation with jMeter, for example you can:
concurrent resource download,browser cache,http headers,setting request time out,cookie management,https support,encoding,ajax support,... )number of users per second,ramp-up time,scheduling,...)assertresponse to find a text in it)Please consider:
HTTP(S) Test Script Recorder).listeners) but there are not meant to be on during test. You must run your test and generate reports (.jtlfiles). 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.The https://www.blazemeter.com/jmeter has very good and practical information to help you configure your test environment.
看一下 LoadBooster(https://www.loadbooster.com)。 它利用无头脚本浏览器 PhantomJS/CasperJs 来测试网站。 Phantomjs将解析并渲染每个页面，执行客户端脚本。 无头浏览器方法更容易编写测试场景来支持复杂的 AJAX 重型 Web 2.0 应用程序，浏览器导航、鼠标单击和击键到浏览器或等到 DOM 中存在元素。 LoadBooster 也支持 selenium HTML 脚本。
免责声明：我在 LoadBooster 工作。
Take a look at LoadBooster(https://www.loadbooster.com). It utilizes headless scriptable browser PhantomJS/CasperJs to test web sites. Phantomjs will parse and render every page, execute the client-side script. The headless browser approach is easier to write test scenarios to support complex AJAX heavy Web 2.0 app，browser navigation, mouse click and keystrokes into the browser or wait until an element exists in DOM. LoadBooster support selenium HTML script too.
Disclaimer: I work for LoadBooster.
由于这个问题仍然悬而未决，我不妨权衡一下。
好消息是，在过去 5 年左右的时间里，开源工具已经真正成熟并在该领域起飞，坏消息是它们太多了在那里。
以下是我的想法：-
Jmeter 与 Grinder
Jmeter 是由 XML 样式规范驱动的，该规范是通过 GUI 构建的。
Grinder 在多线程 Java 框架内使用 Jython 脚本，因此更面向程序员。
这两个工具都可以处理 HTTP 和 HTTPS，并有一个代理记录器来帮助您入门。
这两种工具都使用控制器模型来驱动多个测试代理，因此可扩展性不是问题（只要可以访问云）。
哪个更好：-
一个艰难的选择，因为这两种工具的学习曲线都很陡峭，因为您会遇到更复杂的脚本要求，例如 URL 重写、关联、为每个虚拟用户提供唯一数据以及模拟首次或返回用户（通过操纵 HTTP标题）。
也就是说，我将从 Jmeter 开始，因为这个工具拥有大量的追随者，并且网络上有许多使用该工具的示例和教程。 如果当您遇到“障碍”时，这是您无法使用 Jmeter“轻松”完成的事情，那么请看看 Grinder。 好消息是这两个工具具有相同的 Java 要求，并且“混合搭配”解决方案并非不可能。
添加新内容 – 运行多个 Selenium WebDriver 实例的无头浏览器。
这是一种相对较新的方法，因为它依赖于现在可以从云中配置的资源的可用性。 通过这种方法，Selenium (WebDriver) 脚本被获取并在无头浏览器（即 WebDriver = New HtmlUnitDriver()）驱动程序中以多个线程运行。
根据经验，大约 25 个“无头浏览器”实例可以从 Amazon M1 小型实例执行。
这意味着，当您将功能测试脚本重新调整为性能测试脚本时，所有相关性、URL 重写问题都会消失。
与 Grinder 或 Jmeter 等 HTTP 驱动程序相比，由于需要更多虚拟机来驱动负载，因此可扩展性受到影响。 也就是说，如果您希望吸引 500 个虚拟用户，那么使用 20 个 Amazon 小型实例（每个实例 6 美分/小时），每小时的成本仅为 1.20 美元，即可为您提供非常接近真实用户体验的负载。
As this question is still open, I might as well weigh in.
The good news is that over the past 5 or so years the Open Source tools have really matured and taken off in the space, the bad news is there are so many of them out there.
Here are my thoughts:-
Jmeter vs Grinder
Jmeter is driven from an XML style specification, that is constructed via a GUI.
Grinder uses Jython scripting within a muti-threaded Java framework, so more oriented to programmers.
Both tools will handle HTTP and HTTPS and have a proxy recorder to get you started.
Both tools use the Controller model to drive multiple test agents so scalability is not an issue (given access to the Cloud).
Which is better:-
A hard call as the learning curve is steep with both tools as you get into the more complicated scripting requirements for url rewriting, correlation, providing unique data per Virtual User and simulating first time or returning Users (by manipulating the HTTP Headers).
That said I would start with Jmeter as this tool has a huge following and there are many examples and tutorials on the web for using this tool. If and when you come to a 'road block', that is something you can't 'easily' do with Jmeter then have a look at the Grinder. The good news is both these tools have the same Java requirement and a 'mix and match' solution is not out of the question.
Something new to add – Headless browsers running multiple instances of Selenium WebDriver.
This is a relatively new approach because it relies on the availability of resources that can now be provisioned from the Cloud. With this approach a Selenium (WebDriver) script is taken and run within a headless browser (i.e. WebDriver = New HtmlUnitDriver()) driver in multiple threads.
From experience around 25 instances of 'headless browsers' can be executed from the Amazon M1 Small Instance.
What this means is that all of the correlation, url rewriting issues disappear as you repurpose your functional testing scripts to become performance testing scripts.
The scalability is compromised as more VMs will be needed to drive the load, as compared with a HTTP driver such as the Grinder or Jmeter. That said, if you are looking to drive 500 Virtual Users then with 20 Amazon Small Instances (6 cents an hour each) at a cost of just $1.20 per hour gives you load that is very close to the Real User Experience.
对于简单的使用，我更喜欢 ab(apache benchmark) 和 siege，稍后需要一个，因为 ab 不支持 cookie，并且会从动态站点创建无尽的会话。
两者都很容易启动：
siege 可以使用更多的 url 运行。
上一个 siege 版本在 siegerc 中启用了详细信息，这很烦人。 您只能通过编辑该文件（
/usr/local/etc/siegerc）来禁用它。For simple usage, I perfer ab(apache benchmark) and siege, later one is needed as ab don't support cookie and would create endless sessions from dynamic site.
both are simple to start:
siege can run with more urls.
last siege version turn verbose on in siegerc, which is annoy. you can only disable it by edit that file(
/usr/local/etc/siegerc).对于基于 Web 的服务，请查看 loader.io。
概括：
他们还有一个 API。
For a web based service, check out loader.io.
Summary:
They also have an API.
ab，围攻，tsung< /a>, httperf, 践踏，Pylot，request-log-analyzer , perftools
ab, siege, tsung, httperf, Trample, Pylot, request-log-analyzer, perftools
我使用过 JMeter。 除了测试 Web 服务器之外，您还可以测试数据库后端、消息服务和电子邮件服务器。
I've used JMeter. Besides testing the web server you can also test your database backend, messaging services and email servers.
我玩过JMeter。 一种认为无法测试的就是 ASP.NET Webforms。 视图状态破坏了我的测试。 我不清楚为什么，但有一些工具不能正确处理视图状态。 我当前的项目是 ASP.NET MVC，JMeter 可以很好地配合它。
I played with JMeter. One think it could not not test was ASP.NET Webforms. The viewstate broke my tests. I am not shure why, but there are a couple of tools out there that dont handle viewstate right. My current project is ASP.NET MVC and JMeter works well with it.
这个聚会有点晚了。 我同意 Pylot 是最好的新兴开源工具。 它使用简单，并且由一位伟大的人 (Corey Goldberg) 积极开发。 作为 OpenQA 的创始人，我也很高兴 Pylot 现在列在我们的主页上并使用我们的一些基础设施（即论坛）。
然而，我最近也发现负载测试的整个概念是有缺陷的：模拟 HTTP 流量，以及应用程序变得如此复杂，是一件令人痛苦的事情。 这就是我创建商业工具 BrowserMob 的原因。 这是一个使用 外部负载测试服务 ">Selenium 在播放负载时控制真实的网络浏览器。
该方法显然需要比普通负载测试技术多吨的硬件，但当您使用云计算时，硬件实际上相当便宜。 这样做的一个很好的副作用是脚本编写比正常的负载测试容易容易。 您不必执行任何高级正则表达式匹配（如 JMeter 要求的那样）来提取 cookie、.NET 会话状态、Ajax 请求参数等。由于您使用的是真正的浏览器，它们只会执行它们应该执行的操作。
很抱歉公然推销商业产品，但希望这个概念对某些人来说很有趣，并且至少让他们在可以使用一堆额外硬件时考虑一些处理负载测试的新方法！
A little late to this party. I agree that Pylot is the best up-and-coming open source tool out there. It's simple to use and is actively worked on by a great guy (Corey Goldberg). As the founder of OpenQA, I'm also happy that Pylot now is listed on our home page and uses some of our infrastructure (namely the forums).
However, I also recently decided that the entire concept of load testing was flawed: emulating HTTP traffic, with applications as complex as they have become, is a pain in the butt. That's why I created the commercial tool BrowserMob. It's an external load testing service that uses Selenium to control real web browsers when playing back load.
The approach obviously requires a ton more hardware than normal load testing techniques, but hardware is actually pretty cheap when you are using cloud computing. And a nice side effect of this is that the scripting is much easier than normal load testing. You don't have to do any advanced regex matching (like JMeter requires) to extract out cookies, .NET session state, Ajax request parameters, etc. Since you're using real browsers, they just do what they are supposed to do.
Sorry to blatantly pitch a commercial product, but hopefully the concept is interesting to some folks and at least gets them thinking about some new ways to deal with load testing when you have access to a bunch of extra hardware!