在过去,我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。
只要让少数开发人员在主页上使劲敲一下,就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面,甚至更多——在发布之后。
我使用的工具的URL是Microsoft Homer(又名Microsoft Web Application Stress Tool)和Pylot。
这些工具生成的报告对我来说没有多大意义,我花了很多时间试图弄清楚站点能够支持什么样的并发负载。这总是值得的,因为最愚蠢的错误和瓶颈总是会出现(例如,web服务器配置错误)。
你做了什么,你使用了什么工具,你的方法有什么成功?对我来说,最有趣的部分是提出某种有意义的公式,用于从压力测试应用程序报告的数字中计算应用程序可以支持的并发用户数。
既然这个问题还没有解决,我不妨发表一下看法。
好消息是,在过去的5年左右的时间里,开源工具已经真正成熟并在这个领域起飞了,坏消息是还有很多这样的工具。
以下是我的想法:-
Jmeter vs Grinder
Jmeter是由XML样式规范驱动的,该规范是通过GUI构造的。
Grinder在多线程Java框架中使用Jython脚本,因此更面向程序员。
这两个工具都可以处理HTTP和HTTPS,并有一个代理记录器让您开始。
这两种工具都使用Controller模型来驱动多个测试代理,因此可伸缩性不是问题(给定对云的访问)。
哪个更好:-
这是一个艰难的呼叫,因为使用这两种工具的学习曲线是陡峭的,因为您进入了更复杂的脚本需求,如url重写、相关性、为每个虚拟用户提供唯一数据以及模拟第一次或返回用户(通过操作HTTP头)。
也就是说,我会从Jmeter开始,因为这个工具有很多追随者,网上有很多使用这个工具的例子和教程。如果和当你遇到一个“路障”,这是你不能“轻易”用Jmeter做的事情,然后看看Grinder。好消息是,这两个工具都有相同的Java需求,“混合搭配”解决方案也不是不可能。
添加了一些新的东西——运行多个Selenium WebDriver实例的无头浏览器。
这是一种相对较新的方法,因为它依赖于现在可以从云中提供的资源的可用性。使用这种方法,一个Selenium (WebDriver)脚本在多线程的无头浏览器(即WebDriver = New HtmlUnitDriver())驱动程序中运行。
根据经验,亚马逊M1小实例可以执行大约25个“无头浏览器”实例。
这意味着,当您将功能测试脚本重新定位为性能测试脚本时,所有的相关性、url重写问题都将消失。
与Grinder或Jmeter等HTTP驱动程序相比,由于需要更多的虚拟机来驱动负载,因此可伸缩性受到了影响。也就是说,如果你想要驱动500个虚拟用户,那么使用20个亚马逊小实例(每个实例每小时6美分),每小时只需1.20美元,就可以获得非常接近真实用户体验的负载。
这里提到了很多好的工具。我想知道工具是否可以回答这个问题:“如何对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企业版(具有强大专业支持的商业版)。
弗兰克