我想测试，就像我确定的许多其他人一样，“我的网络服务器可以同时处理多少个请求”。
通过使用abor之类的工具siege，并使用代表实际使用情况的查询来访问您的 apache Web 服务器/mysql 数据库/php 脚本，与实际用户的实际使用情况相比，您获得的结果具有多大的代表性？
我的意思是，例如，使用实用程序进行测试，所有流量都来自一个 IP，而实际使用来自许多不同的 IP 地址？这是否说明了世界的不同？
如果ab说我的网络服务器每秒可以处理 1000 个请求，这是否可以直接转换为说网络服务器每秒可以处理来自实际用户的 1000 个请求？
我知道这是一个毛茸茸的领域，所以我能得到的答复越具体和直接越好。旧的“取决于”不会有太大帮助:)
对不起，但“这取决于”是这里最好的答案。
首先，回答这个问题最有价值的工具不是 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 设置 - 为您的静态资产设置缓存标头将对您的带宽费用产生重大影响，并且可能有助于最终用户感知的性能。\
简短的回答是否定的，可能不会。
ab和朋友，当从本地机器运行时，不受网络延迟/带宽阻塞的影响。
此外，每个现实生活中的请求都需要不同级别的处理——数据库访问/加载、文件包含等。
另外，这些都没有考虑到来自其他正在运行的后台进程的服务器负载。
为了获得接近真实的结果，我建议您分析典型的用户行为，siege使用用户正在访问的 url 创建一个 url 文件并随机延迟运行它。这个结果不能直接转移到生产环境中，但它是你可以用你自己的结果得到的最接近的结果。您还可以尝试测试 Web 应用程序性能的 Web 服务，但如果您需要复杂的测试，通常需要付费
但是说“取决于”并没有多大帮助，并不意味着唯一有效的答案不是“取决于”。因为它有点像。
对于许多应用程序来说，您的单个 IP 不会成为问题，所以这不是我担心的第一件事。但这可能是：如果您对每个 IP 进行一次复杂的统计（例如，将一些信息保存在您设计得不是很好的表中），这意味着您只在测试中这样做了一次，所以您会遇到不好的情况当真正的用户带着他们令人讨厌的不同 IP 出现的时候
如果您的所有请求都来自一条慢线（可能因为您正在处理所有这些请求而速度很慢），那么您将不会得到认真的测试。基本上，如果您期望传入的流量更多，那么您的测试系统的连接可以处理..您会得到漂移。CPU使用率等也是如此。
例如，如果您的请求是点击所有页面，但您的用户只点击一个特定页面，您显然会得到不同的结果。频率也是如此。如果您按顺序访问页面，可以让您充分利用缓存之类的东西（查询缓存在这方面是一个棘手的问题，但还有 memcached、varnish 等层），那么您将再次遇到麻烦。您可以寻找的最简单的事情是delay您可以设置围攻测试，但您可能需要考虑许多其他事情。
编写好的测试很难，你的测试越好，你就越接近。但是您需要了解您的系统，了解您的用户并了解您的测试。真的没有什么可说的，然后“这取决于”