0

我想测试,就像我确定的许多其他人一样,“我的网络服务器可以同时处理多少个请求”。

通过使用abor之类的工具siege,并使用代表实际使用情况的查询来访问您的 apache Web 服务器/mysql 数据库/php 脚本,与实际用户的实际使用情况相比,您获得的结果具有多大的代表性?

我的意思是,例如,使用实用程序进行测试,所有流量都来自一个 IP,而实际使用来自许多不同的 IP 地址?这是否说明了世界的不同?

如果ab说我的网络服务器每秒可以处理 1000 个请求,这是否可以直接转换为说网络服务器每秒可以处理来自实际用户的 1000 个请求?

我知道这是一个毛茸茸的领域,所以我能得到的答复越具体和直接越好。旧的“取决于”不会有太大帮助:)

4

4 回答 4

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 设置 - 为您的静态资产设置缓存标头将对您的带宽费用产生重大影响,并且可能有助于最终用户感知的性能。\

于 2012-12-20T11:14:48.683 回答
0

简短的回答是否定的,可能不会。

ab和朋友,当从本地机器运行时,不受网络延迟/带宽阻塞的影响。

此外,每个现实生活中的请求都需要不同级别的处理——数据库访问/加载、文件包含等。

另外,这些都没有考虑到来自其他正在运行的后台进程的服务器负载。

于 2012-12-20T10:48:39.097 回答
0

为了获得接近真实的结果,我建议您分析典型的用户行为,siege使用用户正在访问的 url 创建一个 url 文件并随机延迟运行它。这个结果不能直接转移到生产环境中,但它是你可以用你自己的结果得到的最接近的结果。您还可以尝试测试 Web 应用程序性能的 Web 服务,但如果您需要复杂的测试,通常需要付费

于 2012-12-20T10:53:48.427 回答
0

但是说“取决于”并没有多大帮助,并不意味着唯一有效的答案不是“取决于”。因为它有点像。

  • 事实:测试不是现实生活中的使用。
  • 事实:测试可以非常接近现实生活中的使用。
  • 问题:你怎么知道它是否存在?

这取决于您对请求的处理方式。

对于许多应用程序来说,您的单个 IP 不会成为问题,所以这不是我担心的第一件事。但这可能是:如果您对每个 IP 进行一次复杂的统计(例如,将一些信息保存在您设计得不是很好的表中),这意味着您只在测试中这样做了一次,所以您会遇到不好的情况当真正的用户带着他们令人讨厌的不同 IP 出现的时候

这取决于您的测试系统。

如果您的所有请求都来自一条慢线(可能因为您正在处理所有这些请求而速度很慢),那么您将不会得到认真的测试。基本上,如果您期望传入的流量更多,那么您的测试系统的连接可以处理..您会得到漂移。CPU使用率等也是如此。

这取决于你的测试有多好。

例如,如果您的请求是点击所有页面,但您的用户只点击一个特定页面,您显然会得到不同的结果。频率也是如此。如果您按顺序访问页面,可以让您充分利用缓存之类的东西(查询缓存在这方面是一个棘手的问题,但还有 memcached、varnish 等层),那么您将再次遇到麻烦。您可以寻找的最简单的事情是delay您可以设置围攻测试,但您可能需要考虑许多其他事情。

编写好的测试很难,你的测试越好,你就越接近。但是您需要了解您的系统,了解您的用户并了解您的测试。真的没有什么可说的,然后“这取决于”

于 2012-12-20T10:55:10.147 回答