过去，我使用Microsoft Web Application Stress Tool和Pylot对Web应用程序进行压力测试。我写了一个简单的首页，登录脚本和网站演练(在一个电子商务网站中，向购物车中添加了一些商品并结帐)。

仅仅与少数开发人员一起努力访问主页几乎总是可以找到一个主要问题。更多的可扩展性问题将在第二阶段浮出水面，甚至在启动后还会出现。

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

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

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

解决方案

回答

我用过《磨床》。它是开源的，非常易于使用，并且可配置。它基于Java，并使用Jython编写脚本。我们将其针对.NET Web应用程序运行，因此不要以为它只是Java工具(从本质上讲，任何Web压力工具都不应与其使用的平台捆绑在一起)。

我们用它做了一些整洁的事情……我们是一个基于Web的电信应用程序，所以我设置的一个很酷的用途是通过我们的Web应用程序模拟拨号，然后使用我们拥有的自动应答工具(基本上是一个教程) Microsoft的应用程序以连接到其RTC LCS服务器……这是Microsoft Office Communicator在本地网络上连接的……然后进行了修改，以自动接听电话)。然后，这使我们可以使用它代替昂贵的电话工具"锤"(或者类似工具)。

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

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

回答

还有一点要注意，对于我们的Web应用程序，我发现由于锁上线程之间的争用，我们遇到了巨大的性能问题。因此，道德上要非常仔细地考虑锁方案。我们最终使工作线程使用异步http处理程序来限制太多请求，否则应用程序将不堪重负，崩溃并烧毁。这意味着可能会积压大量积压，但至少该站点会停滞不前。

回答

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

回答

看一下TestComplete。

回答

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

回答

我用过openSTA。

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

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

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

它是开源的，免费的。

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

回答

这是JMeter的另一票。

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

但是，一旦开始进行复杂的测试，它的学习曲线确实陡峭，但这是值得的。我们可以非常快速地启动并运行，并且根据要进行的压力测试类型而定，可能会很好。

优点：

• Apache项目中的开源/免费工具(帮助购买)
• 易于上手，一旦掌握了核心概念，就易于使用。 (即，如何创建请求，如何创建断言，如何使用变量等)。
• 非常可扩展。我已经用11台机器运行了测试，这些机器在服务器上产生的负载几乎达到每小时一百万次命中。设置比我期望的要容易得多。
• 拥有活跃的社区和良好的资源来入门和运行。首先阅读教程，并玩一会儿。

缺点：

• UI用Swing编写。 (啊！)
• JMeter通过解析服务器返回的响应文本来工作。因此，如果我们想验证任何一种JavaScript行为，那么我们就不走运了。
• 对于非程序员来说，学习曲线是陡峭的。如果我们熟悉正则表达式，那么我们已经领先于游戏了。
• 支持论坛中有很多(插入有冒犯性的)白痴在问愚蠢的问题，如果他们给文档带来粗略的浏览就可以轻松解决。 ("如何使用JMeter对Windows GUI进行压力测试"显示得非常频繁)。
• 报告"开箱即用"尚需时日，特别是对于大型测试。在上面提到的测试中，我最终不得不编写一个快速的控制台应用程序来执行一些从" xml-logfile"到" html"的转换。不过那是几年前的事，因此很有可能不再需要它了。

回答

我赞同opensta的建议。我只想补充一点，它允许我们做一些事情来监视我们正在使用SMTP测试的服务器。我们会跟踪处理器负载，已用内存，发送的拜拜等信息。唯一的缺点是，如果发现某些问题并想进行修复，则它依赖于几个不再使用的开源库，因此需要进行编译该版本的源代码比大多数OSS更为棘手。

回答

我们使用提到的Microsoft工具Microsoft Web应用程序压力工具。这是我使用过的最简单的工具。它在许多方面受到限制，包括只能在手动创建的测试中命中端口80。但是，它的易用性意味着它实际上已被使用。

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

从我的初步评估来看，JMeter看起来不错，我希望将其包含在今后的持续集成中。但是，JMeter十分复杂且不容易推广。

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

回答

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

回答

我和JMeter一起玩。一个认为它无法测试的是ASP.NET Webforms。 viewstate破坏了我的测试。我不知道为什么，但是那里有一些无法正确处理viewstate的工具。我当前的项目是ASP.NET MVC，JMeter可以很好地工作。

回答

参加这个聚会有点晚了。我同意Pylot是目前最好的新兴开源工具。它简单易用，并得到了一个好人(Corey Goldberg)的积极努力。作为OpenQA的创始人，我也很高兴Pylot现在在我们的主页上列出并使用了我们的一些基础架构(即论坛)。

但是，我最近还认为，负载测试的整个概念都是有缺陷的：模拟HTTP流量以及已变得如此复杂的应用程序，实在是一团糟。这就是为什么我创建了商业工具BrowserMob。这是一个外部负载测试服务，在播放负载时使用Selenium来控制实际的Web浏览器。

这种方法显然比普通的负载测试技术需要更多的硬件，但是当我们使用云计算时，硬件实际上非常便宜。这样做的一个很好的副作用是，与普通的负载测试相比，脚本编写要容易得多。我们不必进行任何高级的正则表达式匹配(如JMeter要求的)即可提取Cookie，.NET会话状态，Ajax请求参数等。由于我们使用的是真正的浏览器，因此它们仅能执行应做的事情。

很抱歉公然推销一种商业产品，但是希望这个概念对某些人很有趣，并且至少让他们在可以使用大量额外的硬件时思考一些新的方式来处理负载测试！

回答

我们差不多是一年前问的一个问题，我不知道我们是否还在寻找基准化网站的另一种方法。但是，由于此问题仍未标记为已解决，因此我建议我们使用免费的Web服务LoadImpact(顺便说一句，未附属)。刚刚通过twitter获得了此链接，并希望分享此发现。他们创建了一个合理的良好概览，只需花几美元，我们便可以使用"完全影响模式"。这听上去很奇怪，但是祝我们好运，并推动服务:)

回答

Visual Studio测试版2010(2008也不错)。这是创建Web /负载测试的真正简单而强大的工具。

在Windows服务器上使用此工具的好处是，我们可以对报告中的所有perfmon服务器统计信息进行集成访问。真的很有用。

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

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

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

回答

为了简单使用，我进行了ab(apache基准测试)和围攻，由于ab不支持cookie，并且以后会从动态站点创建无休止的会话，因此需要使用ab(apache基准测试)和围攻。

两者都很容易上手：

ab -c n -t 30 url

siege -b -c n -t 30s url

攻城游戏可以使用更多网址。

最后的攻城版本在siegerc中打开了详细信息，这很烦人。我们只能通过编辑该文件(/ usr / local / etc / siegerc)来禁用它。

回答

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