Apache 的 AB 工具允许我们测试服务器，以查看服务器每秒可以处理多少页面。结果显然会根据服务器硬件和软件配置的规格而有所不同。我的问题是：您如何知道服务器的结果何时太低/可以改进？或者是可以接受/优化的？
答案1
如果您的结果接近您的场景的大致数字（对于小型静态文件每秒至少有数千个请求，对于简单的动态 PHP 每秒至少有数百个请求，对于带有数据库等的大量动态内容可能更少）并且服务器仍然运行良好，那么您就没问题。
在负载测试期间，服务器仍然有喘息空间也很重要。如果它几乎没有剩余的 CPU 时间或额外内存，那么在网站流量突然激增和/或增长时，您将会遇到大麻烦。
相信你的直觉。如果你只有一个小型数据库来存储内容，并且在基准测试期间数据库服务器似乎消耗了大量的 CPU，请仔细检查所有内容。数据库服务器本身配置是否正确？所有预期的索引是否都已到位？网站是否执行了一些可以优化和/或缓存的半心半意的 SQL 查询？还有其他问题吗？或者，如果你的 Web 服务器似乎甚至在提供静态内容时也花费了大量时间，请检查 Web 服务器设置。
如果你碰巧对一个完全慢如蜗牛的网站进行基准测试，你就会知道还有优化的空间。我曾经对一个看似简单的网站进行基准测试，它运行在一台 8 核服务器、16 GB RAM 和所有那些配置上。ab、siege 和 JMeter 都给我每秒 5 个请求！那时我就知道有些事情非常非常严重地出错了。讽刺的是，是完全配置错误的 cache-plugin 访问了 memcached，出了问题。修复之后，网站速度快了大约 100 倍。:-)
答案2
基准测试是一个非常复杂的话题……
我的观点是……在测试中使用不同数量的并发
1-2-8-16-64-256-512-1024-2048
并推送大量请求..直到
您开始看到错误..由 AB 返回...
然后您开始发现您的应用程序 + 网络服务器的极限。
还要记住您的 RTT 和延迟..
记得运行测试一段时间以获得良好的平均值。
我还应该注意。您可以轻松使用测试服务器上的所有 CPU，而不是实际测试的服务器。因此，请密切关注测试机器上的 CPU 和内存。
希望有帮助：D
答案3
在我看来，问题始终在于用户数量以及他们预期/预期的体验。您的使用情况会有所不同，但我确信，如果 Google 开始以 Expedia 的速度做出响应，人们会感到失望。因此，最终问题在于您的系统在面对一定流量时会如何反应 - 我们无法告诉您这些数据，您需要自己了解。