在过去，我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。
只要让少数开发人员在主页上使劲敲一下，就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面，甚至更多——在发布之后。
我使用的工具的URL是Microsoft Homer(又名Microsoft Web Application Stress Tool)和Pylot。
这些工具生成的报告对我来说没有多大意义，我花了很多时间试图弄清楚站点能够支持什么样的并发负载。这总是值得的，因为最愚蠢的错误和瓶颈总是会出现(例如，web服务器配置错误)。
你做了什么，你使用了什么工具，你的方法有什么成功?对我来说，最有趣的部分是提出某种有意义的公式，用于从压力测试应用程序报告的数字中计算应用程序可以支持的并发用户数。
当前回答
Visual Studio测试版2010(2008年也不错)。这是一个非常简单和强大的工具来创建web/负载测试。
在Windows服务器上使用此工具的好处是，您可以在报告中集成访问所有perfmon服务器统计信息。真的有用。
另一个好处是，在Visual Studio项目中，你可以集成一个“性能会话”来分析你网站的代码执行情况。
如果你在windows服务器上提供网页服务，这是最好的工具。
然而，使用多台机器来加载测试应用程序需要一个单独且昂贵的许可证。
其他回答
来这个派对有点晚了。我同意Pylot是目前最好的开源工具。它使用简单，是由一个伟大的人(科里·戈德堡)积极工作。作为OpenQA的创始人，我也很高兴Pylot现在被列在了我们的主页上，并使用了我们的一些基础设施(即论坛)。
然而，我最近也认为负载测试的整个概念是有缺陷的:在应用程序变得如此复杂的情况下，模拟HTTP流量是一件令人痛苦的事情。这就是我创建商业工具BrowserMob的原因。它是一个外部负载测试服务，在回放负载时使用Selenium来控制真实的web浏览器。
与正常的负载测试技术相比，这种方法显然需要更多的硬件，但在使用云计算时，硬件实际上相当便宜。这样做的一个很好的副作用是编写脚本比普通的负载测试容易得多。你不需要做任何高级的正则表达式匹配(就像JMeter要求的那样)来提取cookie、. net会话状态、Ajax请求参数等等。因为您使用的是真正的浏览器，所以它们只是做它们应该做的事情。
很抱歉公然推销一个商业产品，但希望这个概念对一些人来说是有趣的，至少让他们考虑一些新的方法来处理负载测试，当您有一堆额外的硬件时!
我们使用提到的微软工具——微软Web应用程序压力工具。这是我用过的最简单的工具。它在许多方面都受到限制，包括只能在手动创建的测试中命中端口80。但是，它的易用性意味着它确实被使用了。
我们用其他工具(包括OpenSTA和链接检查蜘蛛)来补充这个工具的负载。
从我的初步评估来看，JMeter看起来不错，我希望它能包括在我们未来的持续集成中。但是，JMeter是复杂的，推出起来并不简单。
我建议提出另一个关于解释MS压力工具结果的问题。
冒着被指责为无耻的自我推销的风险，我想指出，在我寻求免费负载测试工具的过程中，我访问了这篇文章:http://www.devcurry.com/2010/07/10-free-tools-to-loadstress-test-your.html
要么我无法获得我想要的吞吐量，要么我无法获得我想要的灵活性。并且我想在测试后分析中轻松地聚合多个负载测试生成主机的结果。
我尝试了清单上的每一种工具，但令我沮丧的是，它们没有一种完全符合我的要求。所以我做了一个，并分享它。
这里是:http://sourceforge.net/projects/loadmonger
PS:熟悉城市俚语的人不会对这个名字做出恶意评论。我以前不是，但现在更世故了。
对于基于web的服务，请查看loader.io。
简介:
加载程序。IO是一个免费的负载测试服务，允许你用数千个并发连接来测试你的web应用程序/api。
它们也有一个API。
我用过Grinder。它是开源的，非常容易使用，并且非常可配置。它是基于Java的，脚本使用Jython。我们在一个。net web应用程序上运行了它，所以不要认为它只是一个Java工具(从本质上讲，任何web压力工具都不应该与它所使用的平台绑定)。
We did some neat stuff with it... we were a web based telecom application, so one cool use I set up was to mimick dialing a number through our web application, then used an auto answer tool we had (which was basically a tutorial app from Microsoft to connect to their RTC LCS server... which is what Microsoft Office Communicator connects to on a local network... then modified to just pick up calls automatically). This then allowed us to use this instead of an expensive telephony tool called The Hammer (or something like that).
无论如何，我们还使用该工具来查看应用程序在高负载下的运行情况，它在查找瓶颈方面非常有效。该工具内置了报告，以显示请求花费的时间，但我们从未使用过它。日志还可以存储所有响应或自定义日志。
我强烈推荐这个工具，非常有用的价格…但是期望用它做一些自定义设置(它有一个内置的代理来记录脚本，但它可能需要自定义来捕获会话之类的东西……我知道我必须自定义它以利用每个线程的唯一会话)。
