对Web应用程序执行压力testing？

在过去，我使用Microsoft Web应用程序压力工具和Pylot来强调testingWeb应用程序。 我写了一个简单的主页，login脚本和站点漫游（在一个电子商务网站添加几个项目到购物车和结帐）。

只需less量开发人员就能轻松打开主页，几乎总能find一个主要问题。 更多的可扩展性问题将在第二阶段出现，甚至更多 – 在发布之后。

我使用的工具的URL是Microsoft Homer（又名Microsoft Web应用程序压力工具 ）和Pylot 。

这些工具生成的报告对我来说从来没有太多的意义，我会花很多时间来弄清楚网站能够支持什么样的并发负载。 这总是值得的，因为最愚蠢的错误和瓶颈总是会出现（例如，Web服务器错误configuration）。

你做了什么，你使用了什么工具，以及你有什么成功的方法？ 对我来说最有意思的部分是提出一些有意义的公式来计算一个应用程序可以支持的并发用户数量，压力testing应用程序报告的数字。

Answer 1

这是JMeter的另一个投票。

JMeter是一个开源的负载testing工具，用Java编写。 它能够testing许多不同的服务器types（例如，Web，Web服务，数据库，基本上任何使用请求的东西）。

然而，一旦你开始进行复杂的testing，它的确有一个陡峭的学习曲线，但它是非常值得的。 你可以很快起床和跑步，根据你想做什么样的压力testing，这可能是好的。

优点：

• Apache项目中的开源/免费工具（帮助购买）
• 一旦掌握了核心概念，易于使用，易于使用。 （即，如何创build请求，如何创build一个断言，如何使用variables等）。
• 非常可扩展。 我已经在服务器上运行11台机器的testing，达到近百万次点击/小时。 安装比我想象的要容易得多。
• 有一个积极的社区和良好的资源来帮助你起床和跑步。 先阅读教程，并使用它一段时间。

缺点：

• 用户界面是用Swing编写的。 （啊！）
• JMeter通过parsing服务器返回的响应文本来工作。 所以如果你正在寻找validation任何types的JavaScript行为，你运气不好。
• 学习曲线对于非程序员来说是陡峭的。 如果你熟悉正则expression式，那么你已经领先于游戏了。
• 在支持论坛中有大量的（ 插入咒骂 ）白痴问愚蠢的问题，如果他们给予文档即使是粗略的一瞥，也可以很容易地解决。 （'我如何使用JMeter来压力testing我的Windowsgraphics界面'显示相当频繁）。
• “开箱即用”的报告很不理想，特别是对于大型testing。 在上面提到的testing中，我最终不得不编写一个快速的控制台应用程序来执行一些'xml-logfile'到'html'的转换。 那是几年前，所以很有可能不再需要这个了。

Answer 2

我用过磨床 。 它是开源的，使用起来非常简单，而且非常易于configuration。 它基于Java，并使用Jython作为脚本。 我们使用.NET Web应用程序来运行它，所以不要认为它是一个仅限于Java的工具（就其性质而言，任何Web压力工具都不应该绑定到它所使用的平台上）。

我们做了一些整洁的东西…我们是一个基于Web的电信应用程序，所以我设置的一个很酷的用途是模仿通过我们的Web应用程序拨号，然后使用我们有一个自动应答工具（这基本上是一个教程应用程序从微软连接到他们的RTC LCS服务器…这是什么Microsoft Office Communicator连接到本地networking…然后修改，只是自动接电话）。 这就允许我们使用这个而不是昂贵的叫Hammer的电话工具（或类似的东西）。

无论如何，我们也使用这个工具来看看我们的应用程序在高负载情况下如何被阻挡，并且非常有效地find瓶颈。 该工具内置了报告function，显示请求的时间长度，但我们从未使用过。 日志还可以存储所有的响应以及不需要的或自定义的日志logging。

我强烈推荐这个工具，非常有用的价格…但期望做一些自定义设置（它有一个内置的代理logging脚本，但它可能需要定制捕获像会议的东西…我知道我必须定制它以利用每个线程的独特会话）。

Answer 3

晚会有点迟。 我同意Pylot是最好的开源工具。 使用起来很简单，并由一个伟大的人（ Corey Goldberg ）积极地进行工作。 作为OpenQA的创始人，我也很高兴Pylot现在已经被列在我们的主页上，并使用了我们的一些基础设施（即论坛）。

然而，我最近还决定负载testing的整个概念是有缺陷的：模拟HTTPstream量，应用程序已经变得复杂了，这是一个令人头疼的问题。 这就是为什么我创build了商业工具BrowserMob。 这是一个外部负载testing服务 ，在回放负载时使用Selenium来控制真实的Web浏览器。

这种方法显然需要比普通负载testing技术多得多的硬件，但是当你使用云计算时，硬件实际上相当便宜。 这样做的一个好的副作用是脚本比正常的负载testing容易得多。 您不必进行任何高级正则expression式匹配（如JMeter要求）来提取cookie，.NET会话状态，Ajax请求参数等。由于您使用真正的浏览器，他们只是做他们应该做的事情。

对不起，公然地推销一个商业产品，但希望这个概念对一些人来说是有趣的，至less让他们考虑一些新的方法来处理负载testing，当你有一堆额外的硬件！

Answer 4

我用过JMeter 。 除了testingWeb服务器之外，您还可以testing数据库后端，消息服务和电子邮件服务器。

Answer 5

ab，siege，tsung，httperf，Trample，Pylot，请求日志分析器，perftools

Answer 6

对于简单的用法，我认为ab（apache基准）和围攻，稍后需要一个不支持cookie，并会从dynamic网站创build无尽的会议。

两者都很简单：

ab -cn -t 30 url siege -b -cn -t 30s url 

围攻可以运行更多的url。

最后的攻城版在siegerc上变成了冗长的，这是烦人的。 你只能通过编辑该文件（ /usr/local/etc/siegerc ）来禁用它。

Answer 7

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

概要：

loader.io是一个免费的负载testing服务，允许你用数千个并发连接来压力testing你的web-apps / apis。

他们也有一个API 。

Answer 8

由于这个问题仍然是开放的，所以我不妨衡量一下。

好消息是，在过去的5年左右，开源工具已经真正成熟并在太空中脱颖而出，坏消息是其中有那么多。

这是我的想法：

Jmeter vs磨床

Jmeter是通过一个GUI构造的XML样式规范驱动的。

研磨者在multithreading的Java框架内使用Jython脚本，所以更多地面向程序员。

这两个工具将处理HTTP和HTTPS，并有一个代理logging器，让你开始。 这两种工具都使用Controller模型来驱动多个testing代理，因此可伸缩性不是问题（因为可以访问Cloud）。

哪个更好：-

随着您对url重写，关联，为每个虚拟用户提供唯一的数据以及首次模拟或返回用户（通过操作HTTP头）的更复杂的脚本要求，使用这两种工具，学习曲线会非常陡峭。

这就是说，我会从Jmeter开始，因为这个工具有一个巨大的以下，有很多例子和教程在networking上使用这个工具。 如果当你来到一个“路障”，这是你不能“轻松”与Jmeter做，然后看看磨床。 好消息是这两种工具都具有相同的Java要求，而“混搭”解决scheme并非没有问题。

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

这是一种相对较新的方法，因为它依赖于现在可以从云中提供的资源的可用性。 通过这种方法，Selenium（WebDriver）脚本就可以在multithreading的无头浏览器（即WebDriver = New HtmlUnitDriver（））驱动程序中运行。

从大约25个“无头浏览器”实例的经验可以从Amazon M1小实例执行。

这意味着所有的相关性，URL重写问题都会消失，因为您将functiontesting脚本转换为性能testing脚本。

与诸如研磨机或Jmeter的HTTP驱动程序相比，由于需要更多的虚拟机来驱动负载，所以可扩展性受损。 也就是说，如果您希望开发500个虚拟用户，然后用20个亚马逊小实例（每个小时6美分）以每小时1.20美元的成本提供给您的负载，这非常接近真实用户体验。

Answer 9

我们最近开始使用Gatling进行负载testing。 我强烈build议尝试这个工具进行负载testing。 过去我们曾经使用过SOASTA和JMETER。 我们考虑加特林的主要原因如下：

• logging器logging情况
• 与使用Jmeter线程模型相比，使用Akka和Netty可以提供更好的性能
• 与Jmeter XML相比，它是非常可维护的DSL Scala
• 易于编写testing，不要害怕，如果它是scala。
• 报告

让我给你简单的例子，使用Gatling代码编写代码：

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

但是，您可以尽可能地使其变得复杂。 Gatling的一个突出特点就是非常详细的报告。

这里有一些链接：
加特林
加特林教程

我最近讲了这个，你可以在这里谈谈：
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with-Gatling.pdf

Answer 10

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

Answer 11

另外，还有一个非常棒的开放源代码纯python分布式和可伸缩的蝗虫框架，它使用greenlet 。 模拟大量的并发用户是非常棒的。

Answer 12

我试过WebLoad这是一个非常整洁的工具。 它附带和testing脚本的IDE，它允许您logging用户在网站上的行动。 它还绘制图表，因为它执行压力testing您的Web服务器上。 试试看，我强烈推荐它。

Answer 13

尝试所有这里提到的，我发现curl装载机最适合我的目的。 非常简单的界面，实时监控，有用的统计，从中我build立性能的图表。 包括libcurl的所有function。

Answer 14

Blaze Meter有一个用于logging会话并将其导出到JMeter的Chrome扩展（当前需要login）。 你也可以select付钱给他们在JMeter服务器集群上运行（他们的定价似乎比我刚刚停止使用的LoadImpact更好）：

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

我和他们没有任何关系，我只是喜欢他们的服务，尽pipe我还没有使用付费版本。

Answer 15

你在一年前问过这个问题，我不知道你是否还在寻找另一种基准testing方法。 但是，因为这个问题仍然没有被标记为解决，我想build议免费的Web服务LoadImpact （btw。不附属）。 刚刚通过Twitter了这个链接，并希望分享这个发现。 他们创造了一个合理的好的概述，并且为了获得“全面的影响模式”，还有几块钱。 这可能听起来很奇怪，但祝你好运，推动和制动你的服务:)

Answer 16

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

Answer 17

我用过openSTA 。

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

您可以轻松testingWeb服务并编写自己的脚本。

它允许您以任何您想要的方式将脚本放在一起进行testing，并configuration迭代次数，每次迭代中的用户数量，引入每个新用户的上升时间以及每次迭代之间的延迟。 testing也可以安排在未来。

它是开源的，免费的。

它产生了一些可以保存到电子表格的报告。 然后，我们使用数据透视表来轻松分析和绘制结果。

Answer 18

我们使用提到的Microsoft工具 – Microsoft Web Application Stress Tool。 这是我用过的最简单的工具。 它在许多方面是有限的，包括只能在手动创build的testing中打到80端口。 但是，它的易用性意味着它实际上被使用了。

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

JMeter从我的初步评估看起来不错，我希望将其纳入我们持续整合的过程中。 但是，JMeter是复杂的，并不是无关紧要的。

我build议在解释MS压力工具结果时提出另一个问题。

Answer 19

Visual Studiotesting版2010（2008也不错）。 这是一个非常简单而强大的工具来创buildWeb /负载testing。

与Windows服务器一起使用时，此工具带来的好处是您可以对报告中的所有perfmon服务器统计信息进行集成访问。 真的有用。

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

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

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

Answer 20

我们已经制定了一个stream程，将负载和性能测量视为一stream的关注点，正如您所说的，将其放到项目的最后，往往会导致失望。

因此，在开发过程中，我们包含了非常基本的多用户testing（使用selenium），它检查会话pipe理中断，并发性问题，以及明显的资源争用问题等基本的疯狂。 不平凡的项目在持续整合过程中包含了这一点，所以我们得到了非常正规的反馈。

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

对于性能要求极高的项目，我们仍然使用BadBoy和JMeter，但花费了大量的精力来理解我们的testing平台（通常是Web和数据库服务器）上的服务器瓶颈。 有一个很好的工具来分析微软的事件日志 ，这有助于很多。 我们通常会发现意想不到的瓶颈，如果可能的话我们会优化它们 这为我们提供了一个在“1个Web服务器，1个数据库服务器”上的应用程序。 然后，我们通常会部署到我们的目标基础架构，并使用“云中的Jmeter”服务之一来大规模地重新运行testing。

再次，PAL报告帮助分析testing过程中发生的事情 – 您经常在生产环境中看到非常不同的瓶颈。

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

Answer 21

这里提到了很多很好的工具。 我不知道工具是否回答了这个问题：“你如何压力testing一个Web应用程序？ 这些工具并没有真正提供强调Web应用程序的方法。 以下是我所知道的：

压力testing显示了Web应用程序如何失败，同时服务于越来越多的用户。 压力testing显示Web应用程序在失败时如何工作。 现在大多数Web应用程序，特别是社交/移动Web应用程序，都是服务的集成。 例如，当Facebook在2011年5月中断时，您无法loginPepsi.com的Web应用程序。 该应用程序没有完全失败，只是其正常function的一大部分变得对用户不可用。

性能testing显示Web应用程序能够保持响应时间，而不pipe有多less用户同时使用该应用程序。 例如，每10个并发用户每秒处理10个事务的应用程序应该每20个用户处理20个事务。 如果应用程序每秒钟处理less于20个事务，响应时间将会增长，应用程序无法实现线性可伸缩性。

另外，在上面的例子中，每秒事务数量只应该是testing用例/工作stream程的成功操作。 故障通常发生在较短的时间段内，并会使TPS测量过于乐观。 失败对压力和性能testing很重要，因为它们也会对应用程序产生负载。

我在http://www.pushtotest.com/pushtotest-testmaker-6-methodology的TestMaker用户指南中写下了PushToTest方法。; TestMaker有两种版本：开源（GPL）社区版和TestMaker Enterprise（商业版，专业支持很好）。

-坦率

Answer 22

看看LoadBooster（ https://www.loadbooster.com ）。 它利用无头脚本浏览器PhantomJS / CasperJs来testing网站。 Phantomjs将parsing并呈现每一页，执行客户端脚本。 无头浏览器方法更容易编写testing场景，以支持复杂的AJAX沉重的Web 2.0应用程序，浏览器导航，鼠标点击和击键到浏览器或等到DOM中存在元素。 LoadBooster也支持seleniumHTML脚本。

免责声明：我为LoadBooster工作。

Answer 23

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

Answer 24

还有一点需要注意的是，对于我们的Web应用程序，我发现由于线程之间的争用而导致性能问题非常严重……因此，道德就是非常仔细地考虑lockingscheme。 我们结束了工作线程扼杀太多的请求使用asynchronoushttp处理程序，否则应用程序将只是得不偿失，崩溃和燃烧。 这意味着巨大的积压可能会堆积如山，但至less该网站会熬夜。

Answer 25

看看TestComplete 。

Answer 26

我第二个opensta的build议。 我只是补充一点，它允许你做一些事情来监视你使用SMTPtesting的服务器。 我们跟踪处理器负载，使用的内存，发送的脚本等等。唯一的缺点是，如果你发现某些东西不知所措，并且想要修复它，那么它依赖于几个不再保持的开源库，所以编译源代码版本比大多数OSS更为棘手。

Answer 27

我和JMeter一起玩。 一个人认为它不能testing是ASP.NET Webforms。 视图状态打破了我的testing。 我不知道为什么，但是那里有一些工具不处理视图状态。 我目前的项目是ASP.NET MVC和JMeter与它很好地工作。

Answer 28

我用FunkLoad获得了很好的结果：

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

Answer 29

冒着被指责为无耻的自我推销的风险，我想指出，在我寻求一个免费的负载testing工具，我去了这篇文章： http : //www.devcurry.com/2010/07/10-free-工具对loadstress试验your.html

要么我无法获得我想要的吞吐量，要么我无法获得我想要的灵活性。 我想在后期testing分析中轻松汇总多个负载testing生成主机的结果。

我尝试了列表中的每一个工具，我的沮丧发现，他们没有一个做了我想做的事情。 所以我build立了一个，并分享它。

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

PS：对那些熟悉城市俚语的人的名字没有评论。 我不是，但现在稍微更加世俗化。

Answer 30

我也投票给JMeter，我想给@PeterBernier的回答添加一些引号。

加载testing回答的主要问题是我的Web应用程序支持多less并发用户？ 为了得到正确的答案， 负载testing应尽可能接近真实的应用程序使用情况 。

请记住， jMeter有许多构build块逻辑控制器 ， configuration元素 ， 预处理器 ， 听众 ，…可以帮助你在这个。

你可以用jMeter模拟真实世界的情况，例如你可以：

1. configurationjMeter作为真正的浏览器，通过configuration（ concurrent resource download ， browser cache ， http headers ， setting request time out ， cookie management ， https support ， encoding ， ajax support …）
2. configurationjMeter来生成用户请求（通过定义number of users per second ramp-up time ， scheduling …）
3. 使用jMeterconfiguration大量客户端，进行分布式负载testing。
4. 处理响应以查找服务器在testing期间是否正确响应。 （例如assert响应来查找文本）

请考虑：

• 使用jMeter可以在几分钟内开始真正的Web应用程序testing。 jMeter有一个非常简单的工具来logging你的testing场景（称为HTTP(S) Test Script Recorder ）。
• jMeter在http://jmeter-plugins.org有大量的插件。;
• jMeter UI是基于swing的，并且在jMeter 3.2中做了很好的改变。 另一方面，请考虑JMeter GUI只能用于testing和debugging。 在GUI模式下将其用于实际testing并不是一个好习惯。 https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui 。 configuration并testing您的场景并在非gui模式下运行。
• jMeter中有许多报告显示工具（称为listeners ），但在testing期间并不打算打开。 您必须运行testing并生成报告（ .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提供了非常好的实用信息来帮助您configurationtesting环境。;