Редактировать : (после указания на то, что у нас практически нет предварительной статистики по трафику)
Поэтому мы можем забыть об основной части плана, изложенного ниже, и непосредственно попадает в часть «Выполнить некоторые оценки» . Проблема в том, что нам нужно будет заполнить параметры из модели, используя образованные догадки (или простые дикие догадки). Ниже приведена простая модель, для которой вы можете настроить параметры в зависимости от вашего понимания ситуации.
Модель
Допущения :
а) Распределение запросов страниц следует кривой нормального распределения .
b) Учитывая короткий период во время пикового трафика , скажем, 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% посетителей; можно начать с малого, но не настолько, чтобы возможные наблюдаемые изменения могли быть случайными ...