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

时间:2008-08-11 03:00:27

标签: web-applications stress-testing performance webapplicationstresstool pylot

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

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

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

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

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

29 个答案:

答案 0 :(得分:109)

这是对JMeter的另一次投票。

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

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

优点:

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

缺点:

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

答案 1 :(得分:36)

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

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

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

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

答案 2 :(得分:23)

这个派对有点晚了。我同意Pylot是最好的即将推出的开源工具。它使用简单,并且由一个好人(Corey Goldberg)积极地工作。作为OpenQA的创始人,我也很高兴Pylot现在列在我们的主页上并使用我们的一些基础设施(即论坛)。

然而,我最近还认为负载测试的整个概念存在缺陷:模拟HTTP流量,应用程序虽然变得复杂,但却是一种痛苦。这就是我创建商业工具BrowserMob的原因。这是external load testing service,在回放负载时使用Selenium来控制真实的网络浏览器。

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

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

答案 3 :(得分:15)

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

答案 4 :(得分:12)

答案 5 :(得分:9)

对于基于网络的服务,请查看loader.io

要点:

  

loader.io是一个免费的负载测试服务,允许您通过数千个并发连接对web-apps / apis进行压力测试。

他们也有API

答案 6 :(得分:9)

由于这个问题仍然存在,我不妨考虑一下。

好消息是,在过去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个“无头浏览器”实例。

这意味着当您将功能测试脚本重新用作性能测试脚本时,所有相关性,网址重写问题都会消失。

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

答案 7 :(得分:9)

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

两者都很容易开始:

ab -c n -t 30 url

siege -b -c n -t 30s url

围攻可以运行更多网址。

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

答案 8 :(得分:7)

此外,还有一个使用locust的真棒开源pure-python分布式和可扩展greenlets框架。它非常适合模拟大量的同时用户。

答案 9 :(得分:6)

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

答案 10 :(得分:4)

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

答案 11 :(得分:3)

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

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

答案 12 :(得分:3)

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

答案 13 :(得分:2)

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

答案 14 :(得分:1)

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

使用此工具时,对Windows服务器使用的奖励是,您可以对报告中的所有perfmon服务器统计信息进行集成访问。真有用。

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

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

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

答案 15 :(得分:1)

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

压力测试显示Web应用程序在为越来越多的用户提供响应时失败。压力测试显示Web应用程序在失败时如何运行。今天的大多数Web应用程序 - 尤其是社交/移动Web应用程序 - 都是服务的集成。例如,当Facebook在2011年5月停运时,您无法登录Pepsi.com的Web应用程序。该应用程序并未完全失败,只有其正常功能的很大一部分对用户不可用。

性能测试显示Web应用程序能够维持响应时间,而不依赖于同时使用该应用程序的用户数量。例如,每秒处理10个并发用户的10个事务的应用程序应该在20个用户处理每秒20个事务。如果应用程序每秒处理的事务少于20个,则响应时间会越来越长,并且应用程序无法实现线性可伸缩性。

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

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

-Frank

答案 16 :(得分:1)

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

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

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

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

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

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

答案 17 :(得分:1)

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

免责声明:我为LoadBooster工作。

答案 18 :(得分:1)

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

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

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

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

答案 19 :(得分:1)

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

答案 20 :(得分:1)

我使用了openSTA

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

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

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

它是开源的,免费的。

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

答案 21 :(得分:1)

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

答案 22 :(得分:0)

我也投票支持 jMeter ,我想在@PeterBernier回答中添加一些引用。

  

负载测试答案的主要问题是多少并发   用户可以支持我的Web应用程序?为了得到正确的答案,   负载测试应代表实际的应用程序使用情况,尽可能接近   可能

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

您可以使用jMeter模仿真实世界的情况,例如:

  1. 通过配置(concurrent resource downloadbrowser cachehttp headerssetting request time outcookie managementhttps support,{将jMeter配置为真实浏览器{1}},encoding,...)
  2. 配置jMeter以生成用户请求(通过定义ajax supportnumber of users per secondramp-up time,...)
  3. 使用jMeter配置大量客户端,进行分布式负载测试。
  4. 处理响应以查找服务器在测试期间是否正确响应。 (例如scheduling响应以查找其中的文本)
  5. 请考虑:

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

答案 23 :(得分:0)

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

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

我尝试了清单上的每一个工具,并且我的挫折感发现他们都没有完成我想做的事情。所以我建了一个并且正在分享它。

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

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

答案 24 :(得分:0)

FunkLoad我的成绩很好:

  • 易于脚本用户互动
  • 报告很明确
  • 可以监控服务器负载

答案 25 :(得分:0)

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

答案 26 :(得分:0)

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

答案 27 :(得分:0)

看看TestComplete

答案 28 :(得分:0)

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