我们目前在开发 Web 应用程序产品时面临一些稳定性问题。该产品部分由我们的合作伙伴承包商构建，我们希望有一个良好的稳定性标准指标。我们一直面临的问题是不断崩溃。Web 应用程序无法识别何时有超过它可以处理的请求，它会建立内存（如内存泄漏），然后它会在没有任何可能恢复的情况下死掉。
我们想为我们的合作伙伴承包商编写一个非常简单的测量方法。我们想了几个主意：
此时，我们必须使用缓存和负载平衡，以便能够每 x 小时（取决于负载）回收 Web 应用程序，这样它们就不会经常死掉。
谢谢你的帮助。
“高负载”真的很难定义。
确定最低可接受的服务水平对您来说要容易得多。
最小并发请求数。
服务请求的最长时间。
每小时的最小请求数。
像这样的简单服务水平易于衡量、易于模拟并且易于写入合同。任何律师或会计师都可以查看负载测试的结果，并说他们是否达到了最低要求。根本不需要深厚的技术知识。
请注意，当您这样做时，“最小值变为最大值”。如果您说他们必须每小时至少处理 10,000 个请求，那么您的测试通常也会显示这也是最大值。
因此，从您的业务模型中定义您的最小值和最大值。你需要多少人才能让人们快乐和富有成效？要求更多是愚蠢的。要求更少意味着用户不满意或效率低下。
通常，我已经看到规范中内置了这些性能类型要求……“系统应支持 x 数量的并发用户”或“每小时 x 数量的请求”。
可以使用 LoadRunner 之类的东西轻松测试和验证这些东西，或者您可以使用 HttpUnit 之类的东西推出自己的类似负载测试器。
您需要以下参数：
负载测试：
i）估计您的应用程序使用行为..（即）不。预期的并发用户数，典型的用户活动
ii) 逐渐加载应用程序并查看 CPU 使用率、响应时间、吞吐量等参数。
可持续性：
加载应用程序（以最佳负载）相当长的时间（12-24 小时）并查看相同的参数 cpu 使用情况、错误级别等。
您还可以尝试可扩展性，即逐步添加硬件并监控应用程序的行为。
这应该使您对系统的行为有一个不错的了解。