レビュー日 · Hosmio リソース
始める前に
自分が所有する、またはテストを許可されているエンドポイントのみを使用すること。低いリクエストレート、観測ウィンドウ、無害なテスト操作に合意すること。通常のリダイレクト、認証、外部依存関係についてアプリケーション運用者に説明してもらうこと。以下の例は未実行の Linux シェルの例示である。
01
4種類の接続をリストアップする。
| パス | 観測するタスク | 記録する条件 |
|---|---|---|
| ユーザー → ポータル | 代表的なページを開く | アクセスネットワーク、応答ステータス、コンテンツ |
| ポータル → 外部API | 許可された依存関係チェックを実行する | エンドポイント、タイムアウト、上流制限 |
| 運用者 → 管理 | 承認された管理パスに到達する | VPN/プロキシとアクセス経路 |
| アプリケーション → 復旧先 | 承認されたテストオブジェクトを転送する | オブジェクトサイズ、スループット、エラー |
最も遅い重要なタスクは、ユーザーからサーバーへのパスではなく、サードパーティAPIを伴う場合がある。バックアップ経路は、インタラクティブトラフィックとは異なるボトルネックを持つことがある。これらのパスを別々に定義し、1つでの良好な結果が別のものの失敗を隠さないようにすること。
02
リクエストを比較可能にする。
文書化された期待ステータスとボディを持つ、小規模で機密性のないエンドポイントを選択すること。キャッシュ、認証、リダイレクト、プロキシが関与しているかどうかを記録すること。一連のシリーズを通じてペイロードとメソッドを同じに保つこと。共有サービスに大量のテストを送信したり、より印象的なサンプルを得るために無制限のループを実行したりしないこと。
# Illustration only. Replace with an authorized test endpoint.
curl --silent --show-error --output /dev/null \
--connect-timeout 5 --max-time 15 \
--write-out 'status=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
https://portal.example/health接続と総時間の制限は、操作の異なる部分を制限する。このコマンドはリダイレクトを追跡したり、証明書検証を無効にしたりしない。リダイレクトや認証失敗は、成功したアプリケーションチェックとしてカウントするのではなく、調査する必要がある。 curl: コマンドラインリファレンス ↗
03
マイルストーンを追加するのではなく解釈する。
上記のcurlタイミングフィールドは、リクエスト開始からの経過マイルストーンである。DNS完了、接続完了、TLS完了は、合計する独立した期間ではない。最初のバイトまでの時間には、準備とサーバーの待機も含まれるため、純粋なネットワーク遅延測定ではない。総時間は操作全体をカバーする。 curl: コマンドラインリファレンス ↗
リダイレクトのない単純な新しい HTTPS 接続の場合、マイルストーン間の差異は、調査に値するフェーズを特定するのに役立つ。接続の再利用、プロキシ、リダイレクトはその解釈を複雑にする。別の運用者が2つの観測が比較可能かどうかを判断できるように、元の出力と条件を保存すること。
04
観測シートを保持する。
Observed at UTC: [timestamp]
Observer / access network: [test point]
Endpoint and expected result: [authorized URL; status/body]
Method / payload / repetitions: [agreed plan]
Proxy, VPN, redirects, cache: [conditions]
Successful requests: [count]
Failures and status codes: [count; categories]
Timing observations: [recorded output]
Application check: [passed / failed / not checked]
Limits of the observation: [known gaps]これは空白の記録テンプレートであり、Hosmio のベンチマークではない。質問を調査するのに十分な観測を選択し、異常または失敗したリクエストを保持すること。不便なエラーを削除したり、短時間の成功サンプルが長期間の可用性を確立すると主張したりしないこと。
05
差異を次のチェックの選択に使用する。
1つのアクセスネットワークのユーザーが失敗し、他のユーザーが成功する場合は、DNS応答、証明書、応答コード、プロキシ経由のルートを比較すること。ポータルに到達可能でもバックグラウンド作業が蓄積する場合は、上流APIとジョブ処理を別々に検査すること。作業が外部依存関係を待っている場合、CPUを追加しても役に立たないことがある。
一度に1つのテスト条件を変更し、その理由を書き留めること。異なるエンドポイント、ペイロード、認証状態は、インフラストラクチャの変更なしに異なるタイミングを説明する場合がある。より大きな転送には、明示的に承認されたテストサイズを使用し、転送予算を含めること。任意の大きなダウンロードは中立的なテストではない。
06
観測を境界のある決定に変換する。
結果を比較する前に、プロジェクトの受け入れ基準に合意すること。それらはクライアントが関心を持つタスクを反映し、機能とタイミングを区別するべきである。2人目の運用者に同じ種類の観測点からプロセスを繰り返してもらうこと。不一致は問題を平均化する理由ではなく、条件を検討する理由である。
観測記録を添付する 提案された地域変更 または ホスティング判断マトリックス。どのユーザーネットワークと依存関係が未テストのままであるかを述べること。Hosmio はこのカタログに公開された測定済みエンドポイント、レイテンシ保証、ライブ容量情報を持たない。有用な成果は、再現可能な方法と明確に限定された観測であり、測定されていないパフォーマンスに関する主張ではない。