在过去,我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。

只要让少数开发人员在主页上使劲敲一下,就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面,甚至更多——在发布之后。

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

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

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


当前回答

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

负载测试回答的主要问题是有多少并发 我的web应用程序可以支持哪些用户?为了得到正确的答案, 负载测试应该代表真实的应用程序使用情况,接近于 可能的。

请记住,jMeter有许多构建块逻辑控制器,配置元素,预处理器,监听器,…这对你有帮助。

你可以模仿真实世界的情况与jMeter,例如,你可以:

Configure jMeter to act as real Browser by configuring (concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding , ajax support ,... ) Configure jMeter to generate user requests (by defining number of users per second, ramp-up time, scheduling ,...) Configure lots of client with jMeter on them, to do a distributed load test. Process response to find if the server is responding correctly during test. ( For example assert response to find a text in it)

请考虑:

It is easy to start a real web application test with jMeter in minutes. The jMeter has a very easy tool which record your test scenario ( know as HTTP(S) Test Script Recorder). jMeter has lots of plugins at http://jmeter-plugins.org. The jMeter UI is swing based and has made good changes in jMeter 3.2. On the other hand please consider that JMeter GUI should only be used for test and debugging. It is not good practice to use it in GUI mode for actual test. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui. Configure and test your scenario and run it on non-gui mode. The are lots of reporting showing tools in jMeter (Known as listeners) but there are not meant to be on during test. You must run your test and generate reports ( .jtl files). 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.

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

其他回答

这是给JMeter的另一票。

JMeter是一个开源的负载测试工具,用Java编写。它能够测试许多不同的服务器类型(例如,web, web服务,数据库,基本上使用请求的任何东西)。

然而,一旦你开始面对复杂的测试,它确实有一个陡峭的学习曲线,但它是非常值得的。您可以非常快速地启动并运行,这取决于您想要进行哪种类型的压力测试,这可能没问题。

优点:

Open-Source/Free tool from the Apache project (helps with buy-in) Easy to get started with, and easy to use once you grasp the core concepts. (Ie, how to create a request, how to create an assertion, how to work with variables etc). Very scalable. I've run tests with 11 machines generating load on the server to the tune of almost a million hits/hour. It was much easier to setup than I was expecting. Has an active community and good resources to help you get up and running. Read the tutorials first and play with it for a while.

缺点:

The UI is written in Swing. (ugh!) JMeter works by parsing the response text returned by the server. So if you're looking to validate any sort of javascript behaviours, you're out of luck. Learning curve is steep for non-programmers. If you're familiar with regular expressions, you're already ahead of the game. There are large numbers of (insert expletive) idiots in the support forum asking stupid questions that could be easily solved if they'd give the documentation even a cursory glance. ('How do I use JMeter to stress-test my Windows GUI' shows up quite frequently). Reporting 'out of the box' leaves much to be desired, particularly for larger tests. In the test I mentioned above, I ended up having to write a quick console app to do some of the 'xml-logfile' to 'html' conversions. That was a few years ago though, so it's probable that this would no longer be required.

我赞成开放的建议。我只想补充一点,它允许您使用SMTP来监视您正在测试的服务器。我们跟踪处理器负载、内存使用、发送的byes等等。唯一的缺点是,如果你发现某些东西有问题,想要修复它,它依赖于几个不再保持的开源库,所以获得源代码的编译版本比大多数OSS更棘手。

此外,还有一个很棒的开源纯python分布式和可伸缩的locust框架,它使用了greenlets。它很擅长模拟大量同时使用的用户。

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

压力测试显示了Web应用程序如何在响应不断增加的用户数量时失败。压力测试显示Web应用程序在失败时如何运行。今天大多数Web应用程序——尤其是社交/移动Web应用程序——都是服务的集成。例如,当Facebook在2011年5月中断服务时,你无法登录Pepsi.com的Web应用程序。该应用程序并没有完全失败,只是用户无法使用它的大部分正常功能。

性能测试显示Web应用程序保持响应时间的能力,与有多少用户同时使用应用程序无关。例如,一个应用程序每秒处理10个事务,同时有10个并发用户,应该每秒处理20个事务,同时有20个用户。如果应用程序每秒处理的事务少于20个,那么响应时间就会变长,应用程序无法实现线性可伸缩性。

同样,在上面的例子中,每秒事务数应该仅仅是测试用例/工作流的成功操作。故障通常发生在较短的时间跨度内,这将使TPS测量过于乐观。失败对于压力和性能测试非常重要,因为它们也会在应用程序上产生负载。

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

弗兰克

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

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

我尝试了清单上的每一种工具,但令我沮丧的是,它们没有一种完全符合我的要求。所以我做了一个,并分享它。

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

PS:熟悉城市俚语的人不会对这个名字做出恶意评论。我以前不是,但现在更世故了。