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