私のウェブサイトはどれくらいのトラフィックを処理できますか?

Web サイトのパフォーマンスとキャパシティを明確に理解するのは簡単なことではありません。 この詳細なガイドでは、サイトのトラフィックに関する質問に自信を持って答えるために、見るべき指標を一度に調べます.

WP Engineでは、ウェブサイトのパフォーマンスを知っています 単なる一次元のキャッチフレーズではありません。 実際、私たちのプラットフォームで実行されるサイトに関して言えば、私たちはパフォーマンスを、私たちのクラウドとセキュリティ ソリューションの側面と管理された WordPress の専門知識を組み合わせた戦略的な方程式と見なしています。

そうすることで、アクティブなサポートが必要な変数とメトリックの長いリストを使用して、複数の角度からアプローチすべきパフォーマンスにアプローチすることができます。

また、これらの取り組みはそれ自体が製品であり、終わりのないものであると考えています。プラットフォーム全体でサイトのパフォーマンスのすべてのコンポーネントを改善する方法に常に取り組んでいます. この「決して満足しない」アプローチを採用することで、WP Engine はお客様が WordPress で最速のサイトを構築するのを支援することができ、トラフィックの急増からセキュリティに至るまで、あらゆる問題に直面してもそれらのサイトを稼働させ続けることができます。脅威。

ここでは、Time to First Byte (TTFB) などの速度とメトリックについて説明しますが、次の記事では、トラフィック メトリックと、重要ではあるものの一般的な質問「サイトで処理できるトラフィックの量はどれくらいですか?」について詳しく説明します。

質問の組み立て。

Web サイトのキャパシティ、つまり、ある時点でサイトが処理できるトラフィックの量は、サイト全体のパフォーマンスの重要な要素であり、KPI だけでなく、開発者がインフラストラクチャなどに費やす時間にも直接影響します (独自のインフラストラクチャを社内で再管理します)。 とはいえ、サイトが実際に処理できるトラフィックの量を測定するには、サイトが受け取るユーザーとトラフィックの種類を理解することから始めます.

まず、インターネットのコンテキスト内での同時ユーザーの定義を調べてみましょう。

WP Engine では、このリソースは WordPress サイトです。

同時ユーザー数は高レベルの指標であることに注意してください。 次のいくつかのセクションでは、同時ユーザーが同時要求のより詳細なメトリックにつながることを学習します。 これらのリクエストにはさまざまな形とサイズがあるため、キャッシュ可能性を使用して、サイトが大規模にどのように機能するかを理解できます。 さらに深く掘り下げると、同時実行性とキャッシュ可能性がどのように相互に作用するかを探ります。

では、同時ユーザーをどのように使用して、環境の容量を把握するのでしょうか? これに答える前に、さらに一歩戻って、現在使用されている最も一般的な指標の 1 つである月間トラフィックを見てみましょう。

毎月のトラフィック メトリック: 役に立ちましたか?

一般的に言えば、はい。 月ごとの数値は、基本的なトラフィック プロファイル (低、中、高) を理解するのに役立ちます。 毎月のトラフィックは、マーケティング キャンペーン、検索エンジンのランキング、市場の状況などの多くの変数に基づいて変化する可能性があるため、これらのメトリックは、潜在的な傾向、パターン、および季節性に関する洞察も提供します。

ほとんどのサイトでは、通常の日常のトラフィックはかなり安定しており、予測可能です。 これをベースライン トラフィックと呼ぶことができます。 ただし、トラフィックの急増が繰り返される一部のサイトでは、ベースラインについて心配する必要はありません。 彼らは、コンサート チケットを販売するサイトや製品リリースの発表に使用されるサイトなど、ビジネスにとって重要なトラフィックの多いイベントに関心を持っています。 これらのイベントが最も重要な場合、実稼働環境がベースライン トラフィックだけでなくピーク トラフィック レベルも処理することが重要です。

これは、毎月のトラフィック数が役に立たないところです。 この (実際にはすべての) トラフィック レベルで容量を理解するためのより信頼できる指標は、同時ユーザー数です。

ユーザー指標をさらに深く掘り下げます。

同時ユーザーに飛び込む前に、デジタル分析の領域におけるメトリックの階層を理解しておくと役に立ちます。 これを説明する図を次に示します。

• ユーザーまたは訪問者は、初めてサイトにアクセスしたユーザーを表す指標です。 通常、一意のユーザー ID によって定義されます。 WP Engine では、一意の IP アドレスとして定義され、1 日あたり 1 人の一意の訪問者としてカウントされます。 同じユーザーによる追加の訪問は一意のユーザー ID によって認識されるため、一意のユーザーは 1 回だけカウントされます。
• セッションまたは訪問は、ユーザーがサイトを利用した期間を表します。 セッションは、ユーザーが最初にサイトにアクセスしたときに開始され、ユーザーがブラウザーを閉じる、Cookie を消去する、または 30 分間非アクティブになる (Google アナリティクスのデフォルトの期間で、カスタマイズ可能) のいずれかが発生すると終了します。 1 人のユーザーが 1 日に複数のセッションを持つことができます。
• ヒットは、サイトと定義済みのリソースとの間の相互作用です。 デジタル アナリティクス側では、この指標は Google アナリティクスに送信されるデータとして定義されます。 これらのヒットは、最も一般的なページ ビューです。 WP Engine コンテキスト内では、ヒットは本番環境へのリクエストになる可能性があります。 これらのリクエストは、静的アセット (png、jpeg、pdf) のようにキャッシュ可能にすることも、データベース書き込み (登録、公開投稿、製品注文) のように動的にすることもできます。

これらのメトリックの階層に基づいて、上から下に移動するにつれて、データがあいまいさがなくなり、より詳細になります。 同時に、これらのメトリックがパフォーマンスに与える影響を理解することがより明確になります。

つまり、月間ユーザー数や訪問者数を知るだけでは十分ではありません。

Google アナリティクスのアクティブ ユーザーはどうですか?

Google Analytics と WP Engine がメトリックをキャプチャして定義する方法に関して、しばしば誤解があります。 簡単に言えば、どちらも異なる目的でこのデータを追跡しています。 Google アナリティクスは、主にマーケティングおよびコンバージョン分析ツールです。 対照的に、WP エンジンは、インフラストラクチャ レイヤーで生のリソース使用率を追跡し、アプリケーション レイヤーでパフォーマンスを追跡するマネージド プラットフォームです。 方法論は異なり、両方のプラットフォーム間で不一致が生じる可能性があります。

同時実行に関連するため、Google アナリティクスは、サイトでのマーケティング キャンペーンの効果を監視するリアルタイム レポートを提供します。 これには、現在サイトでアクティブなユーザーの数が含まれます。

「リアルタイム」であるにもかかわらず、この指標はサイト上のユーザーの総数を任意の時点で同時に正確に測定するものではありません。 リアルタイムのアクティブ ユーザーは、過去 5 分以内にイベントまたはページ ビューをトリガーした一意のユーザーとして定義されます。 ユーザーが 5 分以内にサイトを離れた場合、Google はこれを引き続きアクティブ ユーザーとしてカウントします。 ユーザーがサイトに 5 分以上滞在すると、サイトと対話していても、アクティブ ユーザーとしてカウントされなくなります。

これを念頭に置いて、Google のアクティブ ユーザーは、サイトの実際の同時ユーザー数より多い可能性があります。 また、まれに、ユーザーの行動や平均セッション時間によっては、メトリックが実際の同時実行数よりも少なくなる場合があります。

Google アナリティクスのアクティブ ユーザーは信頼できますか? いつものように、データは多ければ多いほど良いです。 しかし、それだけでは容量のニーズを決定することはできません。

同時ユーザーの測定方法。

Google アナリティクスが同時ユーザーの明確な指標を提供しない場合、どうすればよいでしょうか? この数を決定するのに役立つ 2 つの一般的な方法を次に示します。

1. 同時ユーザー数を計算します。

Google アナリティクスから取得したデータでこの式を使用すると、1 秒などの非常に短い時間単位でサイトのアクティブ ユーザー数を計算できます。

[1 時間あたりのピーク セッション数 X 平均セッション時間 (秒)] / 3600

1 時間あたりのピーク セッションについては、Google アナリティクスの [オーディエンスの概要] レポートに移動します —> トラフィックがピークに達している期間を見つけます —> タブを [1 時間単位] に変更します —> グラフにカーソルを合わせると、1 時間以内の最大セッション数が表示されます。

平均セッション時間のメトリックは、概要ダッシュボード内に表示されます。 そうでない場合は、[概要] タブの [指標を選択] に移動して期間を表示します。

2. Google アナリティクスの代替手段を選択します。

Google Analytics はこの分野で最も人気のある Web 分析ツールですが、特定のニーズをすべて満たすとは限りません。 同時ユーザーの従来の定義に沿って同時実行を測定できる分析ツールは多数あります。

キャッシュ可能性についてはどうですか？

では、同時ユーザーはパフォーマンスの有効な測定値でしょうか? 完全ではありません。 このメトリックは、シナリオの規模を大まかに理解するのに役立ちますが、より深い洞察は提供しません。

そうは言っても、WordPress サイトにログインしているユーザー (メンバー、管理者、編集者) とログインしていないユーザーの違いを理解しておくと役に立ちます。これらのユーザーの行動によって、さまざまな種類の「ヒット」またはリクエストが生成されます。サイトのパフォーマンスを最もよく示しています (上記の前のセクションで言及)。

これを拡張するために、これらのさまざまなタイプのリクエストは、静的または動的のいずれかの形式で提供されます。

• たとえば、CSS、JS、画像などの静的コンテンツ(めったに変更されないファイル) は、簡単にキャッシュできます。
• ログイン ページ、ショッピング カート、メンバーシップ専用エリアなどの動的コンテンツは、アクセスする各ユーザーに固有のものを画面に表示する必要があるため、キャッシュできません。

これは、キャッシュまたは一時ストレージ領域にデータを格納するプロセスを指すキャッシャビリティの概念をもたらします。 コンテンツがキャッシュされている場合、ブラウザーは元のサーバーではなくキャッシュからコンテンツを取得できるため、エンドユーザーの時間を節約し、ネットワークの追加のトラフィック負担を軽減できます。

 上記の静的対動的分類を参照すると、静的コンテンツが多いサイトほどキャッシュ可能性スコアが高くなります。 逆に、より動的なコンテンツを含むサイトは、キャッシュ可能性スコアが低くなります。

WP Engine ユーザーが WordPress サイトにログインすると、ほぼ完全にキャッシュできない動的コンテンツと対話します。 したがって、Varnish や CDN などのフロントエンド キャッシング レイヤーをバイパスします。 その結果、これらのキャッシュ不可能なリクエストは通常​​、PHP と MySQL を介してバックエンドで新たに処理する必要があるため、より多くのリソースを消費します。 一方、ログインを必要としないサイトでは、ページの要素によってキャッシュ可能性が異なる場合があります。

この図は、静的コンテンツと動的コンテンツを提供するために必要なさまざまなテクノロジーを示しています。

たとえば、「The Puppy Nursery」という子犬の養子縁組 Web サイトがあるとします。 新しい訪問者がサイトにアクセスすると、ホームページの高品質の写真が突然表示されます。 メニューにカーソルを合わせた後、各動物の詳細については、子犬の経歴ページをクリックすることにしました。 これらのページはほとんど静的で、かわいい子犬の説明と写真が掲載されています。 これらのページにはほとんどが静的なコンテンツ (キャッシュ可能) があるため、この特定のユーザー セッションはリソースをあまり消費しません。

さて、1 日経った後、あなたは子犬を引き取るつもりで、再びこのサイトにアクセスすることにしました。 登録ページをクリックすると、地理的に最も近い子犬のリストが動的にポップアップ表示されます。 子犬を選んだ後、個人の連絡先の詳細をフォームに記入し、安全放棄に同意し、養子縁組料金のためにクレジット カード情報を提供します。 送信を押すと、「ありがとうございました」ページにリダイレクトされます。 この特定のユーザー セッションは、パーソナライズされたポップアップ、フォームの送信、クレジット カード トランザクションなどのインタラクティブな要素により、より動的です。 その結果、より多くのリソースを消費します。

この例が示すように、ユーザー セッションの変動により、サーバーへの要求の種類と数が異なります。 これらの要求は、同時ユーザーの数だけよりも、容量とパフォーマンスの優れた指標です。

全体として、同時にログインしているユーザー、ログアウトしているユーザーの数、およびキャッシュ可能性は、サイトのリソース需要を理解するのに役立ちます。

さまざまな種類のサイト。

明らかに、すべての Web サイトは独自のものであり、さまざまな課題に直面しています。 ただし、Web サイトの基本的な特性によって、そのキャッシュ可能性が通知されることは依然として事実です。

この概念を拡張して、一般的により静的または動的であるさまざまなタイプのサイトを次に示します。

静的：

• パンフレット サイト
• B2B マーケティング サイト
• 非営利団体
• ブログ (投稿アクティビティが少ない)
• ユーザーの操作が非常に少ないサイト

動的：

• eコマースストア
• 会員サイト
• WordPress マルチサイト
• 学習管理システム
• ユーザーとのやり取りが多いサイト (コメント、登録、注文トランザクション、ログイン アクティビティ、検索クエリ)

注:これらはそのように分類されていますが、WordPress サイトには静的要素と動的要素の両方が含まれている場合があります。 そのため、キャッシュ可能性スコアを見るときは、両方の比率を理解することが重要です。

これをトラフィックに変換してみましょう。 パンフレットと e コマースの 2 種類のサイトがあるシナリオを想像してみてください。 本来、パンフレット サイトは e コマース ストアよりも静的です。 それぞれのサイトのキャッシュ可能性スコアは 90% と 20% です。 サイトが WP Engine でホストされている場合は、サポート チームに連絡してキャッシュ可能性スコアを確認してください。

このシナリオでは、サイトごとに WP Engine のプラットフォームで Google Cloud 専用ソリューションを使用することにしたとします。 ソリューションがまったく同じであると仮定すると、パンフレット サイトがダウンする前に処理できるトラフィックの量は? ECサイトはどうですか？

ご存知のように、答えは状況によって異なります。 一般的に言えば、専用ソリューションのパンフレット サイトは、e コマース サイトよりも 1 か月あたりかなり多くの訪問者をサポートできます。 それは単により静的でキャッシュ可能です。 これは、比較的安全な仮定です。

サイトが処理できる訪問者の正確な数を知る限り、この質問をより小さな部分に分割して全体的にアプローチすることをお勧めします.

正しい質問をする。

サイトがどれだけのトラフィックを処理できるかを判断する代わりに、おそらくより役立つ質問は…

現実的な高トラフィック シナリオで、サイトが一定時間内に処理できる同時ユーザー数は? たとえば、あなたのサイトがテレビ番組で取り上げられ、1,000 人の同時非ログイン ユーザーが 20 分間見込まれるとします。]

これらのユーザーのうち、ログインしているユーザーとログアウトしているユーザーの数は?

サイトはどの程度キャッシュ可能ですか?

この負荷のピーク時の応答時間、1 分あたりのリクエスト数、レイテンシ、およびエラー率の許容レベルはどれくらいですか?

そして、それがビジネスに反映されると、これらの KPI が満たされない場合はどうなるでしょうか?

それは収益にどのような影響を与える可能性がありますか?

負荷テストに入ります。

これらの質問に答えるために、負荷テストを実行して実際のシナリオをシミュレートすることを強くお勧めします。

 負荷テストは、システムに要求を課して、システムのパフォーマンスを判断するプロセスです。

Page Performance テスト (WP Engine の顧客が利用可能) または Speed Tool テスト (誰でも利用可能) は、1 回の訪問に基づいてサイトの速度を測定しますが、それは最初の章にすぎません. 負荷テストがすべてを物語っています。

最も一般的なのは、負荷テストを実行して、多数の同時ユーザーによるピーク トラフィックをシミュレートすることです。 言い換えれば、1 回の訪問だけでなく、高負荷の下でサイトがどのように機能するかを示します。

サイト固有の環境のキャパシティを真に理解するために、負荷テストを行うと、あらゆるレベルのトラフィックでより信頼できるようになります。

役立つリソースを次に示します。

負荷テストの詳細については、このホワイトペーパーを参照してください。

ページのキャッシュ可能性を改善するためのヒントについては、この記事を参照してください。

最終的な考え。

サイトが処理できるトラフィックの量を理解することは、確かに混乱を招く可能性があります。 ほとんどのマネージド ホスティング プロバイダーは、独自の基準と、ソリューションの月間最大訪問者数を定義しています。 サイトには独自の一連の特性があるため、これらの数値を信頼してパフォーマンスと容量を評価することは現実的ではありません。 また、毎月のトラフィック数は、サイトがトラフィックの多いイベントをどのように処理するかを理解するのに役立ちません。たとえ短期間しか続かない可能性があるイベントであってもです。

そのため、これらの推定数はガイドラインとしてのみ使用する必要があります。 適切な質問をし、適切なデータを評価し、必要に応じて適切なテストを実行することで、より多くの情報に基づいた意思決定を行うことができます。

最後に、トラフィックはパフォーマンス パズルの一部にすぎず、ソリューションとプラットフォームを選択する際の決定要因の 1 つにすぎません。 その他の要因には、キャッシング レイヤー、データベースのパフォーマンス、インフラストラクチャの品質と設計、高可用性、およびスケーラビリティが含まれます。

すべてのビジネスにはさまざまなニーズがあります。 企業のお客様には、満たす必要のある重要なビジネス要件と機能要件があります。

AWS Well-Architected フレームワークの柱によると、これらは最優先事項です。

• オペレーショナル エクセレンス:システムを実行および監視して、ビジネス価値を提供し、サポート プロセスと手順を継続的に改善する能力。
• セキュリティ:リスク評価と緩和戦略を通じてビジネス価値を提供しながら、情報、システム、および資産を保護する能力。
• 信頼性:システムがインフラストラクチャまたはサービスの中断から回復し、コンピューティング リソースを動的に取得して需要に対応し、構成ミスや一時的なネットワークの問題などの中断を軽減するシステムの能力。
• パフォーマンス効率:システム要件を満たすためにコンピューティング リソースを効率的に使用し、需要の変化やテクノロジの進化に合わせてその効率を維持する能力。
• コストの最適化:システムを実行して、最低価格でビジネス価値を提供する能力。

WP Engine は、これらの柱に沿った業界標準の慣行に従います。

サイトが処理できるトラフィックの量について詳しく知りたいですか? ここをクリックして、WP Engine のプランと、管理された WordPress ホスティング プラットフォームを利用したときに顧客が目にするメリットについて詳しく確認してください。