編集:(トラフィックに関する事前統計が事実上ないことを示した後)
したがって、以下に示す計画の大部分を忘れて、「いくつかの見積もりを実行する」部分に直接入ることができます。問題は、知識に基づいた推測(または単純な野生の推測)を使用してモデルからパラメーターを入力する必要があることです。以下は、状況の理解に基づいてパラメーターを微調整できる単純なモデルです。
モデル
仮定:
a)ページ要求の分布は、正規分布曲線に従います。
b)トラフィックのピーク時の短い期間、たとえば30分を考慮すると、リクエストの数は均等に分散されていると見なすことができます。
これは[やや]正しくない可能性があります。たとえば、広告キャンペーンが複数の地域、たとえば米国とアジアの市場をターゲットにしている場合、二重の曲線になる可能性があります。また、曲線は異なる分布に従う可能性があります。ただし、これらの仮定は、次の理由から適切なものです。
- 仮にあったとしても、「悲観的な側面」、つまりピークトラフィック値を過大評価することは誤りです。この「悲観的な」見通しは、わずかに小さい標準偏差値を使用することでさらに採用できます。(2〜3時間使用することをお勧めします。これにより、トラフィックの68%と95%が、それぞれ4時間と8時間(2h std dev)と6時間と12時間(3h stddev)になります。
- それは簡単な計算になります;-)
- それは一般的に現実と一致することが期待されます。
パラメータ:
- V=24時間あたりの個別の訪問者の予想数
- Ppv=特定の訪問者セッションに関連付けられたページリクエストの平均数。(式を2回使用することを検討できます。1つは「静的」タイプの応答用で、もう1つは動的応答用です。つまり、アプリケーションが特定のユーザー/コンテキストの応答の作成に時間を費やす場合です)
- sig=分単位の標準偏差
- R=1分あたりのピーク時のリクエスト数。
式:
R = (V * Ppv * 0.0796)/(2 * sig / 10)
これは、正規分布の場合、zスコアの表によると、サンプルの約3.98%が、平均の片側または反対側(ピークの)で標準偏差の1/10以内に収まるためです。各側の標準偏差の10分の1以内にサンプルのほぼ8%を取得し、この期間中の分布が比較的均一であると仮定して、分数で割るだけです。
例:V = 75,000 Ppv=12およびsig=150分(つまり、トラフィックの68%が5時間以上、95%が10時間以上、残りの14時間は5%になると想定)。R = 1分あたり2,388リクエスト、つまり1秒あたり40リクエスト。かなり重いですが、「実行可能」です(アプリケーションがリクエストごとに15秒かかる場合を除く...)
編集(2012年12月)
:コメントで提供されているように、上記で提案されたモデルの「エグゼクティブサマリー」をここに追加しますfull.stack.ex
。
このモデルでは、ほとんどの人が正午などにシステムにアクセスすると想定しています。それがピーク時です。他の人は先にジャンプしたり遅れたりしますが、遠くなるほど少なくなります。真夜中に誰もいない。24時間以内のすべての要求を合理的にカバーするベルカーブを選択しました。左側に約4シグマ、右側に4シグマがあり、ロングテールには「何も」重要なものが残っていません。ピークをシミュレートするために、正午の周りに細いストライプを切り取り、そこでリクエストをカウントします。
このモデルは、実際には、ピークトラフィックを過大評価する傾向があり、より妥当なトラフィックパターンよりも、「最悪の場合」のシナリオを推定するのに役立つ可能性があることに注意してください。見積もりを改善するための暫定的な提案は次のとおりです。
- パラメータを拡張する
sig
(比較的トラフィックの多い有効なトラフィック期間が長いことを確認するため)
- 考慮される期間の全体的な訪問数を減らす、つまりパラメータを20%減らす(その多くの訪問がピーク時間外
V
に発生することを認める)
- ポアソン分布や二項分布など、別の分布を使用します。
- 毎日多くのピークがあり、トラフィック曲線は実際には同様の広がりを持つが明確なピークを持ついくつかの通常の(または他の分布)関数の合計であると考える必要があります。このようなピークが十分に離れていると仮定すると、元の式を使用できますが、
V
係数を考慮した数のピークで割ったものだけです。
[元の応答]
あなたの当面の懸念は、サーバーが余分な負荷をどのように処理するかということのようです...非常に価値のある懸念;-)。この運用上の懸念から気を散らすことなく、今後の急増の規模を見積もるプロセスを検討してください。また、広告キャンペーン中およびそれ以降に、サイトのトラフィックに関するより多くのより良いインテリジェンスを収集する準備をする機会も提供します。このような情報は、やがてサージなどをより正確に見積もるのに役立つだけでなく、サイトの設計の一部をガイドするのにも役立ちます(商業効率とスケーラビリティの向上のため)。
暫定計画
既存のトラフィックとの質的な類似性を想定します。
広告キャンペーンは、現在の訪問者/ユーザーの母集団とは異なる母集団(ユーザーのタイプ)にサイトを公開します。さまざまな状況でさまざまな主題が選択されます。たとえば、「広告キャンペーン」の訪問者は、「自分で選んだ?」と比較して、より焦り、特定の機能に焦点を合わせ、価格を心配する場合があります。訪問者。それでもなお、他のサポートモデルと測定値がないため、また負荷を推定するために、一般的な原則は、サージユーザーが全体として自己選択した群集と同様に動作すると想定することです。一般的なアプローチは、これに基づく「実行数」であり、知識に基づいた推測を使用してモデルの係数をわずかに曲げ、いくつかの特徴的な定性的な違いに対応します。
既存のトラフィックに関する統計を収集
するこれに関するより良い情報(tealeaf、Google Analyticsなど)がすぐに得られない限り、そのような情報のソースは単にWebサーバーのログである可能性があります...次に、これらのログを抽出して解析するための簡単なツールを構築できます次の統計を抽出します。これらのツールは、将来の分析(キャンペーン自体など)に再利用でき、アプリケーションを大幅に変更することなく、より多くの/異なるデータをログに記録する機会を探すことに注意してください。
- 平均、最小、最大、標準偏差 にとって
- セッションごとにアクセスしたページ数
- セッションの期間
- 1日の1時間あたりの24時間トラフィックの割合(週末などを除きます。もちろん、これらの期間中に多くのトラフィックを受信するサイトでない限り)これらの割合は、少なくともノイズを除去するために、数週間にわたって計算する必要があります。
いくつかの見積もりを「実行」する:
たとえば、ピーク使用率の見積もりから始め、ピーク時間の割合、1日の平均セッション数、セッションあたりの平均ページヒット数などを使用します。この見積もりでは、次の確率的性質を考慮に入れる必要があります。トラフィック。このフェーズでは、キューイング効果の影響を心配する必要はありません。代わりに、要求期間に対するサービス時間が十分に短いと想定してください。したがって、要求の確率が短期間(たとえば、15分)に分散される方法については、現実的な見積もり(または、これらの非常に高い使用期間については、ログ分析から通知された値)を使用してください。
最後に、この方法で取得した数値に基づいて、これがサーバー上で表す持続的な負荷のタイプを把握し、アプリケーションの一部をリファクタリングするためにリソースを追加することを計画できます。また、-非常に重要です!-持続的な容量負荷の見通しがある場合は、ChrisWによって提案されているように、Pollaczek-Khinchine式の実行を開始して、有効負荷のより良い見積もりを取得します。
追加のクレジットについて;-) キャンペーン中に、たとえばランダムにいくつかの実験を実行することを検討してください訪問したページの一部に明確な外観または動作を提供し、これが特定のメトリック(詳細情報の登録、注文場所、訪問したページ数など)に与える影響を測定することにより、これに関連する作業実験の種類は重要かもしれませんが、リターンも重要である可能性があり、他に何もなければ、それはあなたの「ユーザビリティの専門家/コンサルタント」を彼/彼女のつま先に保つかもしれません;-)あなたは明らかにそのような実験の定義に取り組みたいでしょう、適切なマーケティング/ビジネス当局と協力し、実験を統計的に代表するために、代替サイトが提案されるユーザーの最小パーセンテージを事前に計算する必要がある場合があります。実験を訪問者の50%に適用する必要がないことを知っておくことは確かに重要です。小さく始めることができます、