在过去，我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。
只要让少数开发人员在主页上使劲敲一下，就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面，甚至更多——在发布之后。
我使用的工具的URL是Microsoft Homer(又名Microsoft Web Application Stress Tool)和Pylot。
这些工具生成的报告对我来说没有多大意义，我花了很多时间试图弄清楚站点能够支持什么样的并发负载。这总是值得的，因为最愚蠢的错误和瓶颈总是会出现(例如，web服务器配置错误)。
你做了什么，你使用了什么工具，你的方法有什么成功?对我来说，最有趣的部分是提出某种有意义的公式，用于从压力测试应用程序报告的数字中计算应用程序可以支持的并发用户数。
当前回答
这是一个老问题，但我认为新的解决方案值得一提。Checkout LoadImpact: http://www.loadimpact.com。
其他回答
为了简单的使用，我更喜欢ab(apache基准)和围攻，后来需要一个，因为ab不支持cookie，会从动态站点创建无休止的会话。
这两种方法都很简单:
ab -c n -t 30 url
siege -b -c n -t 30s url
围攻可以运行更多的网址。
最后一个攻城版本在攻城中打开啰嗦，这很烦人。您只能通过编辑该文件(/usr/local/etc/siegerc)来禁用它。
我们已经开发了一个流程，将负载和性能测量视为头等重要的问题——正如你所说，把它留到项目的最后往往会导致失望……
因此，在开发过程中，我们包括非常基本的多用户测试(使用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报告有助于分析测试期间发生了什么—您经常会在生产环境中看到非常不同的瓶颈。
关键是要确保不只是运行压力测试，还要收集了解应用程序性能所需的信息。
尝试了这里提到的所有方法，我发现卷曲加载器最适合我的目的。非常简单的界面，实时监控，有用的统计数据，从中我建立了性能图表。libcurl的所有特性都包含在内。
我也投票给jMeter，我想在@PeterBernier的回答中添加一些引用。
负载测试回答的主要问题是有多少并发 我的web应用程序可以支持哪些用户?为了得到正确的答案， 负载测试应该代表真实的应用程序使用情况，接近于 可能的。
请记住，jMeter有许多构建块逻辑控制器，配置元素，预处理器，监听器，…这对你有帮助。
你可以模仿真实世界的情况与jMeter，例如，你可以:
Configure jMeter to act as real Browser by configuring (concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding , ajax support ,... ) Configure jMeter to generate user requests (by defining number of users per second, ramp-up time, scheduling ,...) Configure lots of client with jMeter on them, to do a distributed load test. Process response to find if the server is responding correctly during test. ( For example assert response to find a text in it)
请考虑:
It is easy to start a real web application test with jMeter in minutes. The jMeter has a very easy tool which record your test scenario ( know as HTTP(S) Test Script Recorder). jMeter has lots of plugins at http://jmeter-plugins.org. The jMeter UI is swing based and has made good changes in jMeter 3.2. On the other hand please consider that JMeter GUI should only be used for test and debugging. It is not good practice to use it in GUI mode for actual test. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui. Configure and test your scenario and run it on non-gui mode. The are lots of reporting showing tools in jMeter (Known as listeners) but there are not meant to be on during test. You must run your test and generate reports ( .jtl files). Then you must use these tools to analyze result. Please have a look at https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats or https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm.
https://www.blazemeter.com/jmeter提供了非常有用的信息，可以帮助您配置测试环境。
对于基于web的服务，请查看loader.io。
简介:
加载程序。IO是一个免费的负载测试服务，允许你用数千个并发连接来测试你的web应用程序/api。
它们也有一个API。
