再現可能なワークロードでHome Assistantのイベントからアクションまでの遅延をベンチマークする方法

固定したイベントからアクションまでのワークロードを再生し、制御されたキャッシュおよびバックグラウンド条件下で、パーセンタイル遅延、エラー、飽和状態、回復を測定して Home Assistant のベンチマークを行います。

ダッシュボードのクリックが素早く反応しても、Recorder の書き込み、バックアップ、またはデバイスのバースト中にオートメーションが応答し続けることの証明にはなりません。実用的なホームサーバーベンチマークは、定義済みの入力から開始し、観測可能なアクションで終了します。その間、エンティティ数、インテグレーションの挙動、ネットワーク経路、キャッシュ状態、温度、競合するサービスを固定します。この経路を繰り返すことで、ばらつきと、最初に余裕を失うリソースが明らかになります。

リソースを測定する前に、エンドツーエンドの結果を1つ選ぶ

まず、合成した状態変化からサービス呼び出しまでの時間や、ダッシュボードのコマンドから対象の状態が確認されるまでの時間など、家庭内で観測できる結果を選びます。この区間には CPU 処理だけでなく、インテグレーションの遅延、イベント処理、オートメーションのロジック、ネットワーク伝送、デバイスの応答、確認処理なども含まれます。

実際のワークロードを分離されたマイクロテストの代わりに使用し、平均値だけでなくテールの挙動も測定すると、ベンチマーク手法は改善します。実用的なベンチマーク設計の原則では、現実的なワークロード、パーセンタイル、同時実行数、コールド状態とウォーム状態の両方が重視されています。

選択した結果を合格基準の指標にします。ホストの CPU、メモリ、ストレージ、ネットワークの測定値は、その結果が変化する理由を説明するものであり、結果そのものの代わりにはなりません。サーバーの平均使用率が低くても、オートメーションの経路で時折発生する長い遅延が、照明、ロック、アラーム、暖房にとって重要になる場合があります。

固定したワークロードスクリプトを作成する

実行に含めるエンティティ、トリガー頻度、オートメーション経路、ダッシュボード操作、Recorder の保持期間、データベースの状態、バックグラウンドジョブを正確に書き出します。家庭の安全を損なったり実際のデバイスを消耗させたりせずにシーケンスを再生できるよう、合成入力または無害な入力を使用します。実行時間と試行間の回復時間も固定します。

高頻度オートメーションに関する議論からは、イベント頻度とテンプレート処理を明示する必要性が分かります。Home Assistant コミュニティで行われた高頻度イベント負荷の調査では、毎分1,000イベントを超えるワークロードが扱われており、トリガー頻度を明記しないと、2つのベンチマーク結果を比較できなくなることが示されています。

代表的なワークロードは、必ずしも実行可能な最大負荷である必要はありません。通常時に発生する最も忙しい重複状態と、それを制御して少し超える負荷を含めます。最初の実行で通常の挙動を確認し、追加の負荷で残りの余裕を明らかにします。説明のつかないバックグラウンドタスクによってベンチマークが逸話にならないよう、サービスを無作為に混在させることは避けます。

コールド、ウォーム、定常状態を分けてテストする

Home Assistant の再起動、初回のダッシュボード表示、キャッシュされていない履歴の検索では、後続の繰り返しでは回避されるストレージ処理や初期化処理が実行されることがあります。ウォーム状態の実行では、データベースページ、フロントエンドアセット、DNS 応答、OS キャッシュが再利用される場合があります。長時間の実行では、温度の安定、ログの増加、バックグラウンドスケジューリングも加わります。

キャッシュウォーミングは、要求が到着する前に頻繁に使用されるデータをより高速な層に配置することで、遅延を変化させます。このキャッシュウォーミングの影響に関する分析では、ウォーム状態の結果が通常運用には有効でも、再起動や回復の性能を示す証拠としては誤解を招く可能性が説明されています。

これらの状態をまとめて平均せず、それぞれ報告します。コールド性能は再起動またはキャッシュ追い出し後の挙動を示し、ウォーム性能は日常的な繰り返し操作を示し、定常状態の性能は継続的な負荷への対応を示します。容量に関する主張は、指定した状態がユーザーの利用シナリオと一致している場合にのみ信頼できます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

パーセンタイルと段階ごとの境界を測定する

エンドツーエンドの遅延をすべて記録し、エラー数とともに中央値および高パーセンタイル値を報告します。中央値は一般的な体験を示し、95パーセンタイルまたは99パーセンタイルは平均値に隠れた断続的なキューを明らかにします。経路が許す場合は、トリガー、オートメーション開始、アクション呼び出し、対象状態の確認時点でタイムスタンプを取得します。

迅速なシステム切り分けでは、遅延がリソース間を移動する可能性があるため、プロセス、CPU、メモリ、ネットワーク、ブロックデバイス、エラーを確認します。Linux パフォーマンス分析のワークフローは、1つの使用率だけで診断せず、リソースのシグナルを相関させる簡潔な例を示しています。

段階ごとのタイムスタンプによって、遅いインテグレーション、ビジー状態のイベントループ、遅いデータベース処理、ネットワーク遅延、応答の遅い対象デバイスを区別できます。Home Assistant がすぐにアクションを発行しているのに確認が遅れて届く場合、ホストに CPU を追加しても測定されたボトルネックは解消しません。最初に拡大している段階が、調査すべき関係の切れ目です。

使用率、飽和状態、エラーを組み合わせて使う

使用率はリソースがどれだけ忙しいかを示し、飽和状態はすぐに処理できず作業がキューに入っていることを示し、エラーは処理の失敗を明らかにします。ベンチマーク中は、CPU、メモリ、ストレージ、ネットワークについて、この3つすべてを確認します。高い使用率は健全な場合もありますが、短い飽和状態のバーストは、長時間の平均値が余裕を示していても遅延を生むことがあります。

USE パフォーマンス手法では、粗い平均値が短時間の完全使用率やキューイングを隠す可能性があると明確に警告しています。これは Home Assistant に直接関係します。短時間のイベントバーストは、ホストの5分間 CPU 平均値よりも重要になる場合があるためです。

システムのシグナルを、同じベンチマークのタイムスタンプと組み合わせます。遅いテールが発生するたびにストレージキューが増加するなら、メモリ回収イベントやネットワーク再送とは異なる次の実験が必要になります。最も忙しいリソースをボトルネックと呼ぶのは、その飽和状態またはエラーがユーザーに見える遅延と一致している場合に限ります。

ベンチマークの比較可能性が失われる場合

ソフトウェアのバージョン、エンティティの構成、データベースのサイズ、保持期間、クライアント、ネットワーク経路、周囲温度、バックグラウンドサービスが変化したのに記録されていなければ、結果は比較できなくなります。ある実行ではキャッシュをウォームアップし、別の実行では行わない場合や、短い区間の測定でイベントのタイムスタンプの代わりに手動計測を使用した場合も同様です。

コンテナのベンチマークでは、ランタイム、リソース制限、ストレージ経路、ネットワークモード、ホストの状態を明記する必要があります。このDocker パフォーマンスベンチマークガイドは、CPU、メモリ、ストレージ、ネットワークのテストを分けており、コンテナというラベルだけでは環境の説明として不十分であることを示しています。

最も遅い実際の依存先を省略した合成結果も、家庭での体験を予測できなくなります。ループバックのオートメーションは Core の性能を正確に測れるかもしれませんが、クラウドインテグレーションやバッテリーデバイスについては何も示しません。制御された内部経路と代表的なエンドツーエンド経路の両方を維持し、それらの結果を1つの数値に統合しないでください。

5回の試行による合格プロトコルを実行する

まず環境マニフェストを取得し、固定したワークロードでコールド状態の試行を5回、ウォーム状態の試行を5回行います。その後、許可された中で最も忙しいバックグラウンドジョブを含む継続的な実行を行います。各物理リソースについて、中央値、95パーセンタイル、最大値、エラー、再起動イベント、使用率・飽和状態・エラーのシグナルを報告します。

コンテナ単位のメトリクスは、保持され、アプリケーションの結果と時間的に対応付けられている場合に有用です。このコンテナ監視ガイドでは、遅延分布と併せて使用できる CPU、メモリ、ネットワーク、ブロック I/O の項目が説明されています。

対象のパーセンタイルを改善し、エラーを増加させず、別の必要な経路へ飽和状態を移さない変更のみを採用します。繰り返しの試行で同じ上限が確認された場合は、ZimaSpace の制限要因の特定に関する診断を次の手順として利用します。