1

仮に、マーケティングキャンペーンが成功した結果として、誰かが1日あたりX(100,000など)のユニークな訪問者を期待するように言ったとテッツは言います。

それはどのようにピークリクエスト/秒に変換されますか?同時リクエストのピーク?

明らかに、これは、ユーザーセッションごとに要求される一般的なページ数や一般的なページの読み込み時間など、多くの要因に依存します。これらは他の変数Y、Z、Vなどです。

これらのメトリックを推定するために、ある種の関数または単なる比率を探しています。明らかに、本番環境のスケーラビリティ戦略を計画するためです。

これは、私がすぐに取り組んでいる本番サイトで発生する可能性があります。これらを推定するためのあらゆる種類のヘルプが役立ちます。

4

3 に答える 3

4

編集:(トラフィックに関する事前統計が事実上ないことを示した後)
したがって、以下に示す計画の大部分を忘れて、「いくつかの見積もりを実行する」部分に直接入ることができます。問題は、知識に基づいた推測(または単純な野生の推測)を使用してモデルからパラメーターを入力する必要があることです。以下は、状況の理解に基づいてパラメーターを微調整できる単純なモデルです。

モデル

仮定
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%に適用する必要がないことを知っておくことは確かに重要です。小さく始めることができます、

于 2009-10-13T04:23:33.747 に答える
2

まず、「1日あたり」は「8時間の営業日中」を意味すると仮定します。これは、おそらく不必要に最悪の場合ではなく、最悪のシナリオであるためです。

したがって、8時間で平均100,000を取得し、それぞれが到着する時間がランダムである場合(他の時間とは無関係)、数秒でより多くを取得し、数秒でより少なくなります。詳細は「待ち行列理論」と呼ばれる知識の一分野です。

Pollaczek-Khinchineの式が適用可能であると仮定すると、サービス時間(つまり、要求ごとのCPU時間)が非常に短い(つまり、おそらく1秒未満)ため、かなり長い(つまり、50%を超える)余裕があります。 )サーバー使用率。

要約すると、リクエストあたりの時間が短いと仮定すると、平均的な需要に対応するために必要な容量よりも高い容量が必要になります(ただし、ここに良いニュースがあります。それほど高くはありません)。

悪いニュースは、容量が平均需要よりも少ない場合、平均キューイング遅延は無限大であるということです(または、より現実的には、一部の要求は処理される前に破棄されます)。

もう1つの悪いニュースは、サービス時間が短い場合、平均需要の一時的な変動に敏感であるということです。たとえば、...

  • 需要が昼食時間中にピークに達した場合(つまり、他の時間と同じ平均需要ではない場合)、または何らかの理由で5分間にピークに達した場合(たとえば、テレビコマーシャルの休憩中)。

  • また、その期間に顧客をキューに入れる余裕がない場合(たとえば、昼食時間全体、または5分間のコマーシャル休憩全体)

...次に、これらの短期的なピーク需要を満たすのに十分な容量が必要です。OTOH余剰分を失う余裕があると判断するかもしれません。つまり、ピーク時のキャパシティを設計する価値がなく(たとえば、昼休みにコールセンターのスタッフを追加で雇う)、放棄された通話の一部を支払う余裕があるということです。

于 2009-10-13T03:10:42.133 に答える
1

それはマーケティングキャンペーンに依存します。たとえば、テレビ広告は一度に多くのトラフィックをもたらしますが、新聞広告の場合は1日を通してより多くのトラフィックが広がります。

マーケティングタイプに関する私の経験では、太陽が輝いていない場所から数字を引き出すだけで、通常は現実よりも少なくとも1桁高くなっています。

于 2009-10-13T02:42:38.477 に答える