Как соотносятся различные показатели посетителей?

Гипотетически, говорят теты, кто-то говорит вам, что вы должны ожидать X (около 100 000 или около того) числа уникальных посетителей в день в результате успешной маркетинговой кампании.

Как это переводится в пиковые запросы / секунду? Пик одновременных запросов?

Очевидно, что это зависит от многих факторов, таких как типичное количество страниц, запрошенных за сеанс пользователя или время загрузки типовой страницы, или многое другое. Это другие переменные Y, Z, V и т. Д.

Я ищу какую-то функцию или даже просто соотношение для оценки этих показателей. Очевидно, что для планирования стратегии масштабируемости производственной среды.

Это может произойти на производственной площадке, над которой я работаю очень скоро. Любая помощь в оценке этого полезна.

13.10.2009 02:35:45
Вы знаете, сколько запросов может обработать система в настоящее время? У вас есть кеширующий обратный прокси? Обычная вещь, которая случается, когда планирование не было сделано заранее, состоит в том, что сервер попадает через несколько минут в кампанию.
John La Rooy 13.10.2009 22:05:27
3 ОТВЕТА
РЕШЕНИЕ

Изменить : (следуя указаниям на то, что у нас практически нет предыдущих статистических данных о трафике)
Поэтому мы можем забыть об основной части плана, изложенной ниже, и сразу перейдем к части «Выполнить некоторые оценки» . Проблема в том, что нам нужно будет заполнить параметры из модели, используя образованные догадки (или простые дикие догадки). Ниже приведена простая модель, для которой вы можете настроить параметры на основе вашего понимания ситуации.

модель

Допущения :
а) Распределение запросов страниц следует кривой нормального распределения .
б) Учитывая короткий период во время пикового трафика , скажем, 30 минут, количество запросов можно считать равномерно распределенным .
Это может быть [несколько] неверно: например, у нас может быть двойная кривая, если рекламная кампания нацелена на несколько географических регионов, например, на рынки США и Азии. Также кривая может следовать другому распределению. Эти предположения, однако, хороши по следующим причинам:

  • он будет ошибаться, если вообще будет, на «пессимистической стороне», то есть переоценке пиковых значений трафика. Этот «пессимистичный» прогноз может быть в дальнейшем принят путем использования немного меньшего значения стандартного отклонения. (Мы предлагаем использовать от 2 до 3 часов, что позволило бы разместить 68% и 95% трафика в течение 4 и 8 часов (2 ч. Стандартное отклонение) и 6 и 12 часов (3 ч. Стандартное отклонение) соответственно.
  • это делает для простых расчетов ;-)
  • как ожидается, в целом соответствует действительности.

Параметры :

  • V = ожидаемое количество отдельных посетителей за 24 часа
  • Ppv = среднее количество запросов страниц, связанных с данным сеансом посетителя. (вы можете рассмотреть возможность использования формулы дважды, один для «статического» типа ответов, а другой для динамических ответов, т. е. когда приложение тратит время на создание ответа для данного пользователя / контекста)
  • sig = стандартное отклонение в минутах
  • R = пиковое количество запросов в минуту.

Формула :

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

Это связано с тем, что при нормальном распределении и в соответствии с таблицей z-показателей примерно 3,98% выборок находятся в пределах 1/10 от стандартного отклонения на одной или другой стороне от среднего значения (самого пика), поэтому получить почти 8 процентов выборок с точностью до одной десятой от стандартного отклонения с каждой стороны, и, предполагая относительно равномерное распределение в течение этого периода, мы просто делим на количество минут.

Пример : V = 75 000 Ppv = 12 и sig = 150 минут (т. Е. Предполагается, что 68% трафика будет приходиться на 5 часов, 95% на 10 часов, 5% на остальные 14 часов дня). R = 2 388 запросов в минуту, т.е. 40 запросов в секунду. Довольно тяжелый, но «выполнимый» (если приложение не занимает 15 секунд на запрос ...)

Редактировать (декабрь 2012 г.)
: я добавляю здесь «краткое изложение» модели, предложенной выше, как указано в комментариях full.stack.ex.
В этой модели мы предполагаем, что большинство людей посещают нашу систему, скажем, в полдень. Это пиковое время. Другие прыгают вперед или отстают, чем дальше, тем меньше; Никто не в полночь. Мы выбрали кривую колокольчика, которая разумно покрывает все запросы в течение 24-часового периода: примерно с 4 сигмами слева и 4 справа, в длинном хвосте не остается ничего значительного. Чтобы смоделировать самый пик, мы вырезали узкую полоску около полудня и посчитали там запросы.

Следует отметить, что на практике эта модель имеет тенденцию переоценивать пиковый трафик и может оказаться более полезной при оценке сценария «наихудшего случая», а не более вероятных моделей трафика. Предварительные предложения по улучшению оценки

  • расширить sigпараметр (чтобы признать, что эффективный период трафика относительно высокого трафика больше)
  • уменьшить общее количество посещений за рассматриваемый период, т.е. уменьшить Vпараметр, скажем, на 20% (чтобы признать, что примерно такое количество посещений происходит вне какого-либо пикового времени)
  • использовать другое распределение, такое как, скажем, пуассоновское или некоторое биномиальное распределение.
  • учитывать, что каждый день существует ряд пиков и что кривая трафика фактически является суммой нескольких нормальных (или других распределительных) функций с аналогичным разбросом, но с отчетливым пиком. Предполагая, что такие пики находятся достаточно далеко друг от друга, мы можем использовать исходную формулу, только с Vкоэффициентом, деленным на столько пиков, сколько рассмотрено.

[оригинальный ответ]
Похоже, что ваша непосредственная задача заключается в том, как сервер (-ы) может справиться с дополнительной нагрузкой ... Очень достойная проблема ;-). Не отвлекая вас от этой оперативной задачи, рассмотрите процесс оценки масштабов предстоящего всплеска, а также предоставьте возможность подготовиться к тому, чтобы собирать больше и больше информации о трафике сайта во время и после рекламной кампании. Такая информация со временем окажется полезной для более точных оценок скачков напряжения и т. Д., А также для руководства некоторыми аспектами дизайна сайта (для коммерческой эффективности, а также для повышения масштабируемости).

Предварительный план

Предположим, качественное сходство с существующим трафиком.
В рамках рекламной кампании сайт будет представлен населению, отличающемуся от текущего типа посетителей / пользователей: разные ситуации выбирают разные темы. Например, посетители "рекламной кампании" могут быть более нетерпеливыми, сосредоточенными на конкретной функции, озабоченными ценой ... по сравнению с "самостоятельно выбранными?" посетители. Тем не менее, из-за отсутствия какой-либо другой поддерживающей модели и измерения, а также для оценки нагрузки, общий принцип может заключаться в том, чтобы предполагать, что пользователи перенапряжения в целом будут вести себя подобно толпе, выбранной самим собой. Обычный подход - это «число прогонов» на этой основе и использование образованных догадок, чтобы слегка согнуть коэффициенты модели, чтобы учесть несколько отличительных качественных различий.

Соберите статистику о существующем трафике.
Если у вас нет для этого лучшей информации (например, tealeaf, Google Analytics ...), вашим источником такой информации может быть просто журнал веб-сервера ... Затем вы можете создать несколько простых инструментов для извлечения парсинга этих журналов. и извлеките следующую статистику. Обратите внимание, что эти инструменты будут многократно использоваться для последующего анализа (например, самой кампании), а также искать возможности регистрации большего количества / различных данных без значительного изменения приложения!

  • Средний, Мин, Макс, Станд. Дев. за
    • количество страниц, посещенных за сеанс
    • продолжительность сеанса
  • процент от 24-часового трафика для каждого часа рабочего дня (исключая выходные и т. д., если, конечно, это не тот сайт, который получает много трафика в эти периоды). Эти процентные доли должны быть рассчитаны по крайней мере за несколько недель для устранения шума.

Выполните некоторые оценки :
например, начните с оценки пикового использования, используя процентную долю пиковых часов, среднее число ежедневных сеансов, среднее число посещений страниц за сеанс и т. Д. Эта оценка должна учитывать стохастический характер движение. Обратите внимание, что на этом этапе вам не нужно беспокоиться о влиянии эффекта очереди, вместо этого предположите, что время обслуживания относительно периода запроса достаточно мало. Поэтому просто используйте реалистичную оценку (или, скорее, значение, полученное из анализа журнала, для этих очень высоких периодов использования), для способа распределения вероятности запроса в течение коротких периодов (скажем, 15 минут).

Наконец, основываясь на числах, которые вы получили таким образом, вы можете почувствовать тип поддерживаемой нагрузки, которая будет представлена ​​на сервере, и запланировать добавление ресурсов для рефакторинга части приложения. Также - очень важно! - если прогнозируется устойчивая нагрузка при загрузке, начните использовать формулу Поллачека-Хинчина, как это предложено ChrisW, чтобы получить более точную оценку эффективной нагрузки.

Для дополнительного кредита ;-) Подумайте о проведении некоторых экспериментов во время кампании, например, случайным образомобеспечение особого внешнего вида или поведения для некоторых посещенных страниц, и путем измерения влияния, которое это может оказать (если таковое имеется) на определенные показатели (регистрация для получения дополнительной информации, места заказов, количества посещенных страниц ...) Усилия, связанные с этим тип эксперимента может быть значительным, но отдача также может быть существенной, и, если ничего другого, это может держать вашего «эксперта / консультанта по применимости» в затруднительном положении ;-) Вы, очевидно, захотите поработать над определением таких экспериментов, с соответствующими маркетинговыми / деловыми властями, и вам может понадобиться заранее рассчитать минимальный процент пользователей, для которых будет предложен альтернативный сайт, чтобы сохранить эксперимент статистически репрезентативным. Действительно важно знать, что эксперимент не должен применяться к 50% посетителей; можно начать с малого,

4
17.12.2012 21:02:31
Текущий трафик очень низкий, поэтому я не могу экспериментировать. Ожидается, что трафик будет выглядеть как всплеск один или два дня. Все, что дается, это количество посетителей в день. Нет возможности для экспериментов.
ulver 13.10.2009 14:32:52
@ full.stack.ex Основным предположением является то, что трафик на веб-сайт обычно распределяется в течение 24 часов. Другими словами, в течение 24 часов существует один конкретный момент времени, когда трафик (количество активных сеансов или количество запросов страниц) является наибольшим, и этот объем трафика снижается с обеих сторон этого пика, в скорость подразумевается формулами стандартного (или гауссовского) распределения.
mjv 17.12.2012 01:42:58
(продолжение) x- это время (от 0 до 24 ч), которое yпредставляет собой процент трафика (по отношению к общему 24-часовому трафику, то есть относительно V или V * PPV, в зависимости от того, как определяется «трафик»: как число посетителей или количество запросов страниц в данный момент). С точки зрения вероятностей, yэто вероятность того, что любое конкретное посещение (или запрос страницы, опять же в зависимости от определения «трафика») произойдет в конкретный момент времени x. sigто есть значение ОДНОГО стандартного отклонения этой гипотетической кривой колокола.
mjv 17.12.2012 01:43:43
(продолжение) формула просто вычисляет [среднюю] частоту запросов страниц за интервал времени 2/10-го от одного StdDev, 1/10-й каждый по обе стороны от пика. (Опять же, исходя из предположения о стандартном распределении запросов страниц в течение 24 часов; возможно, и как указывалось в ответе, это предположение может привести к переоценке пикового трафика.)
mjv 17.12.2012 01:49:18
@mjv: Спасибо за ваше (воскресенье?) время! Поэтому я думаю, что это может быть действительным «резюме»: в этой модели мы предполагаем, что большинство людей посещают нашу систему, скажем, в полдень. Это пиковое время. Другие прыгают вперед или отстают, чем дальше, тем меньше. Никто не в полночь. Мы выбрали кривую колокольчика, которая разумно покрывает все запросы в течение 24-часового периода: примерно с 4 сигмами слева и 4 справа "ничего" не остается в длинном хвосте. Чтобы смоделировать самый пик, мы вырезали узкую полоску около полудня и посчитали там запросы. Мы также можем смоделировать весь профиль за 24 часа. Спасибо!
full.stack.ex 17.12.2012 08:10:38

Это будет зависеть от маркетинговой кампании. Например, телевизионная реклама принесет много трафика сразу, для газетной рекламы она будет распространяться больше в течение дня.

Мой опыт работы с маркетинговыми типами заключался в том, что они просто выбирают число, из которого солнце не светит, как правило, выше, чем реальность, по крайней мере на порядок

1
13.10.2009 02:42:38

Я бы начал с предположения, что «в день» означает «в течение 8-часового рабочего дня», потому что это сценарий наихудшего случая, который, возможно, не излишне наихудший.

Таким образом, если вы получаете в среднем 100 000 за 8 часов, и если время прибытия каждого из них является случайным (независимо от других), то через несколько секунд вы получаете больше, а через несколько секунд вы получаете меньше. Детали - это область знаний, которая называется « теория очередей ».

Если предположить, что формула Поллачека-Хинчина применима, то, поскольку ваше время обслуживания (т. Е. Процессорное время на запрос) довольно мало (т. Е. Меньше секунды, вероятно), поэтому вы можете позволить себе иметь довольно высокое значение (т. Е. Более 50%). ) использование сервера.

Таким образом, предполагая, что время на запрос невелико, вам нужна емкость, которая выше (но вот хорошие новости: не намного выше), чем все, что требуется для обслуживания среднего спроса.

Плохая новость заключается в том, что если ваша емкость меньше, чем средняя потребность, то средняя задержка в очереди бесконечна (или, более реалистично, некоторые запросы будут отменены до их обслуживания).

Другая плохая новость заключается в том, что, когда у вас мало времени на обслуживание, вы чувствительны к временным колебаниям среднего спроса, например ...

  • Если спрос достигает максимума во время обеденного перерыва (то есть не соответствует среднему спросу, как в другие часы), или даже если по какой-то причине он достигает максимума в течение 5-минутного периода (например, во время перерыва в телевизионной рекламе)

  • И если вы не можете позволить, чтобы клиенты стояли в очереди на этот период (например, очередь на весь обеденный перерыв или, например, весь пятиминутный рекламный перерыв)

... тогда вашей способности должно быть достаточно для удовлетворения этих краткосрочных пиковых требований. OTOH вы можете решить, что вы можете позволить себе потерять излишки: что не стоит проектировать для пиковой пропускной способности (например, нанимать дополнительных сотрудников колл-центра во время обеденного перерыва) и что вы можете позволить себе некоторый процент оставленных вызовов.

2
13.10.2009 03:29:33