上記の図の著者が非常に正確に表明したように 、多くの初心者（そして初心者ではない）は、知識と理解のための高い入力しきい値の問題に直面しています。
不可解な表現？
ここで、私にとって、世界を好転させるアイデアを持つ未経験の若者として、それは明確ではありません：GET、POST、INSERT、そして最も重要なCPUのこれらすべての量をどこで入手するか。
この問題には多くの解決策があります。
たとえば、「1日あたり1万個のホストがあるWordPressのWebサイトがこのような読み込みプロファイルを生成する」などの標準的なケースを公開する場合です。 便利ですか？ はい ホスティング事業者にとってシンプルで安価ですか？ はい 広く適用され、評価の精度は十分ですか？ 前の投稿のディスカッション参加者の一人が述べたように、「WordPressの1つのモジュールはCPU負荷を10倍に増やすことができます。」
デモへのアクセスを許可できます（または、一方で、クラウドホスティングサービスから
そして、ここで私は長い間クラースの灰を私の心にノックしていた考えを思いつきました
そして、ホスティング事業者で仮想サーバーを作成する場合、外部からではなく内部からサイト全体に入力し、ストレステスターを設定しますか？ ストレステスターにURLとルールの抽象的なリストではなく、ライブWebサーバーログをフィードするとしますか？
サイトの場合、そのようなテストは実際の負荷と変わりません。「大食い」アドレスを禁止するDoS保護をオフにすることもできます。結局、ストレスサーバーはサイト全体のインターネットのふりをすることができます。
このストレステストは、ホスト（および将来のWebサイトをテストするクライアント）の外部チャネルをロードせず、真空中の球形馬ではなく、「超高速チャネル」の真空中の真の群れをシミュレートします。持久力」、および実際のサイトで実際の顧客が消費するリソースの量。
このテストは、「加速」として実行され、ASAPログ全体を1対1の速度で、実際には任意の選択されたログでロードします。 はい、毎日のログのテストには1日かかりますが、干渉しますか？ ただし、ホスティング事業者は、サイトの最小ロード時にログからのリクエストの最大数が処理されるようにテストを計画できます。 さらに、遅延がサイト自体のロジックに影響を与えるまで、そのようなテストはマイナス無限大に優先順位を付けることができます。つまり、「仮想」ユーザーは2秒ではなく0.2秒ではなく22秒でページを取得します。ベース、IOPSへのトラフィックは正しくカウントされます。
入力ログは、スラッシュドットの瞬間をシミュレートすることで修正できます（これを行うのは非常に簡単です-変更されたIPアドレスを持つ実際のセッションのコピーを取り込んで混合します）。
すべての手順は完全に透明であり、完全な初心者でも理解できます。
この方法の欠点は質量です
これにより、実際のホスティングに匹敵するホスティング事業者の負荷が発生します。 出力チャネルが少なく、毎日の負荷分散が行われ、優先度が高くなります-CPU、IOPSなどを実際のお金で消費します。
これは開発に非常に時間がかかります。インターネットから隔離され、隔離され、優先順位が付けられた仮想サーバー構造を作成する必要があります。 ロケット手術ではないかもしれませんが、開発にはお金がかかります。
これにより、個人データに関する多くの疑問が生じます。実際のログをホスティング業者にアップロードし、難読化ツール（まだ開発が必要）を通過させても、デリケートな問題です。
これはクライアントに多くの条件を課します：スタートアップだけでなく、既存のウェブサイトとライブログを持つ移民です。 どの種類のログがすべての共有ホストからまだ利用可能ではありません。 「生きていない」ログをゼロから作成することは難しく、誰もがサイトのどの部分が最も頻繁にアクセスされるかを予測できるわけではありません。 悪名高い「WordPressの1つのプラグイン」は、1000人中1人のユーザーがいるページに座っている可能性があります。また、999人中999人が座っているページに座っている可能性があります。
もちろん、すべてのサイトを単純なコピーでクラウドに転送できるわけではありません。つまり、ホスティングのコストを見積もるためにも、ウェブマスタークライアントは、適応させるためにエンコーダーの作業に時間やお金を費やす必要があります。
緩和オプションがあります
ホスティング事業者は、クライアントがラップトップやNASなどで起動する仮想マシン（より正確には、2台のマシンの束、ホスティング事業者とストレッサー）のイメージをアップロードします。これはすでにWebマスタークライアントの質問です。
上記と比較した長所：ユーザーデータの漏洩はなく、ホスティングリソースの消費はありません。
マイナス面も明らかです。まず、ウェブマスターのホームマシンがサイトのこのような負荷を（少なくとも「非常に低いペース」で）処理できる場合、クラウドホスティングはほとんど必要ありません。 第二に、提供された仮想マシンイメージでの課金システムとホスティング自体のリーク。 ただし、リソースの計算にのみ適した簡易バージョンを提供できます。 第三に、以前は未知だったハードウェアに対する仮想化の影響を非常に細かく考慮する必要があります。
追加のボーナスは、特定のホストプラットフォーム向けに開発できることです。
そして最後：両方のオプションは、私にとっては、クラウド以外のホスティング事業者にとって有用だと思われます。