对不起,但“这取决于”是这里最好的答案。
首先,回答这个问题最有价值的工具不是 ab 或 siege 或 JMeter(我最喜欢的开源工具),它是一个电子表格。
您的系统可以处理的请求数量取决于您首先遇到的瓶颈。其中一些瓶颈将是硬件/基础设施(带宽、CPU、负载平衡方案的有效性),一些将是“现成的”软件及其配置方式(例如,Apache 提供静态文件的能力),以及软件(您的 PHP 脚本和数据库查询的运行效率如何)。一些瓶颈资源可能不在您的控制之下——例如,大多数托管在欧洲或美国的网站在从中国访问时速度很慢。
我使用电子表格对用户旅程进行建模 - 这完全取决于您的具体情况,但用户旅程可能是:
- 访问主页
- 点击“注册/登录”链接
- 注册为新用户
- 单击电子邮件中的“验证”链接
- 访问受限内容
大多数网站支持许多用户旅程——在任何时候,这些用户旅程之间的混合可能会有很大差异。
对于每个用户旅程,我会评估访问者请求的性质——例如,“访问主页”可能是“下载 20 个静态文件和 1 个 PHP 脚本”,而“注册为新用户”可能需要“1 个 PHP 脚本” ,但有一组相当复杂的数据库脚本。
这个过程最终成为电子表格中的一组行,显示每种类型的请求数。为了精确起见,可能需要将每个动态页面(PHP 脚本)视为它自己的请求,但我通常将所有静态资源集中在一起。
这为您提供了一个基于大量假设进行测试的基线。您现在可以创建负载测试脚本,代表“20% 的新用户、50% 的回访用户、10% 的主页、20% 的完整购买路径、20% 的放弃购物车”或您想出的任何用户旅程。
创建包含旅程的负载测试脚本并运行它;理想情况下从多个位置(有几种从云提供商处运行 Jmeter 的廉价方法)。测量响应时间,并查看在 10% 以上的情况下,最慢请求的响应时间在哪里超过了质量阈值(我通常建议 3 秒)。
尝试改变用户旅程之间的划分——例如,广告活动可能会带来大量新注册。我通常会推荐至少 3 或 4 种不同的混合物。
如果用户旅程中的任何变化给出的结果显着低于平均值(15% 或更多),那可能是最糟糕的情况。
否则,对结果进行平均,您会以合理的确定性知道这是您可以支持的最小请求数。您可以测试的用户旅程变化越多,就越能确定该数字是准确的。“最少”是指您可以合理地确定您至少可以管理这么多用户。这并不意味着您最多可以处理这么多用户——这是一个细微的差别,但很重要!
在大多数 Web 应用程序中,瓶颈是动态页面的生成——测试 Apache 提供静态文件的能力或托管服务提供商的带宽相对而言意义不大。它作为“我们是否忘记了任何东西”测试很好,但您将从测试您的 PHP 脚本中获得更多价值。
在你这样做之前,我建议你只用 PHP 文件来“寻找瓶颈”——我上面概述的过程并没有告诉你瓶颈在哪里,只是有一个。因为它最有可能是 PHP(当然还有你从 PHP 中做的所有事情,比如调用数据库),所以对解决方案进行检测以测试性能通常是一个好主意。
您还应该使用 Yslow 之类的工具来确保优化您的 HTTP/HTML 设置 - 为您的静态资产设置缓存标头将对您的带宽费用产生重大影响,并且可能有助于最终用户感知的性能。\