Home Assistantは実際に何をキャッシュし、どの繰り返しリクエストが高速化されるのか？

「Home Assistantは2回目のほうが速い」という表現は、いくつかの異なる仕組みを指す場合があります。ブラウザーがフロントエンドのアセットを再利用することもあれば、すでに開いているダッシュボードがページを再構築する代わりにWebSocket経由で最新の状態を受信することもあります。OSがデータベースや設定ページをメモリ上に保持することもあれば、インテグレーションが確立済みの接続を再利用することもあります。

これらすべての効果を「Home Assistantのキャッシュ」と呼ぶと、どこで高速化が起きているのかが分からなくなります。実用的なモデルでは、繰り返されるリクエストを特定し、2回目の実行でどのレイヤーが処理を省略できるのかを見極めます。

ブラウザーキャッシュはフロントエンドアセットを高速化する

JavaScript、スタイル、アイコン、カスタムカード、その他のフロントエンドリソースはブラウザーキャッシュに保持されるため、ページを再読み込みする際に同じアセットを最初からダウンロードしたり再構築したりせずに済みます。

Home Assistantの現在のブラウザーに関する案内では、ユーザーインターフェースは高速化のため、多くのものをブラウザーにキャッシュすると明記されています。このキャッシュは、アップデート後やカスタムカードの変更後に古くなることがあります。そのため、正常に動作しないUIはハードリフレッシュで直る場合があります。

このキャッシュが変えるのは、ページの起動と描画であり、物理デバイスの制御速度ではありません。キャッシュの消去はフロントエンドの検証であって、サーバー全体のパフォーマンスをリセットする操作ではありません。

開いたままのダッシュボードはライブWebSocketの状態経路を再利用する

フロントエンドが接続されると、変更のたびにスマートホーム全体の状態を再取得する必要はありません。WebSocket APIを通じて更新やサブスクリプションを受信し、該当するインターフェースコンポーネントを更新します。

現在のフロントエンドアーキテクチャでは、フロントエンドが共有hassオブジェクトを通じてコアの状態を受け取り、追加の購読データをWebSocket経由で同期し続ける仕組みが説明されています。そのため、接続を維持する壁掛けタブレットと、毎朝ダッシュボードを初めて開くスマートフォンでは、繰り返されるリクエストの経路が異なります。

ただし、この再利用を、多数のクライアントが線形にスケールする証拠と解釈してはいけません。クライアントが増えるたびに、シリアライズ、サブスクリプション、履歴リクエスト、クライアント側の描画処理が追加される可能性があります。

Linuxのページキャッシュはファイルやデータベースの繰り返し読み込みを高速化する

通常のファイルシステムの読み取りは、Linuxのページキャッシュを経由します。最近使用されたデータベースのページ、設定ファイル、静的アセットはメモリに残ることがあり、繰り返しのリクエストで物理ストレージから再度読み取る必要がなくなります。

Linuxカーネルの現在のドキュメントでは、通常のファイル読み取りによってページキャッシュが作成され、その後の読み取りで高コストなストレージアクセスを省略できる仕組みが説明されています。つまり、Home Assistantがその特定のクエリに対してアプリケーションレベルの専用キャッシュを実装していなくても、繰り返し実行する履歴クエリはメモリの恩恵を受ける可能性があります。

このため、SSDとHDDの違いは、再起動後、キャッシュが追い出された後、またはワーキングセットが大幅に大きくなった場合よりも、キャッシュが温まった状態でのテストでは小さく見えることがあります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

データが温まっていても、基になるクエリのコストが下がったわけではない

履歴リクエストは、必要なページがたまたまメモリ上にあっても、論理的には同じ量のデータをスキャンしたり、同じインデックスを参照したりする場合があります。ダッシュボードも、アセットと接続状態がすでに利用可能になっていても、同じエンティティをリクエストすることがあります。

ウォームキャッシュ時のパフォーマンスと実際の容量を分けて考えることを扱った関連するZimaSpaceのベンチマークガイドでは、その運用上の意味が示されています。キャッシュは有用ですが、容量に関する主張は、現実的なキャッシュ圧迫と継続的なワークロードに耐えられるものでなければなりません。

キャッシュヒットは、1つのリクエストから1つのコストを取り除くだけです。経路上の他の段階に属するCPU、メモリ、ネットワーク、データベース、インテグレーションの処理まで取り除くものではありません。

繰り返されるリクエストごとに温まるレイヤーは異なる

• 同じダッシュボードを再読み込みする：ブラウザーのアセットとクライアントランタイムが温まっている可能性があります。
• 壁掛けタブレットを開いたままにする：WebSocketの状態とサブスクリプションが維持されます。
• 同じ履歴範囲を繰り返し表示する：データベースやファイルシステムのページがメモリに残っている可能性があります。
• 同じローカルサービスを呼び出す：確立済みのインテグレーション接続やネットワーク接続がすでに存在している可能性があります。
• 再起動後に開く：これらのレイヤーのいくつかが同時に冷えた状態になっている可能性があります。

すべてのキャッシュを消去して、それを「科学的」と呼ぶのではなく、ユーザーの操作に対応するレイヤーを測定してください。

よくある質問

ブラウザーキャッシュを消去すると、Home Assistant Coreは遅くなりますか？

主に変わるのは、フロントエンドの読み込み経路です。Coreは同じサーバーロジックを実行しますが、ブラウザーはアセットを再度ダウンロードして再構築する必要があるため、インターフェースの初回読み込みが遅くなることがあります。

ウォーム状態の履歴クエリは、ベンチマークに使えませんか？

いいえ。ウォーム状態のクエリは、実際の運用状態を表します。問題は、メモリ圧迫、再起動、ワーキングセットの拡大によって同じキャッシュのメリットが失われる可能性があるのに、ウォーム状態の結果だけを容量の結果として扱うことです。