再現可能なホームサーバーのワークロードでImmichをベンチマークする方法

エヴァ・ウォン

IceWhale author

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

再現可能なImmichベンチマークでは、1つの変数を変更する前に、メディアの対象群、クライアント経路、キャッシュ状態、バックグラウンド処理の重複、測定対象のエンドポイントを固定します。

これらを制御しなければ、2回目の実行が高速になったように見えても、ハードウェアの改善ではなくデータがキャッシュされているだけかもしれません。また、アイドル状態でのテストでは、インポート時の競合が隠れる可能性があります。役立つホームサーバーベンチマークでは、家庭で実際に発生する閲覧、アップロード、検索、復旧の要求を同じ順序で再現します。

メトリクスを収集する前にユーザーの成果を定義する

まず、アップロードの受け付け、新しい写真が検索可能になるまでの時間、タイムラインのサムネイル生成完了、オリジナル画像の表示、動画の再生開始、使用可能なライブラリへの復旧など、観測可能な成果から始めます。CPU使用率やディスクスループットはこれらの成果を説明するものですが、ユーザーが感じる結果の代わりにはなりません。

ZimaSpaceのImmichのデータパスに関する記事では、アップロードの受け付け、処理の準備完了、検索結果の選択、メディアの配信を分けて説明しています。この構造が役立つのは、ベンチマークで複数の依存する段階を混ぜて誤解を招く合計値にするのではなく、1つのエンドポイントを計測する必要があるためです。

インタラクティブなエンドポイントを2つ、バックグラウンドのエンドポイントを1つ選びます。それぞれに合格基準を設定し、中央値に加えて遅い側のレイテンシーまたは完了率を記録します。無関係なスコアを大量に含むベンチマークは解釈が難しくなります。特定の判断に結び付いた少数の指標に絞ることで、結果を実際の行動につなげやすくなります。

データセット、クライアント経路、開始状態を固定する

家族のライブラリに合った形式とサイズを含む、代表的な同じ写真と動画をすべての実行で使用します。アカウント、クライアントデバイス、ネットワーク経路、Immichのバージョン、派生ファイルの設定を固定します。ブラウザーのキャッシュやWi-Fiの経路が変わっただけでも、検証対象の設定差を上回る影響が出ることがあります。

ベクトル検索のベンチマークに関する記事では、PostgreSQLの検索性能を調べる際に、埋め込み、挿入、検索のワークロードを再現可能にすることの重要性を強調しています。Immichはより広範なアプリケーションですが、この実験原則は応用できます。測定値の差から結論を導くには、制御された入力と、定義された検索操作が必要です。

ファイルのチェックサム、件数、合計バイト数、写真形式、動画の再生時間、期待される検索結果を含むデータセットマニフェストを作成します。再起動したサービス、ウォームアップ操作、キューに入っているジョブ、競合するアプリケーションを確認する開始チェックリストも追加します。チェックリストの内容が異なる場合は、平均に含めず、比較不能な実行として記録します。

コールド、ウォーム、持続の各フェーズを実行する

コールドフェーズでは、初期化と初回アクセスのコストが明らかになります。ウォームフェーズでは、直後に繰り返した場合の再利用性能が分かります。持続フェーズでは、代表的なインポートやバックグラウンドキューを長時間実行しながら操作を繰り返し、サーマルスロットリング、メモリ圧迫、ストレージキュー、リソース競合を明らかにします。

あるコミュニティの報告では、最初のスマート検索に約5秒かかり、モデルのメモリ使用量が変化する一方で、直後の繰り返しは約0.5秒だったとされています。これらの数値はベンチマークの基準ではありません。コールド状態とウォーム状態のリクエストを平均すると、テストで説明すべき遷移が隠れてしまうことを示す例です。

各フェーズを少なくとも3回実行し、生のタイムスタンプとリソースのトレースを保存します。インタラクティブな処理では中央値と遅い側の指標を、バックグラウンド処理では1分あたりのキュー処理件数を記録します。エラー、スワップの大量発生、サーマルリミットによって意図した定常状態が損なわれた場合は、実行を中止します。

Featured

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

ZimaCube2

1変数のランシートを使用する

実行前に仮説を書きます。データベースの配置、ワーカーの同時実行数、メモリ制限、ネットワーク経路、アクセラレーターのいずれかを変更し、1つの明示したメカニズムによって、名前を付けた1つのエンドポイントを改善する、という形です。それ以外はすべて固定します。これにより、複数の変更を伴うアップグレードで結果が速くなっても、根拠を持って原因を説明できない事態を防げます。

一般的なボトルネック分析では、CPU、RAM、ストレージ、ネットワークの制限が、それぞれ異なる使用率のパターンとユーザーへの影響を生むことを説明しています。Immichに適用する場合、補助的なメトリクスはエンドポイントの結果と一貫して変化する必要があります。最も高い数値を示すグラフが、必ずしも制限要因とは限りません。

コールド、ウォーム、持続の各フェーズについて、ベースラインと変更後の結果を記録し、合格、不合格、判定不能のいずれかを付けます。繰り返すと消える改善や、エラー、不安定な温度、キューの進行状況の消失、復旧時間の増加を引き起こす改善は採用しません。将来のリリースと正しく比較できるよう、マニフェストとランシートを保存します。