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

エヴァ・ウォン

IceWhale author

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

How to Measure Immich Performance Without Mistaking Cache for Capacity - Zima Store Online

Immichの容量は、1回の高速なキャッシュ済み実行ではシステムの実際の飽和点が隠れる可能性があるため、コールド、ウォーム、持続的なワークロードを繰り返して測定する必要があります。

ホームサーバーでは、同じサムネイル、データベースページ、アプリケーションデータにすでにアクセスした後なら、タイムラインやアルバムが非常に高速に感じられることがあります。しかしその結果が示すのは、ウォーム経路が効率的だということであり、システムがより大きな家族のライブラリや、より多くの同時アクティビティを持続的に処理できるということではありません。有用な容量テストでは、キャッシュの状態を管理し、ワーキングセットを拡大し、実行を繰り返し、測定可能な停止条件を定める必要があります。

キャッシュ速度と容量は同じではない

容量とは、レイテンシー、キュー、またはエラーが許容できない状態になる前に、Immichシステムがどれだけ代表的な処理を持続できるかを表します。キャッシュ速度が答えるのは、役立つデータや生成済みアセットがすでに近くにある状態で、システムがどれだけ速く同じ処理を繰り返せるかという、より限定された問いです。ベンチマークが同じアルバムやタイムラインを繰り返す場合、この2つの問いは同じように見えることがありますが、実際には異なる動作条件を測定しています。

この違いは、後続のリクエストがキャッシュされたリソースを再利用するため、初回表示と再表示の所要時間が乖離するウェブパフォーマンスで簡単に確認できます。Immichでは、サムネイル、プレビュー、データベースページ、ファイルシステムのメタデータ、OSキャッシュ、クライアントアセットなどが再利用されるため、ウォーム状態になる機会がさらに多くあります。そのため、再実行では、拡大中のライブラリや新たにアクセスされたライブラリで必要となる処理が省かれる可能性があります。

これは、繰り返しリクエストがサンプルの大部分を占める場合、キャッシュに焦点を当てたHome Assistantのテストが誤解を招く可能性があるのと同じ理由です。繰り返しリクエストのキャッシュ層に関するZimaSpaceの解説は、ここでの測定ロジックにも当てはまります。Immichではウォーム時の性能を記録しますが、それをサーバー全体の容量として扱うのではなく、別の経路として明示してください。

コールド、ウォーム、定常状態の実行を分ける

まず、ストップウォッチを押す前の状態を定義します。コールド実行には、キャッシュが役立つ機会が少ない状態で、別の日付範囲やアセットセットを開くなど、直前に繰り返していない処理を含めます。ウォーム実行では、既知の経路を意図的に繰り返します。定常状態の実行では、代表的なアクティビティを十分な時間継続し、短いバーストでは現れないバックグラウンド処理、リソースの再利用、キューを明らかにします。

ウォームアップ自体が誤解を招くこともあります。Perconaは、遅延したバックグラウンドプロセスが性能を変化させ続けているため、データベースがウォームアップ済みに見えても、実際にはそうでないケースを説明しています。つまり、定常状態に到達するのは、最初の高速なクエリより後になることがあります。Immichでも、ライブラリの状態に応じて、フォアグラウンドの閲覧とデータベース処理、サムネイル処理、インデックス作成、その他のキュー内ジョブが同時に進む可能性があります。

ホームサーバーのテストでは、これらのフェーズを一緒に平均するのではなく、それぞれ個別に実行します。バックグラウンドジョブがアイドル状態かアクティブ状態かを記録し、クライアントとネットワーク経路を一定に保ち、同じフェーズを数回繰り返します。ウォーム実行が高速でも、持続的なアクティビティによってレイテンシーやキューの深さが徐々に増加するなら、容量計画にとってより良い指標は後者です。

ワーキングセットを簡単にキャッシュできる範囲より大きくする

同じ20枚の写真を開くベンチマークでは、家族のライブラリ容量に関する問いに答えるには通常小さすぎます。OS、データベース、クライアント、ストレージスタックは、小さなホットセットをプロセッサの近くに保持できますが、実際の利用では月、人物、アルバム、検索結果、動画の間を移動します。そのためテストセットは、すべての操作が同じ直近のデータの恩恵を受けないよう、十分に大きく変化に富んでいる必要があります。

データベースベンチマークの実践では、この違いが明確に示されています。ストレージやコールド状態を調べることを目的としたテストでは、残存キャッシュによって、実際にはキャッシュ性能のテストになってしまう可能性があります。本番のImmichサーバーですべてのキャッシュ層を消去する必要はありませんが、1つの画面を繰り返し再利用するよりも広いワーキングセットを持つワークロードを用意する必要があります。

通常の家庭での利用に近い複数の日付範囲、アルバム、検索、アセットタイプを選び、1つのビューを繰り返し処理するのではなく、順番に切り替えます。ハードウェアや設定を比較する際も、そのワークロードの定義を維持してください。変更によって小さな反復サブセットだけが改善し、より広いナビゲーションが負荷時に劣化し続けるなら、ホット経路は改善されたものの、実用的な容量の境界は変わっていません。

-15% OFF

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

Single board computer zimaboard2

パーセンタイルを測定し、テストを繰り返す

1つの平均値では、ユーザーが実際に気付く瞬間が隠れてしまいます。9件のリクエストが高速でも、キューが増加したりストレージがビジー状態になったりして10件目が停止すれば、平均値はなお良好に見える可能性があります。少なくとも中央値とp95などのテールパーセンタイルを記録し、レイテンシーをスループット、エラー数、ジョブのバックログ、CPU、メモリプレッシャー、ストレージアクティビティと組み合わせて、低下の背景も把握してください。

実用的なベンチマーク分析では、特にキャッシュの追い出し、コンパクション、バックグラウンドアクティビティが後から現れる可能性のあるステートフルなシステムでは、単一の実行結果を信頼するのではなく、p50、p95、p99と分散を報告することが推奨されています。Immichのテストに実験室レベルの精度は必要ありませんが、再現可能な限界と、たまたま静かな時間帯とを区別できるだけの繰り返しは必要です。

各負荷レベルで同じシナリオを少なくとも数回実行し、最良の結果だけを残すのではなく、生の観測値を保持します。p95が実行間で安定し、測定ウィンドウ間でサーバーがキュー内の処理を完了できているなら、容量に関する主張の信頼性は高まります。結果が大きく変動する場合は、ユーザー数、写真数、または高速なハードウェアによって上限が変わったと判断する前に、管理されていない変数を調べてください。

停止条件を備えたImmich容量プロトコルを使う

まず、代表的な1つのクライアントワークロードから始め、テスト対象として意図した状態にシステムが到達した後でベースラインを取得します。次に、同時閲覧、アップロード、検索、バックグラウンド処理の増加など、1度に1つの変数だけを増やし、ライブラリ、クライアント構成、ネットワーク経路、サーバー設定は固定します。各段階で、p50およびp95のレイテンシー、1分あたりの成功処理数、エラー、キューの増加、飽和に近づいている主要なサーバーリソースを記録します。

この方法なら、1回の短い実行結果から結論を出すという一般的な誤りを避けられます。パフォーマンステストのガイダンスでは、ウォームアップ、キャッシュ状態、バックグラウンド処理、通常のシステムノイズがサンプルを支配する可能性があるため、単一実行による結論を避けるよう警告しています。各負荷レベルを、単に引用しやすいのではなく、傾向を説明できる程度に安定するまで繰り返してください。

テスト前に停止ルールを宣言します。実用的なホームラボ向けのヒューリスティックとして、p95レイテンシーが3つの連続した測定ウィンドウで未負荷時のベースラインの約2倍を超え続ける場合、またはエラーやジョブのバックログが増え続けて回復しない場合、現在の設定が飽和したと判断できます。これはテスト上のヒューリスティックであり、Immichの制限値ではありません。有用な容量の数値は、同じコールド、ウォーム、定常状態のプロトコルで測定した、その境界を下回る最後の負荷レベルです。