在过去，我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。
只要让少数开发人员在主页上使劲敲一下，就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面，甚至更多——在发布之后。
我使用的工具的URL是Microsoft Homer(又名Microsoft Web Application Stress Tool)和Pylot。
这些工具生成的报告对我来说没有多大意义，我花了很多时间试图弄清楚站点能够支持什么样的并发负载。这总是值得的，因为最愚蠢的错误和瓶颈总是会出现(例如，web服务器配置错误)。
你做了什么，你使用了什么工具，你的方法有什么成功?对我来说，最有趣的部分是提出某种有意义的公式，用于从压力测试应用程序报告的数字中计算应用程序可以支持的并发用户数。
当前回答
我用过JMeter。除了测试web服务器，您还可以测试数据库后端，消息服务和电子邮件服务器。
其他回答
为了简单的使用，我更喜欢ab(apache基准)和围攻，后来需要一个，因为ab不支持cookie，会从动态站点创建无休止的会话。
这两种方法都很简单:
ab -c n -t 30 url
siege -b -c n -t 30s url
围攻可以运行更多的网址。
最后一个攻城版本在攻城中打开啰嗦，这很烦人。您只能通过编辑该文件(/usr/local/etc/siegerc)来禁用它。
冒着被指责为无耻的自我推销的风险，我想指出，在我寻求免费负载测试工具的过程中，我访问了这篇文章:http://www.devcurry.com/2010/07/10-free-tools-to-loadstress-test-your.html
要么我无法获得我想要的吞吐量，要么我无法获得我想要的灵活性。并且我想在测试后分析中轻松地聚合多个负载测试生成主机的结果。
我尝试了清单上的每一种工具，但令我沮丧的是，它们没有一种完全符合我的要求。所以我做了一个，并分享它。
这里是:http://sourceforge.net/projects/loadmonger
PS:熟悉城市俚语的人不会对这个名字做出恶意评论。我以前不是，但现在更世故了。
我们最近开始使用Gatling进行负载测试。我强烈推荐使用这个工具进行负载测试。我们过去使用过SOASTA和JMETER。我们考虑加特林的主要原因如下:
记录仪对场景进行记录 使用Akka和Netty相比性能更好 Jmeter线程模型 DSL Scala相比Jmeter XML更易于维护 编写测试很容易，如果是scala也不用害怕。 报告
让我给你一个简单的例子来写代码使用加特林代码:
// your code starts here
val scn = scenario("Scenario")
.exec(http("Page")
.get("http://example.com"))
// injecting 100 user enter code here's on above scenario.
setUp(scn.inject(atOnceUsers(100)))
但是你可以让它越复杂越好。加特林的突出特点之一是报告非常详细。
以下是一些链接: 加特林 加特林教程
我最近做了一个关于它的演讲，你可以在这里看一下: https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with-Gatling.pdf
我们已经开发了一个流程，将负载和性能测量视为头等重要的问题——正如你所说，把它留到项目的最后往往会导致失望……
因此，在开发过程中，我们包括非常基本的多用户测试(使用selenium)，它检查基本的疯狂问题，如中断的会话管理、明显的并发问题和明显的资源争用问题。重要的项目在持续集成过程中包含了这一点，所以我们得到了非常定期的反馈。
对于没有极端性能要求的项目，我们在测试中包含基本性能测试;通常，我们使用BadBoy编写测试脚本，并将它们导入JMeter，替换登录细节和其他线程特定的东西。然后我们将这些数据提升到服务器每秒处理100个请求的水平;如果响应时间小于1秒，通常就足够了。我们出发，继续我们的生活。
For projects with extreme performance requirements, we still use BadBoy and JMeter, but put a lot of energy into understanding the bottlenecks on the servers on our test rig(web and database servers, usually). There's a good tool for analyzing Microsoft event logs which helps a lot with this. We typically find unexpected bottlenecks, which we optimize if possible; that gives us an application that is as fast as it can be on "1 web server, 1 database server". We then usually deploy to our target infrastructure, and use one of the "Jmeter in the cloud" services to re-run the tests at scale.
同样，PAL报告有助于分析测试期间发生了什么—您经常会在生产环境中看到非常不同的瓶颈。
关键是要确保不只是运行压力测试，还要收集了解应用程序性能所需的信息。
既然这个问题还没有解决，我不妨发表一下看法。
好消息是，在过去的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美元，就可以获得非常接近真实用户体验的负载。
