我希望像其他许多人一样，测试“我的Web服务器可以处理多少个并发请求”。
通过使用ab或siege之类的工具，并通过代表真实生活使用情况的查询命中apache Web服务器/ mysql数据库/ php脚本，与真实生活相比，您获得的结果有多大代表性实际用户的使用情况？
我的意思是，例如，使用实用程序进行测试，所有流量都来自单个IP，而实际使用量却来自许多不同的IP地址？这说明了差异世界吗？
如果ab说我的Web服务器每秒可以处理1000个请求，这是否可以直接转换为说Web服务器每秒可以处理来自实际用户的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设置-为静态资产设置缓存标头会对带宽费用产生重大影响，并可能有助于提高最终用户的性能。 \
关于php - 负载测试的代表性如何？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13970330/