キャッシュを容量と取り違えずにHome Assistantのパフォーマンスを測定する方法

高速なウォーム状態でのHome Assistantテストを行っても、余裕容量があることの証明にはなりません。ブラウザー、データベース、ファイルシステム、またはアプリケーションのキャッシュがすでに利用可能な状態になっていることを示しているだけかもしれません。

容量とは、レイテンシーと正確性の目標範囲内で、システムが継続的な処理をどれだけ完了できるかを指します。一方、キャッシュは繰り返し処理のコストを変化させます。2回目の訪問でダッシュボードが素早く開くこと、キャッシュされたページによって履歴クエリが高速化されること、再起動後に1つのオートメーションが滑らかに動作することは、いずれも有用な観測結果です。しかし、それだけでワークロードの上限が分かるわけではありません。コールド、ウォーム、定常状態、飽和の各フェーズを分けて測定してください。

まず、キャッシュの影響と測定したいワークロードを分離する

Home Assistantの経路ごとに異なるキャッシュがあります。ブラウザーはフロントエンドアセットを保持し、オペレーティングシステムはファイルシステムのページをキャッシュします。SQLiteなどのデータベースは最近読み込まれたページの恩恵を受け、インテグレーションは接続やデバイスの状態を保持することがあります。DNSやTLSも再利用される場合があります。1回の「ウォーム」ベンチマークには、これらの効果がいくつも同時に含まれる可能性があります。

Home AssistantコミュニティのRecorderパフォーマンスガイドでは、大規模なデータベースによって読み取り、書き込み、インデックス処理が増加する仕組みを説明しており、データベースのワークロードは保持する状態の量に応じて変化することが分かります。CPU速度だけで決まるわけではありません。ウォーム状態のページキャッシュは、ワーキングセットがメモリ容量を超えるか、別のワークロードによって追い出されるまで、読み取りコストの一部を隠すことがあります。

テスト前に、容量について何を確認したいのかを定義してください。ダッシュボードの起動、履歴クエリ、オートメーションのレイテンシー、1秒あたりのイベント数、同時クライアント数、バックアップとの重複、ホスト全体でのサービス同時実行数などが考えられます。次に、その処理を高速化し得るキャッシュを洗い出します。すべてのキャッシュを無差別にクリアするのではなく、制御されたコールド状態と、現実的なウォーム状態を1つずつ作り、両方を測定可能にしてください。

コールド実行とウォーム実行で、役立つ2つの極端な状態を把握する

コールド実行では、データやアセットが常駐していない状態でシステムがどう動作するかを確認できます。ウォーム実行では、ユーザーが頻繁に経験する、再利用が発生する定常経路を確認できます。どちらも常に「現実的」とは限りません。毎朝1回だけ開くスマートフォンはフロントエンドのコールド状態に近いかもしれませんが、壁掛けタブレットや負荷の高いデータベースは、1日の大半をウォーム状態で動作している可能性があります。

ストレージのベンチマークでは、最初の実行によってファイルシステムキャッシュがウォームアップするため、連続した2回の実行結果が単純に異なることがあります。そのため、コールドキャッシュとウォームキャッシュの状態を混在させず、識別する必要があります。同じ原則はHome Assistantの履歴テストやアセットテストにも当てはまります。2回目の実行が速かったとしても、それは再利用の証拠であって、それだけでサーバー容量が大きいことの証明にはなりません。

最良値だけでなく、両方の分布を記録してください。データ、クライアント、ネットワーク、ダッシュボード設定は同一にします。ウォーム状態の結果が非常に良くても、コールド状態の結果が家庭内の許容時間を超えるなら、常時開いているクライアントには適していても、再起動、復旧、または利用頻度の低いモバイルアクセスには不向きかもしれません。容量に関する主張には、どの状態を示しているのかを明記してください。

容量は、繰り返し処理が線形に拡大しなくなるときに現れる

容量を測定するには、他の条件を一定に保ちながら、1つのワークロード変数を増やします。イベントレート、ダッシュボードのクライアント数、履歴クエリの同時実行数、データベースの書き込みレート、または他のサービスの負荷などです。Home Assistantのダッシュボードを実際に調査した例では、継続的なWebSocket更新負荷によってクライアントが遅れ始める様子が示されています。1回だけ得られたキャッシュ利用時のピーク値よりも、キューイングとテールの挙動のほうが有益な情報になります。これらの兆候を、CPU、メモリ、ストレージ、ネットワークの使用率と併せて監視してください。

ZimaSpaceでは、共有ストレージのキュー競合において、同様の飽和メカニズムが見られます。スループットが高いままでも、未処理の作業量が有効な並列性を超えると、インタラクティブなテールレイテンシーが増加することがあります。Home Assistantの容量測定でも、レイテンシーを考慮した停止条件が必要です。

マーケティングに流されないための重要な原則は、空きCPUが多いからといって、システム全体の容量が大きいとは限らないということです。オートメーションは無線通信の応答待ちになることがあり、CPUがアイドル状態でもストレージが飽和することがあります。また、サーバーが応答した後にモバイルクライアント側でのレンダリングが遅くなる場合もあります。容量は、1つの使用率ではなく、測定対象となる完全な経路と、その間固定された条件に属します。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

余裕容量を宣言する前に、キャッシュの追い出しと他のサービスをテストする

ホームサーバーは、Home Assistantだけを動かしているわけではありません。バックアップ、メディアスキャン、AIジョブ、カメラ録画、データベース、コンテナなどによって、有用なキャッシュページが追い出されたり、ストレージやメモリの競合が発生したりします。そのため、ほかの負荷がないホストで実施したベンチマークは、本番環境では実際のピーク時に維持できないウォーム状態のワーキングセットを示している可能性があります。

2026年のRecorder最適化事例では、履歴の書き込み量を削減する実践例が紹介されています。これにより、データベースが必要とするI/Oと保持ワーキングセットが減少します。これは、単に2回目のクエリを高速に見せるのではなく、実際の容量の境界を変えるものです。

通常のバックアップ、カメラ、またはコンテナのワークロードを動かした状態で、定常状態のテストを繰り返してください。レイテンシーが目標範囲内に収まり、キャッシュヒットの挙動も安定しているなら、ウォーム状態の結果の信頼性は高まります。別のサービスによってキャッシュが追い出されたり、キューが埋まったりした後にだけ性能が急落するなら、そのホストの本番環境での余裕は、Home Assistant単体のベンチマークが示したものより小さいことになります。

条件を明記して容量結果を公開する

有用な結果には、Home Assistantのバージョン、ハードウェア、ストレージ、データベース、エンティティ数、保持期間、クライアントの種類、ダッシュボード、ネットワーク経路、ウォームまたはコールドの条件、バックグラウンドワークロード、入力レート、テスト時間、合格基準を記載します。これらの詳細がなければ、「Home Assistantは100ミリ秒で応答する」という結果を比較したり再現したりできません。

独立したHome Assistantの同時実行性分析では、asyncioのイベントループがオートメーションタスクをスケジュールする仕組みと、I/O待ちによってタスクが一時停止する仕組みが説明されています。対象ワークロードがオートメーション中心である場合は、ストレージやCPUの使用率だけで容量を判断せず、イベントループの応答性とブロッキング動作も含めてください。

通常発生する最悪の重複負荷を十分な時間実行して定常状態に到達し、テールレイテンシーが目標範囲内に収まり、キューが増え続けず、繰り返し試験で同様の結果が得られた場合にのみ、システムに十分な容量があると判断してください。ウォームキャッシュは1つの動作条件として扱い、家やホストにサービスが増えるにつれて、常に利用できる倍率だとは考えないでください。

FAQ

ベンチマークの前に毎回Home Assistantを再起動すべきですか？

いいえ。再起動によってコールドスタートのシナリオを作ることはできますが、同時に多くの変数が変化します。起動テストでは意図的に再起動を使い、その後は再起動せずに、ウォーム状態と定常状態のテストを分けて実行してください。

最速の実行結果が容量の最良の推定値ですか？

いいえ。最速の実行結果は通常、キャッシュとスケジューリングの条件が有利だったことを示します。容量の判断には、持続的な負荷の下で再現性のある分布とテールレイテンシーを使用してください。システムが飽和に近づいたとき、ユーザーが気づくのは遅い実行結果だからです。

キャッシュヒット率が高いことは悪いと考えるべきですか？

いいえ。再利用は望ましいことです。問題は、ワーキングセット、エンティティ数、履歴、周辺サービスが増えても、キャッシュされたデータが常にメモリ上に残ると仮定することです。ワークロードが同じキャッシュフットプリントに無理なく収まらなくなったときに何が起こるかを測定してください。