Why use a rate-based Virtual Waiting Room instead of a simple queue?

A rate-based Virtual Waiting Room does more than just hold visitors; it controls exactly how many people are allowed through over time. A simple queue may preserve order, but won't deliver stable load when there is abandonment, or people going away from the queue and coming back after their turn has been called. A rate-based queue focused on delivering the exact right number of people to the site every minute is much better at preserving stability. For enterprise organisations, that distinction is critical. During a launch, onsale, or major public event, you do not just need fairness; you need controlled throughput. If too many users are released in one burst, the site can still slow down or fail. Auto-scaling helps with gradual traffic increases, but sudden surges happen faster than scaling can react, so you need a mechanism that actively meters demand in real time. Queue-Fair is built around that principle. It gives enterprise-level organisations accurate, rate-based control, first-come, first-served fairness, and a much better chance of keeping the site stable during extreme demand. It can usually be deployed in about five minutes with a single line of code, and Free Queue lets teams get started for free.

How does a rate-based approach help prevent website crashes?

A rate-based approach helps prevent crashes by smoothing the arrival of visitors into a stable flow. Instead of opening the gate too widely and hoping the site copes, it meters access at a pace the origin can actually handle. That keeps pressure on critical services under control and reduces the chance of a sudden concurrency shock taking down the platform. This is more effective than relying on infrastructure alone because infrastructure is often reactive. If a traffic spike lands within seconds, for example from ticket onsales or timed product launches, extra instances and capacity may not come online quickly enough to stop the first wave from overwhelming the bottleneck. A rate-based Virtual Waiting Room deals with the traffic pattern itself, which is often the true cause of the incident. Queue-Fair gives organisations that protection in a form that is both powerful and easy to deploy. With one line of code, around five minutes to go live, and a Free Queue option at no cost, enterprise teams can quickly add a highly practical defence against crashes, overload errors, and unstable customer journeys.

When is a rate-based Virtual Waiting Room most useful?

It is most useful when demand is intense, sudden, and commercially important. That includes ticket on-sales, product drops, flash sales, presales, public deadlines, campaign launches, and any event where many people are likely to arrive together. In these situations, the challenge is not merely the number of visitors but the concentration of arrivals in a short time window. A rate-based approach is especially valuable for enterprise organisations because it supports operational control. Teams can protect the site, maintain fairness, and tune throughput to match real-world conditions instead of guessing. That means fewer crashes, fewer emergency interventions, and a better customer experience during the moments that matter most. Queue-Fair is designed exactly for those high-pressure scenarios. It combines rate-based accuracy, fairness, rapid deployment with a single line of code, and a Free Queue option for free. That makes it one of the fastest and most effective ways to prepare a website for sudden demand without waiting for a major replatforming or infrastructure project.

オンラインキューを利用することでサイトのクラッシュを防ぐ方法とWebサイトのクラッシュについて

トラフィックのピーク時に、Webサーバーは同じサーバーポートに対して何回のリクエストを処理できるのでしょうか？

従来の負荷推定

従来、eコマースサーバーは最大同時利用者数をサポートするようにプロビジョニングされており、負荷もこのように定義されることが多かった。この方法を用いてウェブサイトのキューを実行することには問題がある。この問題は、料金で解決される。

この問題は、訪問者が実際にウェブサーバーを使用しているのは、ブラウザが各ウェブページを読み込んでいる間だけであることから発生する。

以下はその一例です。

例えば、あるeコマースサイトがチケットを販売しているとします。訪問者の旅の始まりから終わりまで（ユーザーセッション）には、訪問者として6つのページがあります。

が到着する。
は、イベントのページに移動します。
は、特定のイベントのページを見ることができます。
は、座席とチケットを選択します。
は、支払情報を入力し
には、注文確認ページが表示されます。

取引にかかる時間は平均5分です。

再び例として、毎分100人の訪問者がチケット購入のためにやってきて、処理が完了するまでの平均時間が5分だとします。ある瞬間に500人が同時にトランザクション処理に参加することになり、サーバーは500人の同時使用ユーザーに対応できるようにプロビジョニングされなければなりません。

同時接続ユーザーのカウント

新しい訪問者がホームページに到着するたびにインクリメントされ、訪問者がトランザクションを完了するたびにデクリメントされるConcurrent User Counterを作成すれば、1つのサーバーが一度に処理するユーザー数がわかると思うかもしれませんが、これはうまくいきません。

すべての訪問者が取引を完了するわけではないので、うまくいかないでしょう。人は気が変わったり、気が散ったり、一旦離れてから後で戻ってきたりするものです。ウェブサーバーが訪問者とやりとりするのは、訪問者のブラウザがページを読み込んでいるときだけなので、それがいつ、誰に対して起こったのか、ウェブサーバーには知るすべがないのです。

その代わりに、ある訪問者が取引プロセスから外れたと判断するために、単一サーバーはその訪問者からのページ要求がもう来ないことを確認し、その訪問者のセッションをタイムアウトさせる必要があります。タイムアウトは常に平均的なトランザクション時間（この例では20分）よりも長く設定する必要があります。

この方法で、訪問者のセッションがタイムアウトするたびに、自分の想定する同時使用ユーザーカウンターを減少させる機能を追加することもできますが、これは非常に悪い結果をもたらします。

毎分100人の訪問者のうち10％が取引完了に至らなかった場合、完了したものは平均5分、完了しなかったものは常に少なくとも20分アクティブであると考えられます（実際には複数セッションを考慮すると、セッションタイムアウト＋平均セッション時間の方が可能性が高くなります）。

つまり、90 * 5 + 10 * 20 = 650であり、サーバーは実際にはそれほど忙しくないにもかかわらず、650の同時使用ユーザーを報告することになります。

タイムアウトユーザーについてはどうでしょうか？

さらに、その同時接続ユーザーのうち、10 * 20 = 200人ものユーザーが実際にはサイトを利用せず、タイムアウトしている最中であり、トランザクションを完了できない訪問者は10％に過ぎないにもかかわらず、報告された同時接続ユーザーの30％以上となっています。

さて、このウェブサイトに、同時接続ユーザカウンタで制御される待ち行列を追加したいとしましょう。サイトが定員に達したら、キューの先頭にいる個人は、カウンターが減少したときだけサイトに通されます。これをワンアウト・ワンインキューと呼びます。この場合、30％の確率で、待ち行列の先頭にいる人は、取引を完了するつもりのない人が、取引を完了しないまま終わるのを待っていることになります。

それは非常に明確に壊れています。

また、カウンターを作成・運営し、その情報をキュー・システムと共有するための技術的な統合作業やWebサイトへの負荷が追加されます。共有やカウントの仕組みがダウンしたり壊れたりすると、キューは立ち往生してしまいます。さらに悪いことに、もし単一サーバーが非常に忙しくなって、キューサーバーに次の人を入れるように伝えるための更新ができなくなると、キューも動かなくなります。

その解決策料金の使用

これらの問題はすべて、代わりにキューの先頭から一定の固定レート（この場合は1分間に100人）で訪問者を送ることで簡単に解決します。

そうすれば、実際の同時接続ユーザー数を計測する必要もなく、チケット販売サイトとの複雑な連携も必要なく、キューが滞留するリスクもありません。

そのため、私たちは2004年に、忙しいウェブサイトのための料金ベースのバーチャル待合室を発明し、特許を取得しました。

ウェブアプリケーションにおける検索クエリの同時トラフィックは、ウェブサーバーが処理するリクエスト数またはユーザー数に影響します。

負荷テスト httpリクエストウェブサーバーが余分なサーバーリソースを使わずに処理できるリクエスト数

ウェブサーバーは何人の同時ユーザーを扱えるのか？

Webサーバーが処理する同時アクセスユーザー数と、トランザクションフローの最初のページから注文確認ページまでの平均トランザクション時間または訪問時間がわかっていれば、次のようにユーザー数を時間で割って、リトルの法則を使ってキュー・レートに変換することができます。

キュー・レート＝同時接続ユーザー数／トランザクション時間

レートベースのキューシステムはどの程度の精度なのでしょうか？

Queue-Fairは、お客様が指定した速度でウェブサイトへの訪問者を配信します。業界で最も正確なキューAIにより、順番が呼ばれたときに不在だった人や、遅れて戻ってきた人を自動的に考慮し、毎分欲しい訪問者数を確実に獲得することができます。

これは、同時接続ユーザー数にどう反映されるのでしょうか？もちろん、あなたのサイトにアクセスしたすべての訪問者が、トランザクションを完了するまでに平均トランザクション時間通りにかかるわけではありませんが、Queue-Fairでは、大数の法則により、非常に安定した同時接続ユーザー数を得ることができます。

例えば、キューレートが1分間に100人の訪問者があるとします。私たちは、毎分100人の訪問者を安定した流れであなたのサイトに送ります。また、人々があなたのウェブサイトを平均（平均値）5分間利用し、そのうちの70%が、キューを通過してから最後のページ要求を行うまで（トランザクションを完了するかどうかにかかわらず）4～6分かかるとします。これは、平均値の左右に1分ずつの標準偏差があることになります。統計的に言えば、5分半かかる訪問者がいれば、4分半かかる訪問者もいるということです。したがって、複数のセッションにわたる個々の訪問時間のばらつきは、何らかの方法で多くの訪問者を数えるときに、互いに相殺される傾向があります。大数の法則」によれば、この相殺は、関係する人数が多ければ多いほど、より正確になる。

正確にはどのくらい？ これは、ちょっとした統計学で解明できる。サンプルサイズは5×100＝500で、これがここでいう「大きな数」です。これは、あなたがカウントしている人数のことです。つまり、平均の標準誤差の統計的公式に従って、取引時間の平均の標準誤差は1（標準偏差、1分）をサンプルサイズの平方根（つまり500の平方根）で割ったものとなり、取引時間の標準誤差は0.044分、つまりわずか2.7秒、これは1％未満です。

つまり、キューレートが100で、個々の訪問者のトランザクション時間が5分前後であれば、サイトの同時利用者数は495～505人で、70%程度の時間であると予想され、レートベースのキューを使用すれば、Webサーバーに希望通りの非常に安定した負荷がかかるという計算となります。

しかし、この計算は正確でしょうか？例えば、同時接続ユーザーをカウントするたびに（つまり、任意の時点で）サンプルサイズが正確に500になるとは限りませんし、正規（ガウス）分布では、現実には発生しない負のトランザクション時間を与えることができます。そこで、訪問者ごと、1秒ごとのシミュレーターで測定し、この種の計算をチェックします。その結果、上記の数値では、70%の確率で493～507人の訪問者を期待できることがわかりました。また、データを測定した結果、少なくとも95％の確率で500±15人の同時接続ユーザーが存在することが分かりました。

これはおそらく、ウェブサーバーがあなたのサイトを利用する人の数を測定する精度よりも安定していると言えるでしょうさらに、ここで本当に素晴らしいことは、たとえあなたが訪問者の平均トランザクション時間や標準偏差を知らないとしても、あなたが知っているかどうかに関わらずこれらの数学的数量は存在し、とにかく安定した負荷を得ることができる、ということです。

その結果、Queue-Fairはほぼ完璧な精度で1分あたりの訪問者数を提供し、あなたのサイトに非常に安定した同時ユーザー数をもたらし、あなたが完全にコントロールできる安定したウェブサーバー負荷を実現します。

万歳!

そして今、警告です。あなたのサイトの同時ユーザー数の安定性、したがってサーバーの負荷の安定性は、あなたの仮想待合室プロバイダーがどれだけ正確にあなたが望む毎分の訪問者数を送信するかに決定的に依存し、したがって、これはあなたが仮想待合室のプラットフォームを選択する際の重要な要因であることは注目に値します。私たちは世界で最も正確なVWを提供しており、Queue-Fair以上にサーバーのフラッディングを防ぐことはできません。

キューレートを簡単に計算する方法

サーバーが処理できる同時使用ユーザー数やトランザクション時間がわからない場合はどうすればよいでしょうか。ボトルネックとなりそうなページ、通常は「今すぐ購入」ボタンをクリックした結果表示されるページを調べることができます。 Google Analyticsを使って、そのページへの月間ユニークビジター数を調べたり、月間注文数を数えたりしてください。これを30 * 24 * 60 = 43,200で割ると、1ヶ月の分数（約）になります。これは、1ヶ月間の1分あたりの平均訪問者数です。これを3で割ってください。これは、営業時間中の1分あたりの平均訪問者数です（約）。これを2倍してください。これが、キューレートとして使用する安全な数字でしょう。

例えば、1ヶ月に10万件の注文を処理するとします。これは「今すぐ購入」ボタンが10万回クリックされたことになります。この場合、100,000 / 43,200 = 2.31 件/分の注文が発生します。これらの注文のほとんどは日中にあり、夜間はサーバーが静かであることが予想されるため、これを3倍すると、1分間に7件の注文があり、営業時間中のサーバーの忙しさの目安になります。 50未満の場合：需要の山と谷があるため、ピーク時にサーバーの速度が著しく低下しない場合は、これに2を掛けて、1分間あたりのアクティブユーザー数を14とします。数値が50以上の場合：分単位のピークと谷が比較的に小さくなるので、これを2倍にするのは安全ではありません。最終的に得られる数値は、おそらくQueue Rate の安全な数値で、安全に管理できる 1 秒あたりのリクエスト数に相当します。

注文がタイムスタンプで記録されている場合、過去1ヶ月の1分間の最大注文数を見ることもできます。ただし、この1分間の間にサーバーの速度低下によりどれだけの注文が落ちたかは分からないので、20%減額して使用するようにしましょう。

この記事の残りの部分では、Queue Rateを計算する他のいくつかの方法について説明します。

於乎 #1: 同時使用ユーザー数 vs 同時リクエスト数 vs 同時接続数 vs 同時セッション数

一般的に使われている「同時使用ユーザー」には、少なくとも2つの定義があることを指摘しておく必要があります。

私たちは、「あるトランザクションフローに一度に従事する人の数」という定義を使っています。これは、Queue Rateを設定するために知っておくべき重要な数値です。今、あなたのサイトを閲覧しているユーザーの数です。通常、同時セッション数は、同時接続数や同時ユーザー数よりも多少多くなります。これは、一部のセッションがタイムアウトする過程で、平均セッション時間が長くなるためです。

これに対して、同時リクエスト数は、ウェブサーバーが一度に処理するHTTPリクエストの数です。非常に紛らわしいのですが、多くの技術者は、「同時使用ユーザー数」と言う場合、「同時使用リクエスト数」と言います。

次に、同時接続（またはネットワークインターフェースカードの同じサーバーポートへの同時 TCP 接続）ですが、これはサーバーポートまたはバックエンドサービスで一度に開いている TCP/IP ソケットの数です。ページへのリクエストを行う際、ブラウザはデフォルトで、ページからのさらなるリクエストや、ユーザーが別のページに移動した場合に備えて、接続を開いたままにしておきます。これにより、新しいTCP/IP接続を開くための1秒あたりのリクエスト数が減り、サーバープロセスがより効率的になります。これらの同時接続のタイムアウトは、60秒からnever-closeまで、ブラウザによって異なります。サーバーは、一定期間操作がないと自動的に接続を閉じることもあります。Linuxのウェブサーバーでは、このコマンドで同じサーバーポートへの同時接続数を取得することができます。

netstat -aenp | grep ":80 \|:443 " | wc -l

というのがありますが、気になる方は試してみてください。これも「同時ユーザー」と呼ぶ人がいますが、本当は「同時接続」という意味です。

実際、ホスティングプロバイダーにウェブサーバーが処理する最大同時接続ユーザー数（ピーク時のトラフィック量）を教えてほしいと頼んだ場合、おそらく実際には同時セッション、同時リクエスト、同時接続のいずれかの数字を示すでしょう。これは、平均トランザクション時間、トランザクションフロー内のページ数、その他ウェブサーバーの同時ユーザー数を知らせるための情報を知らないという単純な理由からです。これらの数値はすべて異なる値を持っています。

ホスティングプロバイダーや技術チームに最大トラフィックレベルに関する情報を求める場合、同時ユーザー数、同時セッション数、同時リクエスト数、同時接続数のいずれを意味するのかを明確にすることが非常に重要です。

これを間違えると、Webサイトがクラッシュする可能性があります。

その理由は次のとおりです。各ページは1つのHTTPリクエストですが、ブラウザがページを表示するために使用する、ウェブアプリケーションから来る画像、スクリプト、その他のファイルもすべてHTTPリクエストです。

技術担当者から「サーバーは500同時ユーザーをサポートしている」と言われたが、実際には「500同時リクエスト」を意味しているとします。トランザクション時間が5分で、上記の計算式を使って、サイトが1分間に100人の訪問者をサポートできると仮定します。

できる？いいえ

人々がトランザクションフローを通過するとき、実際にサーバーにリクエストを出すのは、各ページがロードされている間だけです。これは、サーバーが処理できる1秒あたりのトラフィック量やアクティブユーザー数に影響します。 5分間のトランザクション時間のうち、平均的なユーザーにとっては数秒にすぎません。したがって、500同時リクエストは、より多くの同時ユーザーを処理できることを意味すると思うかもしれませんが、それは間違いかもしれません。トラフィック量やアクティブユーザーの総数でウェブサイトの容量を把握することが、いかに複雑なビジネスであるか、お分かりいただけたでしょうか。

サーバーリソースの安全性を第一に考え、すべてのユーザーにとって快適なウェブページを作成するために必要なリクエスト数を算出します。

同時リクエストから同時ユーザーへの変換

最大同時リクエスト数から最大同時ユーザー数を計算するには、以下の情報も必要です。

トランザクションフローに含まれるページ数
フロー内の最初のページから最後のページまでの訪問者の平均トランザクション時間
各ページを構成するリクエスト数の平均値
サーバーが1つのHTTPリクエストを処理するのにかかる平均時間

1)と2)はすでにご存じでしょうが、この例では6ページと5分です。トランザクションを行う際に表示されるページを簡単に数えることができます。平均的なトランザクション時間がわからない場合は、Google Analyticsでわかるかもしれませんし、ウェブサーバーのログを確認することもできます。

3)と4)については、Firefoxブラウザが役に立ちます。あなたのサイトのページを右クリックし、「要素の検査」、「ネットワーク」タブを選択します。次に、CTRL-SHIFT-Rキーを押して、ページを完全に更新します。すると、ページの各要素のネットワーク負荷時間が一覧で表示されます。転送」列で転送サイズが確認できることを確認してください。そうしないと、ファイルがキャッシュから提供され、計算が台無しになる可能性があるからです。スクリプトやその他のリソースが、あなたのサイト以外のサーバーから提供されているのを確認できるかもしれませんので、左側のフィルターボックスにあなたのサイトのドメイン名を入力してください。期間」列を表示するには、任意の列のヘッダーを右クリックし、ポップアップメニューから「タイミング」→「期間」を選択します。このような画面が表示されます。

googleは、画像アップロードのためにgoogle analyticsで適切に設定されたnginxを処理します。

このページの Firefox ネットワークタブ。queue-fair.com からのリクエストの期間と回数を表示。

ページの表示に使用されるファイルは、さまざまなサイトから提供されています。左上のフィルターを使って、自分のサイトのファイルだけを表示することもできます。

Firefoxはディスプレイの左下にあるリクエストを数えてくれ、この1ページだけで36のHTTPリクエストを表示しています。

トランザクションフロー内のすべてのページについてこの作業を行う必要があります。合計を数え、ページ数で割って、各ページの平均 HTTP リクエスト数を求めます。各HTMLページの子リクエストの数が、Webサーバーが処理できるトラフィックの量にとって重要な要素であることがおわかりいただけたと思います。

4) については、Duration の列を見て、すべてのページのすべての HTTP リクエストの平均を求める必要があります。よくわからない場合は、0.5秒と仮定してください。いずれにせよ、これには多くの不確実性があります（以下を参照）。

シングルサーバーや静的コンテンツなどのウェブアプリケーションで、同時に何セッション、何ユーザー、毎秒何回のリクエストがあるかを計算すること。

計算をする

いくつかの数字の例を挙げてみよう。サーバーの処理フローの例で動的ページが6ページあることを既に述べましたので1)、平均トランザクション時間が5分であることを2)とします。 1ページあたり36回のHTTPリクエストを想定して3)、HTTPリクエスト1回あたりのサーバー処理時間を0.5秒として4)とします。

この数字から、500同時リクエストを処理できるサーバーは、500 / (0.5 秒) = 1000 HTTP リクエスト/秒を処理でき、完全に最大にした場合、60,000 HTTP リクエスト/分となります。

5分間のトランザクションで、5×60,000＝300,000のHTTPリクエストを処理することができます。多いように見えるでしょ？

しかし、1人の訪問者に対して、6つのページがあり、それぞれ平均36のHTTPリクエストがあるので、6 * 36 = 216リクエストとなる

つまり、30万HTTPリクエストの容量は、理論上、30万÷216＝1,389の同時ユーザーを処理することができるのです。

於乎 #2: 負荷がかかると遅くなるウェブサーバー

おいおい、それはすごいなー。行列率100しかないと思っていたのに、1,389÷5分＝278人/分だから、もっと行列率が高くてもいいんだ！？

まあ、たぶん無理でしょうね。 ひとつには、上記の計算が想定しているように、訪問者が正確に0.5秒間隔でリクエストを送ることはないでしょう。さらに重要なことは、サイトが混雑していないときに入力データを測定していることです。ゴミが入り、ゴミが出る。

サイトが混雑しているとき、サーバーはリクエストの処理に時間がかかります。混雑しているときに他のサイトで、ページが表示されるまでの待ち時間が長くなることにお気づきでしょう。これは、サーバーが1つのHTTPリクエストを処理するのにかかる平均時間（4）を増加させ、最大スループットを減少させます。そこで、1分あたりの訪問者数を278として、それを半分にします。その後、再びそれを半分にします。あなたはおそらく現実的に最大負荷で毎分約70の新しい訪問者を見ている。

これは、サーバーが必要とするリソースが少なく、サーバーが処理できる1分あたりの新規訪問者数を増加させることができることを意味します。また、複数のサーバーに負荷を分散させるロードバランサーや、動的なページではなく静的なコンテンツを提供することも、各サーバーの必要リソースが少なくなるため、サーバー処理を高速化することができます。

また、制作や配信に必要なリソースが少ないページもあるため、すべてのページが同じ時間を要するわけではないことがわかります。データベースの検索、検索クエリー、更新には最も時間がかかるため、プロセスのどこかでボトルネックが発生し、クレジットカード情報の処理と注文の保存を待ったり、空き状況の確認を待ったりする人が山積みになります。また、Webサーバーが処理できる同時アクセスユーザーの数という質問には、必ず最大値の答えがあり、それにはいくつかの制限がある場合があります。その場合、Queue Rateを低く設定して、プロセスの最も遅いステップで同時に十分な人数を処理できるCPU時間を確保し、そこに人がたまらないようにしたいものです。そうしないと、ウェブサーバーが文字通り停止してしまう可能性があります。

じゃあ、どうすればいいんだ？

私たちの経験では、初めての販売では、誰もが自分のサーバーが大量のトラフィックに対応する能力を過大評価しています。

みんな

低速時やピーク時の平均セッション時間やエンドユーザーパフォーマンスを正確に把握するのは、気の弱い人には無理な話です。最適なのは、適切な負荷テストを実行することです。「偽」の顧客が実際に注文手続きを行いながら負荷テストを行い、同じ順番で同じHTTPリクエストを行い、負荷テスト時にページ間で現実と同じ待ち時間が発生するようにし、仮想訪問者の数を増やしながらプロセッサ負荷、IOスループット、応答時間に目を配ることです。 Apache JMeterを使用することもできますが（負荷が軽い場合や低速のマシンではK6を使用することもできます）、どのようなツールを使用するにしても、すべてのユーザーの動作を正確に模倣するには時間がかかり、厄介です（特にキャッシュの複雑さがあります）。その場合でも、最大数を半分にしてください。

それがない場合は、慎重に判断してください。

Queue-Fairのキューレートは、Queue-Fairポータルを使っていつでも簡単に変更できます。 1分あたり10人の訪問者、または通常の日のトランザクションレートから開始し、チケット販売開始後しばらく様子を見て、プロセッサの負荷が低く、SQLデータベースが正常で、CTRL-SHIFT-Rを押したときにページが反応するようであれば、20％以下だけ上げて、少し待ってから繰り返します。顧客体験の観点からは、キュー・レートを上げることは問題ありません。なぜなら、キュー内の顧客が見ている推定待ち時間が短縮されるからです。

キューレートを高く設定しすぎて、それを下げなければならない状況になるのは避けたいことです。キューにいるすべての人がため息をつくことになります。

於乎 #3: キューオープン後のレートアップが早すぎる

注文プロセスのどこかにボトルネックがあり、すべてのトランザクションには最も遅いステップがあり、そこに複数のセッションが積み重なることになることを忘れないでください。チケット販売開始1分後に、サーバーの処理負荷が最大値を大幅に下回っていることを確認し、処理速度を上げるようなことは避けたいものです。訪問者はおそらく「今すぐ購入する」ボタンまで到達していないでしょう。 SQLデータベースがキューレートと同じか類似のレートで新規注文を報告するまで待ち、その時に測定と応答性のテストを行うことをお勧めします。レートを上げるたびに、余分な訪問者がボトルネックに到達するのに同じ時間がかかるので、その時間が経過するまで、新しいレートでのサーバーのパフォーマンスを正確に評価することができないことに留意してください。

於乎 #4: サーバーのスナップ

キューがオープンしたら、キューレートを徐々に増加させるのが最善であることは、すでに説明したとおりです。しかし、負荷がこの限界に近づいても、通常はほとんど兆候がないこと、つまり、いくつかのエラーや警告、あるいは 80% を超えるプロセッサ負荷が発生するだけであることを、あなたは知らないかも知れません。

ウェブサービスに障害が発生すると、「スナップ」または「セイジング」が非常に速く発生する傾向があります。これは通常、システムが送られてくるリクエストと同じくらい速く処理できなくなると、内部処理のキューが蓄積されるからです。するとシステムは、リクエストだけでなく、内部のキューの処理、管理、保存も行わなければならなくなり、それがサーバーの限界を超える原因となっています。これがサーバーの限界です。このような事態が発生すると、サーバーは一時的にエラーページで対応できるかもしれませんが、それを見た訪問者がすぐに更新を押してしまうため、負荷がさらに大きくなってしまいます。

それ以前でも、訪問者があなたのページを表示するのに約1秒以上かかっている場合、訪問者は更新を押します。訪問者が更新を押しても、ウェブサーバーは、訪問者が元のリクエストに対する応答をもう待っていないことを知りません。元のリクエストと更新リクエストの両方を受信した場合、ウェブサーバーはその両方を処理します。つまり、ウェブサーバーの作業が増え、すべての訪問者のレスポンスがさらに遅くなり、さらに多くの訪問者が更新を押すことになり、その結果、エラー・レスポンスを送信し始める前にウェブサーバーが停止してしまうという悪循環に陥ります。

だから、必要以上にサーバーを追い込まないことです。通常、CPU時間の最後の20%の能力を求めることは、リスクに見合うものではありません。 Queue-Fair ポータルに表示されるキューのサイズ（チャート内の黄色い待機中の図と線）が、分単位で減少しているか、あるいはさらにゆっくりと増加していて、表示される待ち時間が 50 分以下であれば、十分に速く注文を処理しているので、あなたが何もしなくても、キューはいずれ空になりキューページを自動的に表示しなくなるでしょうし、あなたが無理をして壊したと上司に伝える必要もないでしょう。Queue-Fairポータルに表示される参加者数よりも、キューの先頭の速度が速ければ、いずれはそこに到達することができます - 転機は通常、各イベントの少なくとも数分後です。数量限定の商品を販売している場合は、折り返し地点に到達する前に売り切れる可能性があります。

Queue-Fairは、キューレートを高く設定しすぎてサーバーが停止した場合でも、サーバーが再び訪問者を処理できるようになるまでキューをホールド状態にするだけで、迅速に復旧させることができるのが良いところです。ホールドモードでは、オンラインイベントの前にデザインすることができる特別なホールドページがキュー内の人々に表示されます。しかし、新しいインターネット訪問者は後方のキューに入り、障害が解消されると公平にキューに入ることができます。 Holdページは、キューレートを低く設定するよりも優れたユーザー体験です。特に、キューを再開する時間を訪問者に伝えるために更新すれば、何十万人もの人々がすでにキューに入っている場合でも、ポータルページエディタで簡単に行えます。Holdモードでは、システムがスナップから回復する間、必要ならQueue-Fair独自のAdmit Oneボタンで一度に一人を通すことさえできます。

イベント開催中にサーバーを休ませる必要がある場合、Holdページを利用することで、サーバーをより早く復旧させることができます。

結論

この記事では、レートベースのキューが常に最善の方法である理由を説明し、必要なレートを計算する2つの方法を示しましたが、トランザクションフロー全体について完全かつ正確な仮想訪問者の負荷テストを行い、それについて本当に超超超確実である場合を除いて、私たちのアドバイスは常に同じです。

キューレートは10に設定し、通常の日のトランザクションレートと同じにします。
プロセッサーの負荷やその他のパフォーマンス指標に注目してください。
新しい注文が、キューレートと同じか同程度の割合でSQLデータベースに記録されるまで待ちます。
ページ上でCTRL-SHIFT-Rを押して、応答性をチェックしてください。ページ全体を取得するのに1秒以上かかる場合は、応答速度が限界に達しており、キューレートを上げるのは危険です。
もし安全であれば、キューレートを20％以上上げないでください。
手順2に戻り、もう一度待つ。
待ち行列のサイズが減少しているか、毎分着実に増加し、新規到着者に表示される待ち時間が50分未満になれば、それ以上速くする必要はない。
座ってリラックスしてください Queue-Fairがあなたをサポートします。

数量限定の商品を販売する場合は、ステップ7にも気を配る必要はありません。

これは、システムがサポートできる実際の最大Queue Rateを知らない、最初のキューのためのものです。それ以降のキューについては、一度、システムが実際に処理できる Queue Rate を測定すれば、再び同じ数字を使用することができるかもしれません。実際には、お客様のシステムは常に開発・改良されており、最近の変更が最大Queue Rateにどのような影響を及ぼしているかわからない場合があります。

これがQueue-Fairを使ったオンセールのやり方です。

お問い合わせ先

住所