performance 对 Web 应用程序性能基准的建议
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/41857/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Recommendations for Web application performance benchmarks
提问by JonnyGold
I'm about to start testing an intranet web application. Specifically, I've to determine the application's performance.
我即将开始测试 Intranet Web 应用程序。具体来说，我必须确定应用程序的性能。
Please could someone suggest formal/informal standards for how I can judge the application's performance.
请有人建议我如何判断应用程序性能的正式/非正式标准。
回答by Marcio Aguiar
Use some tool for stress and load testing. If you're using Java take a look at JMeter. It provides different methods to test you application performance. You should focus on:
使用一些工具进行压力和负载测试。如果您使用 Java，请查看JMeter。它提供了不同的方法来测试您的应用程序性能。你应该专注于：
- Response time: How fast your application is running for normal requests. Test some read/write use case
- Load test: How your application behaves in high traffic times. The tool will submit several requests (you can configure that properly) during a period of time.
- Stress test: Do your application can operate during a long period of time? This test will push your application to the limits
- 响应时间：您的应用程序针对正常请求的运行速度。测试一些读/写用例
- 负载测试：您的应用程序在高流量时期的表现。该工具将在一段时间内提交多个请求（您可以正确配置）。
- 压力测试：您的应用程序是否可以长时间运行？此测试将您的应用程序推向极限
Start with this, if you're interested, there are other kinds of tests.
从这个开始，如果你有兴趣，还有其他类型的测试。
回答by James Pulley
"Specifically, I have to determine the application's performance...."
“具体来说，我必须确定应用程序的性能……”
This comes full circle to the issue of requirements, the captured expectations of your user community for what is considered reasonable and effective. Requirements have a number of components
这又回到了需求问题，即您的用户社区对被认为合理和有效的期望的捕获。需求有许多组成部分
- General Response time, " Under a load of .... The Site shall have a general response time of less than x, y% of the time..."
- Specific Response times, " Under a load of .... Credit Card processing shall take less than z seconds, a% of the time..."
- System Capacity items, " Under a load of .... CPU|Network|RAM|DISK shall not exceed n% of capacity.... "
- The load profile, which is the mix of the number of users and transactions which will take place under which the specific, objective, measures are collected to determine system performance.
- 一般响应时间，“在……负载下，站点的一般响应时间应小于 x, y% 的时间……”
- 特定的响应时间，“在负载......的情况下，信用卡处理应少于 z 秒，有 % 的时间......”
- 系统容量项，“在负载.... CPU|网络|RAM|DISK 不应超过容量的 n%....”
- 负载配置文件，它是用户数量和将发生的事务的组合，在此情况下收集特定的、客观的度量以确定系统性能。
You will notice the the response times and other measures are no absolutes. Taking a page from six sigma manufacturing principals, the cost to move from 1 exception in a million to 1 exception in a billion is extraordinary and the cost to move to zero exceptions is usually a cost not bearable by the average organization. What is considered acceptable response time for a unique application for your organization will likely be entirely different from a highly commoditized offering which is a public internet facing application. For highly competitive solutions response time expectations on the internet are trending towards the 2-3 second range where user abandonment picks up severely. This has dropped over the past decade from 8 seconds, to 4 seconds and now into the 2-3 second range. Some applications, like Facebook, shoot for almost imperceptible response times in the sub one second range for competitive reasons. If you are looking for a hard standard, they just don't exist.
您会注意到响应时间和其他措施不是绝对的。从 6 sigma 制造负责人的角度来看，从百万分之一的例外转变为十亿分之一的例外的成本是非同寻常的，而转变为零例外的成本通常是普通组织无法承受的成本。贵组织的独特应用程序可接受的响应时间可能与高度商品化的产品（面向公共 Internet 的应用程序）完全不同。对于高度竞争的解决方案，互联网上的响应时间期望趋向于 2-3 秒范围，用户放弃率严重上升。在过去的十年里，这已经从 8 秒下降到 4 秒，现在下降到 2-3 秒的范围。一些应用程序，例如 Facebook，出于竞争原因，在不到一秒的范围内拍摄几乎察觉不到的响应时间。如果您正在寻找一个硬标准，它们就是不存在。
Something that will help your understanding is to read through a couple of industry benchmarks for style, form, function.
通读一些关于风格、形式、功能的行业基准，这将有助于你的理解。
Setting up a solid set of performance tests which represents your needs is a non-trivial matter. You may want to bring in a specialist to handle this phase of your QA efforts.
设置一组可靠的性能测试来代表您的需求是一件非常重要的事情。您可能需要聘请一位专家来处理这一阶段的 QA 工作。
On your tool selection, make sure you get one that can
在您选择工具时，请确保您得到一个可以
- Exercise your interface
- Report against your requirements
- You or your team has the skills to use
- You can get training on and will attend with management's blessing
- 练习你的界面
- 根据您的要求报告
- 您或您的团队拥有可以使用的技能
- 你可以接受培训，并会在管理层的祝福下参加
Misfire on any of the four elements above and you as well have purchased the most expensive tool on the market and hired the most expensive firm to deploy it.
上述四个要素中的任何一个都失败了，而且您还购买了市场上最昂贵的工具并聘请了最昂贵的公司来部署它。
Good luck!
祝你好运！
回答by David McLaughlin
To test the front-end then YSlow is great for getting statistics for how long your pages take to load from a user perspective. It breaks down into stats for each specfic HTTP request, the time it took, etc. Get it at http://developer.yahoo.com/yslow/
为了测试前端，YSlow 非常适合从用户角度获取页面加载时间的统计信息。它分解为每个特定 HTTP 请求的统计信息、花费的时间等。从http://developer.yahoo.com/yslow/ 获取
Firebug, of course, also is essential. You can profile your JS explicitly or in real time by hitting the profile button. Making optimisations where necessary and seeing how long all your functions take to run. This changed the way I measure the performance of my JS code. http://getfirebug.com/js.html
当然，Firebug 也是必不可少的。您可以通过点击配置文件按钮显式或实时地配置您的 JS。在必要时进行优化并查看所有功能运行所需的时间。这改变了我衡量 JS 代码性能的方式。http://getfirebug.com/js.html
回答by kemiller2002
Really the big thing I would think is response time, but other indicators I would look at are processor and memory usage vs. the number of concurrent users/processes. I would also check to see that everything is performing as expected under normal and then peak load. You might encounter scenarios where higher load causes application errors due to various requests stepping on each other.
我认为真正重要的是响应时间，但我会考虑的其他指标是处理器和内存使用率与并发用户/进程的数量。我还会检查一切在正常和峰值负载下是否按预期执行。您可能会遇到由于各种请求相互交错而导致更高负载导致应用程序错误的情况。
If you really want to get detailed information you'll want to run different types of load/stress tests. You'll probably want to look at a step load test (a gradual increase of users on system over time) and a spike test (a significant number of users all accessing at the same time where almost no one was accessing it before). I would also run tests against the server right after it's been rebooted to see how that affects the system.
如果您真的想获得详细信息，您将需要运行不同类型的负载/压力测试。您可能希望查看步进负载测试（系统上的用户随着时间的推移逐渐增加）和峰值测试（大量用户同时访问，而之前几乎没有人访问它）。我还会在服务器重新启动后立即对服务器运行测试，以查看这对系统有何影响。
You'll also probably want to look at a concept called HEAT (Hostile Environment Application Testing). Really this shows what happens when some part of the system goes offline. Does the system degrade successfully? This should be a key standard.
您可能还想了解一个称为 HEAT（敌对环境应用程序测试）的概念。这确实显示了当系统的某些部分脱机时会发生什么。系统是否成功降级？这应该是一个关键标准。
My one really big piece of suggestion is to establish what the system is supposed to do before doing the testing. The main reason is accountability. Get people to admit that the system is supposed to do something and then test to see if it holds true. This is key because because people will immediately see the results and that will be the base benchmark for what is acceptable.
我的一个非常重要的建议是在进行测试之前确定系统应该做什么。主要原因是问责制。让人们承认系统应该做某事，然后测试它是否成立。这是关键，因为人们会立即看到结果，这将成为可接受的基准。
