Web 应用程序稳定性的良好标准指标是什么？
目前，我们开发的 Web 应用程序产品面临一些稳定性问题。 该产品部分由我们的合作伙伴承包商构建，我们希望有一个良好的稳定性标准指标。 我们一直面临的问题是不断崩溃。 Web 应用程序无法识别何时存在超出其处理能力的请求，它会累积内存（如内存泄漏），然后在没有任何类型的可能恢复的情况下终止。
我们想为我们的合作伙伴承包商编写一个非常简单的衡量标准。 我们考虑了一些想法：
- 一个系统能够识别高负载的请求并为服务器提供不可用的重试页面，直到它从高负载中恢复。
- 一定数量的并发用户或页面浏览量将使我们能够清楚地衡量何时使用负载均衡器和缓存等可扩展性选项。
此时我们必须使用缓存和负载平衡，以便能够每 x 小时回收一次 Web 应用程序（取决于负载），这样它们就不会不断死机。
感谢您的帮助。
We currently facing some stability issues with our develop web application product. This product was built in part by our partner contractor, and we want to have a good standard metric for stability. The issues we have been facing is constant crashing. The web application is unable to identify when there are more request than it can handle, it builds up memory (like a memory leak) and later it dies without any type of possible recovery.
We would like to write a very simple measurement for our partner contractor to meet. We thought about a few ideas:
- A system that is able to identify high loads of request and serve server unavailable try again pages, until it recovers from the high load.
- A set number of users concurrent or pageviews that will allow us to have a clear metric of when to use scalability options like Load Balancer and Caching.
At this moment we have to use caching and load balancing to be able to recycle the web applications every x hours (depending on the load) so they don't die constantly.
Thanks for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
“高负载”确实很难定义。
您可以更轻松地确定最低可接受的服务级别。
最小并发请求数。
处理请求的最长时间。
每小时最小请求数。
像这样的简单服务级别很容易测量、易于模拟并且易于写入合同。 任何律师或会计师都可以查看负载测试的结果，并说他们是否达到了最低要求。 根本不需要深厚的技术知识。
请注意，当您执行此操作时，“最小值将变为最大值”。 如果您规定他们必须每小时至少处理 10,000 个请求，您的测试通常也会显示这也是最大值。
因此，请根据您的业务模型定义您的最小值和最大值。 您需要多少才能让人们保持快乐和高效？ 要求更多是愚蠢的。 要求更少意味着用户不满意或效率低下。
"High load" is really hard to define.
It's much, much easier for you to determine what the minimally acceptable service levels are.
Minimum number of concurrent requests.
Maximum time to serve a request.
Minimum number of requests per hour.
Simple service levels like that are easy to measure, easy to simulate and easy to write into a contract. Any lawyer or accountant can review the results of a load test and say they did or did not meet the minimums. No deep technical knowledge needed at all.
Note that when you do this, "minimums become maximums". If you say they must serve a minimum of 10,000 requests per hour, your testing will often reveal that's the maximum, also.
So define your minimums and maximums from your business model. How many do you need to keep people happy and productive? Asking for more is silly. Asking for fewer means unhappy or unproductive users.
通常，我已经看到规范中内置了这些性能类型要求......“系统应该支持 x 数量的并发用户”或“每小时 x 数量的请求”。
这些东西可以使用 LoadRunner 之类的东西轻松测试和验证，或者您可以使用 HttpUnit 之类的东西推出自己的类似负载测试器。
Typically, I've seen these performance type requirements built into the specification... "the system should support x amount of concurrent users" or "x number of requests per hour".
These things can be easily tested and verified using something like LoadRunner or you can roll your own similar load tester using something like HttpUnit.
您需要以下参数：
负载测试：
i) 估计您的应用程序使用行为..（即）否。 预期并发用户数、典型用户活动
ii) 逐渐加载应用程序并查看 CPU 使用率、响应时间、吞吐量等参数。
可持续性：
加载应用程序（以最佳负载）相当长的时间（12-24 小时），并查看相同的参数 CPU 使用情况、错误级别等。
您还可以尝试可扩展性，在其中增量添加硬件并监视应用程序的行为。
这应该可以让您对系统的行为有一个很好的了解。
What you'd need are following parameters:
Load Test:
i) Estimate your application usage behaviour.. (i.e.) no. of concurrent users expected, typical user activity
ii) Load the application gradually and look at parameters like cpu usage, response times, throughput, etc.
Sustainability:
Load the application (at optimum load) for a considerable amount of time (12-24 hrs) and look at the same parameters cpu usage, error levels, etc.
You can also try scalability, where you would add hardware incrementally and monitor the behaviour of the application.
This should give you a decent understanding of the behaviour of your system.