1

假设，有人告诉您，由于成功的营销活动，每天会有 X（例如 100,000 或其他）的唯一身份访问者数量。

这如何转化为峰值请求/秒？峰值同时请求？

显然，这取决于许多因素，例如每个用户会话请求的典型页面数或典型页面的加载时间，或许多其他因素。这些是其他变量 Y、Z、V 等。

我正在寻找某种函数，甚至只是一个比率来估计这些指标。显然是为了规划生产环境的可扩展性策略。

这可能会发生在我很快正在工作的生产站点上。估计这些的任何帮助都是有用的。

4

3 回答 3

4

编辑：（在表明我们几乎没有关于流量的先前统计数据之后）
因此我们可以忘记下面列出的大部分计划并直接进入“运行一些估计”部分。问题是我们需要使用有根据的猜测（或普通的猜测）从模型中填充参数。以下是一个简单的模型，您可以根据对情况的理解调整参数。

模型

假设：
a) 页面请求的分布遵循正态分布曲线。
b) 考虑到流量高峰期的短暂时间，比如 30 分钟，可以认为请求的数量是均匀分布的。
这可能 [有些] 不正确：例如，如果广告活动针对多个地理区域，例如美国和亚洲市场，我们可能会有一条双曲线。曲线也可能遵循不同的分布。然而，这些假设是好的假设，原因如下：

  • 如果有的话，它会犯“悲观的一面”，即高估峰值流量值。通过使用稍小的标准偏差值，可以进一步采用这种“悲观”的前景。（我们建议使用 2 到 3 小时，这将使 68% 和 95% 的流量分别在 4 和 8 小时（2h 标准开发）和 6 和 12 小时（3h 标准开发）的时间段内。
  • 它使计算变得容易；-)
  • 预计总体上与现实相符。

参数：

  • V = 每 24 小时内预期的不同访客数量
  • Ppv = 与给定访问者会话相关的平均页面请求数。（您可以考虑使用该公式两次，一次用于“静态”类型的响应，另一次用于动态响应，即当应用程序花时间为给定用户/上下文制作响应时）
  • sig = 标准偏差（分钟）
  • R = 每分钟的峰值时间请求数。

公式：

   R = (V * Ppv * 0.0796)/(2 * sig / 10)

这是因为，在正态分布的情况下，根据z-score 表，大约 3.98% 的样本落在平均值的一侧或另一侧的标准偏差的 1/10 内（非常峰值），因此在每边一个标准差的十分之一内获得几乎 8% 的样本，并且假设在此期间分布相对均匀，我们只需除以分钟数。

示例：V=75,000 Ppv=12 和 sig = 150 分钟（即假设 68% 的流量在 5 小时内到达，95% 在 10 小时内到达，5% 在一天中的其他 14 小时内到达）。R = 每分钟 2,388 个请求，即每秒 40 个请求。相当重，但“可行”（除非应用程序每个请​​求需要 15 秒......）

编辑（2012 年 12 月）
：我在此处添加上述模型的“执行摘要”，如full.stack.ex.
在这个模型中，我们假设大多数人在中午访问我们的系统。那是高峰期。别人跳的或落后的，越远越少；半夜没人。我们选择了一条合理地覆盖 24 小时内所有请求的钟形曲线：左侧约 4 个 sigma，右侧约 4 个，长尾中“无”重要剩余。为了模拟最高峰，我们在中午左右剪下一条窄条并计算那里的请求。

值得注意的是，该模型在实践中倾向于高估峰值流量，并且可能被证明在估计“更坏情况”情景而不是更合理的流量模式时更有用。改进估计的初步建议是

  • 延长sig参数（承认相对高流量的有效流量周期较长）
  • 减少所考虑期间的总访问量，即减少V参数，例如 20%（承认大约有那么多访问发生在任何高峰时间之外）
  • 使用不同的分布，例如泊松分布或一些二项分布。
  • 考虑到每天都有许多峰值，并且流量曲线实际上是几个具有相似分布但具有明显峰值的正态（或其他分布）函数的总和。假设这些峰足够分开，我们可以使用原始公式，只需将V因子除以所考虑的峰数。

[原始回复]
您最关心的似乎是服务器如何处理额外的负载......一个非常值得关注的问题;-)。在不分散您对这一运营问题的注意力的情况下，考虑估计即将到来的激增规模的过程，也为您提供了一个机会，让您准备好在广告活动期间和之后收集更多更好的关于网站流量的情报。这些信息将及时证明有助于更好地估计浪涌等，也有助于指导一些站点的设计（用于商业效率以及提高可扩展性）。

暂定计划

假设与现有流量的定性相似。
广告活动会将网站展示给与其当前访问者/用户群体不同的群体（用户类型）：不同的情况选择不同的主题。例如，与“自选？”相比，“广告活动”访问者可能更不耐烦、专注于特定功能、关心价格…… 访客。尽管如此，由于缺乏任何其他支持模型和测量，并且为了估计负载，一般原则可能是假设激增用户的行为总体上与自选人群相似。一种常见的方法是在此基础上“运行数字”，并使用有根据的猜测来稍微弯曲模型的系数以适应一些独特的定性差异。

收集有关现有流量的统计信息
除非您很容易获得这方面的更好信息（例如 Tealeaf、Google Analytics...），否则此类信息的来源可能只是网络服务器的日志...然后您可以构建一些简单的工具来提取解析这些日志并提取以下统计数据。请注意，这些工具将可重复用于未来的分析（例如：活动本身），并且还会寻找记录更多/不同数据的机会，而不会显着改变应用程序！

  • 平均值、最小值、最大值、标准偏差。为了
    • 每个会话访问的页面数
    • 会话持续时间
  • 工作日每个小时的 24 小时流量百分比（不包括周末等，当然，除非这是一个在这些期间接收大量流量的站点）这些百分比应至少在几周内计算以消除噪音。

“运行”一些估计：
例如，从高峰使用估计开始，使用高峰小时百分比、平均每日会话数、每个会话的平均页面点击数等。这个估计应该考虑到随机性交通。请注意，在此阶段您不必担心排队效应的影响，而是假设服务时间相对于请求周期足够低。因此，对于这些非常高的使用时间段，只需使用现实的估计值（或者更确切地说是从日志分析中得到的值），用于请求概率在短时间内（比如 15 分钟）的分布方式。

最后，根据您以这种方式获得的数字，您可以了解这将代表服务器上的子负载类型，并计划添加资源以重构应用程序的一部分。同样 - 非常重要！- 如果预期持续满负荷负载，请按照 ChrisW 的建议开始运行 Pollaczek-Khinchinine 公式，以更好地估计有效负载。

获得额外奖励 ;-) 考虑在活动期间进行一些实验，例如随机为访问的某些页面提供独特的外观或行为，并通过衡量这可能对特定指标产生的影响（如果有）（更多信息的注册、订单、访问的页面数量......）与此相关的工作实验类型可能很重要，但回报也很重要，如果没有别的，它可能会让您的“可用性专家/顾问”保持警惕；-) 您显然希望致力于定义此类实验，与适当的营销/业务当局联系，您可能需要提前计算建议替代站点的用户的最小百分比，以保持实验在统计上具有代表性。确实很重要的是，该实验不需要应用于 50% 的访问者；可以从小处着手，

于 2009-10-13T04:23:33.747 回答
2

我首先假设“每天”的意思是“在 8 小时工作日内”，因为这是最坏的情况，但可能不是不必要的最坏情况。

因此，如果您在 8 小时内平均获得 100,000 人，并且如果每个人到达的时间是随机的（独立于其他人），那么在几秒钟内您会得到更多，而在几秒钟内您会得到更少。细节是知识的一个分支，叫做“排队论”。

假设Pollaczek-Khinchin 公式适用，那么由于您的服务时间（即每个请求的 CPU 时间）非常小（即可能不到一秒），因此您可以承受相当高的时间（即大于 50% ) 服务器利用率。

总而言之，假设每个请求的时间很短，您需要一个比服务平均需求所需的容量更高的容量（但这是个好消息：不会高多少）。

坏消息是，如果您的容量小于平均需求，那么平均排队延迟是无限的（或者更现实地说，一些请求在得到服务之前将被放弃）。

另一个坏消息是，当您的服务时间很短时，您对平均需求的临时波动很敏感，例如...

  • 如果需求在午餐时间达到峰值（即与其他时间的平均需求不同），或者即使由于某种原因它在 5 分钟内达到峰值（例如在电视广告休息期间）

  • 如果你不能让顾客在那段时间排队（例如整个午餐时间排队，或者例如整个五分钟的商业休息时间）

...那么您的容量需要足以满足这些短期高峰需求。OTOH，您可能会决定您可以承受失去多余的费用：不值得为高峰容量进行工程设计（例如，在午餐时间雇用额外的呼叫中心工作人员），并且您可以承受一定比例的放弃呼叫。

于 2009-10-13T03:10:42.133 回答
1

这将取决于营销活动。例如，电视广告会立即带来大量流量，而报纸广告则会在一天内传播得更多。

我对营销类型的经验是，他们只是从没有阳光的地方拉出一个数字，通常比现实高出至少一个数量级

于 2009-10-13T02:42:38.477 回答