在过去，我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。
只要让少数开发人员在主页上使劲敲一下，就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面，甚至更多——在发布之后。
我使用的工具的URL是Microsoft Homer(又名Microsoft Web Application Stress Tool)和Pylot。
这些工具生成的报告对我来说没有多大意义，我花了很多时间试图弄清楚站点能够支持什么样的并发负载。这总是值得的，因为最愚蠢的错误和瓶颈总是会出现(例如，web服务器配置错误)。
你做了什么，你使用了什么工具，你的方法有什么成功?对我来说，最有趣的部分是提出某种有意义的公式，用于从压力测试应用程序报告的数字中计算应用程序可以支持的并发用户数。
当前回答
我们最近开始使用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报告有助于分析测试期间发生了什么—您经常会在生产环境中看到非常不同的瓶颈。
关键是要确保不只是运行压力测试，还要收集了解应用程序性能所需的信息。
对于基于web的服务，请查看loader.io。
简介:
加载程序。IO是一个免费的负载测试服务，允许你用数千个并发连接来测试你的web应用程序/api。
它们也有一个API。
You asked this question almost a year ago and I don't know if you still are looking for another way of benchmarking your website. However since this question is still not marked as solved I would like to suggest the free webservice LoadImpact (btw. not affiliated). Just got this link via twitter and would like to share this find. They create a reasonable good overview and for a few bucks more you get the "full impact mode". This probably sounds strange, but good luck pushing and braking your service :)
我用过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).
无论如何，我们还使用该工具来查看应用程序在高负载下的运行情况，它在查找瓶颈方面非常有效。该工具内置了报告，以显示请求花费的时间，但我们从未使用过它。日志还可以存储所有响应或自定义日志。
我强烈推荐这个工具，非常有用的价格…但是期望用它做一些自定义设置(它有一个内置的代理来记录脚本，但它可能需要自定义来捕获会话之类的东西……我知道我必须自定义它以利用每个线程的唯一会话)。
另外，对于我们的web应用程序，我发现由于线程之间的锁争用导致了巨大的性能问题……所以这个教训就是要仔细考虑锁定方案。我们最终让工作线程使用异步http处理程序来抑制太多的请求，否则应用程序就会不堪重负，崩溃并烧毁。这意味着大量的积压工作可能会堆积起来，但至少网站会继续运行。
