在Web应用程序上执行压力测试？


Performing a Stress Test on Web Application?

过去，我使用Microsoft Web Application Stress Tool和Pylot来强调测试Web应用程序。我写了一个简单的主页，登录脚本和网站演练(在电子商务网站中添加一些项目到购物车和结帐)。

只需与少数几个开发人员一起努力点击主页几乎总能找到一个主要问题。更多可扩展性问题将在第二阶段出现，甚至更多 - 在发布之后。

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

这些工具生成的报告对我来说从来没有多大意义，我会花费很多时间来弄清楚网站能够支持哪种并发负载。它总是值得的，因为最愚蠢的错误和瓶颈总是会出现(例如，Web服务器配置错误)。

您做了什么，使用了哪些工具，以及您的方法取得了哪些成功？对我来说最有趣的部分是提出某种有意义的公式，用于根据压力测试应用程序报告的数量计算应用程序可以支持的并发用户数。

这是JMeter的另一次投票。

JMeter是一个用Java编写的开源负载测试工具。它能够测试许多不同的服务器类型(例如，Web，Web服务，数据库，几乎任何使用请求的服务器)。

然而，一旦你开始进行复杂的测试，它确实有一个陡峭的学习曲线，但它是值得的。您可以非常快速地启动和运行，并且根据您想要进行的压力测试，可能没问题。

优点：

  • 来自Apache项目的开源/免费工具(帮助买入)
  • 一旦掌握了核心概念，便于上手，易于使用。 (即，如何创建请求，如何创建断言，如何使用变量等)。
  • 非常可扩展。我用11台机器运行测试，在服务器上产生负载，达到近百万次点击/小时。它的设置比我预期的要容易得多。
  • 拥有活跃的社区和良好的资源，可以帮助您启动和运行。首先阅读教程并使用它一段时间。

缺点：

  • UI是用Swing编写的。 (啊！)
  • JMeter通过解析服务器返回的响应文本来工作。因此，如果您希望验证任何类型的JavaScript行为，那么您将失去运气。
  • 非程序员的学习曲线很陡峭。如果您熟悉正则表达式，那么您已经领先于游戏。
  • 在支持论坛中有大量(插入咒骂)白痴问愚蠢的问题，如果他们给文档甚至粗略一瞥就可以轻松解决。 ('如何使用JMeter对我的Windows GUI进行压力测试'经常出现)。
  • 报告"开箱即用"还有很多不足之处，特别是对于大型测试。在我上面提到的测试中，我最终必须编写一个快速控制台应用程序来执行"xml-logfile"到"html"转换。那是几年前的事情，所以很可能不再需要这样做了。
相关讨论

我用过磨床。它是开源的，非常易于使用，并且非常易于配置。它是基于Java的，并使用Jython作为脚本。我们针对.NET Web应用程序运行它，所以不要认为它是一个仅限Java的工具(就其本质而言，任何Web压力工具都不应该与它使用的平台绑定)。

我们做了一些巧妙的事情...我们是一个基于网络的电信应用程序，所以我设置的一个很酷的用途是模仿通过我们的网络应用程序拨号，然后使用我们的自动答案工具(这基本上是一个教程来自Microsoft的应用程序连接到他们的RTC LCS服务器......这是Microsoft Office Communicator在本地网络上连接的...然后被修改为自动接听电话)。这使我们可以使用它来代替昂贵的电话工具The Hammer(或类似的东西)。

无论如何，我们还使用该工具来查看我们的应用程序如何在高负载下保持，并且它在查找瓶颈方面非常有效。该工具内置了报告功能，可显示请求的持续时间，但我们从未使用过它。日志还可以存储所有响应和诸如此类的自定义日志记录。

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

相关讨论

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

但是，我最近还决定负载测试的整个概念存在缺陷：模拟HTTP流量，应用程序虽然变得复杂，但却是一个痛苦的屁股。这就是我创建商业工具BrowserMob的原因。它是一种外部负载测试服务，在回放负载时使用Selenium控制真实的Web浏览器。

这种方法显然需要比正常负载测试技术更多的硬件，但是当您使用云计算时，硬件实际上相当便宜。这样做的好处是脚本比正常的负载测试容易得多。您不必进行任何高级正则表达式匹配(如JMeter要求)来提取cookie，.NET会话状态，Ajax请求参数等。由于您使用的是真正的浏览器，他们只是按照自己的意愿去做。

很抱歉公然宣传商业产品，但希望这个概念对某些人来说很有意思，至少让他们考虑一些新的方法来处理负载测试，当你可以访问一堆额外的硬件时！

相关讨论

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

ab，siege，tsung，httperf，Trample，Pylot，request-log-analyzer，perftools

相关讨论

对于简单的用法，我更喜欢ab(apache基准测试)和围攻，后来需要一个，因为ab不支持cookie，并且会从动态站点创建无限的会话。

两者都很简单：

1
2
3
ab -c n -t 30 url

siege -b -c n -t 30s url

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

最后的围攻版本在siegerc上变得冗长，这很烦人。您只能通过编辑该文件(/usr/local/etc/siegerc)来禁用它。

由于这个问题仍未解决，我不妨考虑一下。

好消息是，在过去5年左右的时间里，开源工具已经真正成熟并在这个领域取得了成功，坏消息是其中有很多这样的工具。

以下是我的想法： -

Jmeter vs Grinder

Jmeter由XML样式规范驱动，该规范通过GUI构建。

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

这两个工具都将处理HTTP和HTTPS，并有一个代理记录器来帮助您入门。
这两个工具都使用Controller模型来驱动多个测试代理，因此可扩展性不是问题(给定访问云)。

哪个更好：-

当您进入更复杂的脚本重写，关联，为每个虚拟用户提供唯一数据以及模拟第一次或返回用户(通过操纵HTTP标头)时，这两种工具的学习曲线都很陡峭。

这就是说我会从Jmeter开始，因为这个工具有很多关注者，网上有很多使用这个工具的例子和教程。如果你来到一个"路障"，这是你不能轻易用Jmeter做的事情，那么看看磨床。好消息是这些工具具有相同的Java要求，并且"混合搭配"解决方案不是不可能的。

新增内容 - 运行Selenium WebDriver多个实例的无头浏览器。

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

根据经验，可以从Amazon M1 Small Instance执行大约25个"无头浏览器"实例。

这意味着当您将功能测试脚本重新调整为性能测试脚本时，所有相关性，URL重写问题都会消失。

与HTTP驱动程序(如Grinder或Jmeter)相比，可扩展性受到影响，因为需要更多的VM来驱动负载。也就是说，如果您希望以每小时1.20美元的成本驱动500个虚拟用户，然后使用20个亚马逊小型实例(每个小时6美分)，那么您的负载将非常接近真实用户体验。

相关讨论

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

摘要：

loader.io is a free load testing service that allows you to stress test your web-apps/apis with thousands of concurrent connections.

他们也有一个API。

相关讨论

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

  • 记录场景的记录器
  • 使用Akka和Netty可以提供更好的性能
    Jmeter线程模型
  • 与Scmeter XML相比，DSL Scala非常易于维护
  • 容易编写测试，不要吓唬它是否是scala。
  • 报告

让我举一个使用Gatling Code编写代码的简单示例：

1
2
3
4
5
6
// 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

此外，还有一个使用greenlet的真棒开源pure-python分布式和可扩展的蝗虫框架。它非常适合模拟大量的并发用户。

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

相关讨论

我试过WebLoad它是一个非常简洁的工具。它附带了测试脚本IDE，允许您在网站上记录用户操作。它还会在您的Web服务器上执行压力测试时绘制图形。尝试一下，我强烈推荐它。

相关讨论

试试这里提到的所有内容，我发现curl-loader最适合我的目的。非常简单的界面，实时监控，有用的统计数据，我可以从中构建性能图表。包含libcurl的所有功能。

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

  • BlazeMeter Chrome扩展程序
  • 有关它的博客条目

我与他们没有任何关联，我只是喜欢他们服务的外观，虽然我还没有使用付费版本。

大约一年前你问了这个问题，我不知道你是否还在寻找另一种方法来对你的网站进行基准测试。但是，由于这个问题仍未标记为已解决，我想建议免费的Web服务LoadImpact(顺便说一下，不是附属的)。刚刚通过Twitter获得此链接，并希望分享此查找。他们创造了一个合理的良好概览，而且只需几美元就可以获得"全面影响模式"。这可能听起来很奇怪，但是好运推动和制动你的服务:)

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

免责声明：我为LoadBooster工作。

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

我用过openSTA。

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

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

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

它是开源的，免费的。

它会生成许多报告，可以保存到电子表格中。然后，我们使用数据透视表轻松分析和绘制结果图。

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

Visual Studio Test Edition 2010(2008年也很好)。这是一个非常简单而强大的工具来创建Web /负载测试。

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

另一个好处是，使用Visual Studio项目，您可以集成一个"性能会话"，该会话将描述您网站的代码执行情况。

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

但是，使用多台计算机加载测试应用程序需要单独且昂贵的许可证。

我们使用提到的Microsoft工具 - Microsoft Web Application Stress Tool。这是我用过的最简单的工具。它在很多方面受到限制，包括只能在手动创建的测试中命中端口80。但是，它的易用性意味着它实际上得到了使用。

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

JMeter从我最初的评估看起来很不错，我希望将它包含在我们的持续集成中。但是，JMeter非常复杂且非常重要。

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

我们已经开发出一种将负载和性能测量视为一流关注的流程 - 正如您所说，将其置于项目的最后会导致失望......

因此，在开发过程中，我们包括非常基本的多用户测试(使用selenium)，它会检查基本的疯狂，例如破坏的会话管理，明显的并发问题以及明显的资源争用问题。非平凡的项目包括在持续集成过程中，因此我们得到非常定期的反馈。

对于没有极端性能要求的项目，我们在测试中包括基本性能测试;通常，我们使用BadBoy编写测试脚本，并将它们导入JMeter，替换登录详细信息和其他特定于线程的内容。然后我们将这些升级到服务器每秒处理100个请求的级别;如果响应时间小于1秒，那通常就足够了。我们开始并继续我们的生活。

对于具有极高性能要求的项目，我们仍然使用BadBoy和JMeter，但是需要花费大量精力来理解我们的测试台(通常是Web和数据库服务器)上的服务器上的瓶颈。有一个分析Microsoft事件日志的好工具，这对此有很大帮助。我们通常会发现意外的瓶颈，如果可能的话我们会优化瓶颈;这为我们提供了一个与"1个Web服务器，1个数据库服务器"一样快的应用程序。然后，我们通常部署到我们的目标基础架构，并使用"云中的Jmeter"服务之一来大规模地重新运行测试。

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

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

这里提到了很多好的工具。我想知道工具是否能回答这个问题："你如何对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-methodology。 TestMaker有两种版本：开源(GPL)社区版和TestMaker Enterprise(具有很强专业支持的商业版)。

-坦率

相关讨论

我和JMeter一起玩。有人认为它无法测试是ASP.NET Webforms。视图状态打破了我的测试。我不是什么原因，但有一些工具没有处理viewstate权利。我目前的项目是ASP.NET MVC，JMeter很适合它。

有可能被指责无耻的自我推销，我想指出，在我寻求免费负载测试工具时，我去了这篇文章：http：//www.devcurry.com/2010/07/10-free-工具对loadstress试验your.html

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

我尝试了列表中的每一个工具，并且我的沮丧发现他们都没有完成我想做的事情。所以我建了一个并且正在分享它。

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

PS：对熟悉都市俚语的人的名字没有讽刺评论。我不是，但现在稍微更加世俗了。

我在FunkLoad上取得了不错的成绩：

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

看看TestComplete。

相关讨论

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

The main question that load testing answers is how many concurrent
users can my web application support? In order to get a proper answer,
load testing should represent real application usage, as close as
possible.

请记住，jMeter有许多构建块逻辑控制器，配置元素，预处理器，监听器......可以为您提供帮助。

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

  • 通过配置(concurrent resource download，browser cache，http headers，setting request time out，cookie management，https support，encoding，ajax support，...)将jMeter配置为真实浏览器
  • 配置jMeter以生成用户请求(通过定义number of users per second，ramp-up time，scheduling，...)
  • 使用jMeter配置大量客户端，进行分布式负载测试。
  • 处理响应以查找服务器在测试期间是否正确响应。 (例如assert响应以查找其中的文本)

    • 请考虑：

    • 使用jMeter在几分钟内轻松启动真正的Web应用程序测试。 jMeter有一个非常简单的工具，可以记录您的测试场景(知道为HTTP(S) Test Script Recorder)。
    • jMeter在http://jmeter-plugins.org上有很多插件。
    • jMeter UI基于swing，并在jMeter 3.2中进行了很好的更改。另一方面，请考虑JMeter GUI只应用于测试和调试。在GUI模式下使用它进行实际测试并不是一个好习惯。 https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui。配置并测试您的场景并在非gui模式下运行它。
    • 有很多报告显示了jMeter中的工具(称为listeners)，但在测试期间并不打算开启。您必须运行测试并生成报告(.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具有非常好的实用信息，可帮助您配置测试环境。

    还有一点需要注意的是，对于我们的Web应用程序，我发现由于线程锁定之间的争用，我们遇到了巨大的性能问题......所以道德是要仔细考虑锁定方案。我们最终让工作线程使用异步http处理程序限制了太多请求，否则应用程序将不堪重负并崩溃和刻录。这意味着一个巨大的积压可能会堆积，但至少该网站会熬夜。

    相关讨论

    我是第二个opensta建议。我只想补充一点，它允许你做一些事情来监控你正在使用SMTP测试的服务器。我们跟踪处理器负载，使用的内存，发送的byes等。唯一的缺点是，如果你发现了某些内容并希望进行修复，它依赖于几个不再保持的开源库，因此需要编译源版本比大多数OSS更棘手。