Immichのキャッシュ：ウォームデータが繰り返しリクエストをどう変えるか

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Immich Caching: How Warm Data Changes Repeated Requests

モデル、データベースページ、サムネイル、クライアントアセットが十分にウォームな状態に保たれ、初回の読み込み処理を再び行わずに済むと、Immichへの繰り返しリクエストは高速になります。

2回目の検索が、必ずしもサーバーの容量が増えた証拠になるとは限りません。1回目のリクエストで準備されたデータを再利用している可能性があるため、意味のあるテストでは、どの状態が保持されるのかを特定し、コールド時とウォーム時の挙動を別々に報告する必要があります。

初回リクエストでは、存在しない状態の準備に時間がかかる

再起動後や長時間アイドル状態だった後は、Immichのリクエストで、コードパス、モデルの重み、データベースページ、サムネイルファイルをアクティブメモリに読み込む必要が生じる場合があります。接続の確立やクライアントアセットの取得が発生することもあります。後続のリクエストでは、表示上は同じクエリでも、これらの処理の一部が省略されます。

ユーザーの報告では、初回のスマート検索に約5秒、直後の再検索に約0.5秒かかり、モデルの読み込みに伴ってGPUメモリが増加したと測定されています。数値は構成によって異なりますが、この観測結果は、初回検索と繰り返し検索が異なるシステム状態を表す理由を示しています。

完全なコンテナの再起動、機械学習サービスの再起動、クライアント状態の消去、または定義したアイドル時間など、正確なコールド条件を記録してください。これらの条件は同じものではありません。「コールド」とだけ記された結果では、遅延の原因がモデルの常駐、サーバーのページキャッシュ、接続の確立、クライアント側の再利用のいずれだったのかを判断できません。

ウォーム状態は複数の独立した層に存在する

繰り返しリクエストをすべて説明できる、単一のImmichキャッシュ設定はありません。オペレーティングシステムはファイルページを保持でき、PostgreSQLはホットデータを再利用でき、機械学習プロセスは読み込み済みのモデルを保持でき、ブラウザやモバイルアプリはサムネイルやアプリケーションアセットを再利用できます。それぞれの層で保持期間は異なります。

キャッシュウォーミングの概要では、一般的な違いが説明されています。ウォームキャッシュは保持されたデータをより短い遅延で提供しますが、コールドキャッシュでは、より低速な一次データソースから取得する必要があります。Immichでは、この一次データソースが永続ストレージであり、「データ」がメディア、データベースページ、モデルファイルである場合があります。

選択的にリセットしてください。同じブラウザで繰り返した後、新しいクライアントで試し、次に機械学習サービスだけを再起動し、その後アプリケーションを再起動し、最後にホストを再起動します。長い遅延が最初に復活したリセットによって、保持された状態が最も大きく寄与した層を特定できます。ただし、複数の層が複合的に影響している可能性もあります。

ウォームな結果は容量の限界を隠すことがある

少数の繰り返し検索では、必要なページとサムネイルだけを常駐させられる場合があります。そのベンチマークは非常に良好に見えても、より大規模なライブラリではメモリを超過し、頻繁なキャッシュミスが発生する可能性があります。ワーキングセットが変化したとき、別のサービスがデータを追い出したとき、または再起動によって一時的な状態が失われたときに、容量の限界が明らかになります。

ZimaSpaceのデータパスの解説では、データベースによる選択とメディア表示が分けて説明されています。これにより、ウォームなサムネイルが遅いクエリを隠したり、キャッシュされたクエリが遅いファイル配信を隠したりするのを防げます。繰り返しリクエストによる改善を診断する際は、結果の識別子と表示アセットを個別に計測してください。

1つの項目を延々と繰り返すのではなく、複数のクエリとタイムラインの範囲を入れ替えてください。代表的なアイドル時間と、競合するワークロードも含めます。サーバーに有用な容量があると言えるのは、1つのホットパスが常駐し続けた場合だけではなく、想定されるワーキングセット全体で許容可能なレイテンシーが維持される場合です。

Featured

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

ZimaCube2

コールド、ウォーム、状態を乱した実行をまとめて報告する

3段階のプロトコルを構築します。まず、記録したコールド条件の後にエンドポイントを実行します。次に、入力を変更せず、すぐに同じ処理を繰り返します。3回目は、想定される変化、つまりアイドル時間、別のコンテナ、より広いクエリセットなどを導入してから再実行します。ストップウォッチの単一の値ではなく、中央値と遅い側のレイテンシーを記録してください。

初回検索に関するサポートスレッドでは、最初に10～15秒の遅延が発生し、その後の繰り返しはほぼ即時になったと報告されています。これは、両方の分布を保持する必要性を裏付けています。ただし、Immichに共通する所要時間を示すものではありません。モデルの選択、アクセラレーター、メモリ、ストレージ、リリースによって差は変わります。

最後に、2つの数値と1つの境界条件を示します。通常のウォーム時レイテンシー、通常のコールド時レイテンシー、そしてウォーム状態が失われるイベントです。コールド時の挙動が家庭内での目標を満たさない場合は、必要な状態を常駐させるか、その読み込み経路を改善してください。人工的なコールドテストだけが失敗する場合は、許容する運用条件として記録します。