Immichはクライアントによって応答性が異なるように感じられるのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Immich Feel Less Responsive Across Different Clients? - Zima Store Online

Immichは、クライアント側のレンダリング、画像のデコード、キャッシュの状態、ネットワーク経路がサーバーの応答後に追加の処理を発生させるため、あるクライアントでは遅く感じられることがあります。

同じサーバー、ストレージ、データベースを使い続けていても、家族がデスクトップブラウザー、古いスマートフォン、タブレットから同じライブラリを閲覧することがあります。サーバーが変わっていなくても、エンドツーエンドのリクエストにはサーバー外の処理が含まれるため、あるデバイスではタイムラインやプレビューの表示が遅くなることがあります。したがって有用な比較は、サーバーの応答時間と、各クライアントが結果を受信、デコード、キャッシュ、描画するために費やす追加時間を分けて考えることです。

Immichの応答後に行われる処理はクライアントによって異なる

Immichのリクエストは、サーバーがJSON、サムネイルURL、または画像レスポンスを準備した時点で終わるわけではありません。クライアントはそのレスポンスを処理し、インターフェースを更新し、レンダリングをスケジュールし、ユーザー入力に対応する必要があります。そのため、返されたデータを表示可能で操作できる画面に変換する処理にデバイスやブラウザーが余分な時間をかけると、高速なサーバーでもクライアントが重く感じられることがあります。

この違いは、JavaScript、イベント処理、スタイル計算、レイアウト、描画処理の多くがメインスレッドの処理を奪い合うブラウザーで特に重要です。古いスマートフォンや負荷の高いブラウザーがそのスレッドを長く占有すると、高速なデスクトップとImmich APIの完了時刻がほぼ同じでも、タップやスクロールが遅れることがあります。

サーバーのCPU使用率やデータベースのレイテンシーだけを比較しても、体感の一部を見落としてしまうのはこのためです。ZimaSpaceによるネイティブクライアントとブラウザークライアントの解説でも、同じバックエンドが異なるクライアント実行経路にデータを供給できるという、同じシステム上の原則が示されています。Immichでは、遅延がレスポンス到着前に発生しているのか、それともクライアントが処理を始めた後に発生しているのかを確認することが、最初の診断ポイントになります。

画像のレンダリングによって高速なレスポンスも遅く感じられる

写真の閲覧では、クライアント間の差がより明確になります。ギャラリーはテキストやAPIメタデータだけで構成されているわけではありません。クライアントは多数のサムネイルや大きなプレビューを要求し、一部をメモリに保持し、圧縮された画像データをデコードし、ビューポートに合わせて拡大縮小しながら、ユーザーがスクロールし続ける間に複数の画像を合成することがあります。同じImmichアセットを要求していても、こうしたローカル処理の量やタイミングはデバイスによって大きく異なります。

JPEGやWebPなどの圧縮形式は、ピクセルを表示する前に画像のデコードを行う必要があります。高速なCPU、より最適化されたデコーダー、利用可能なメモリ容量の多さ、異なるブラウザーエンジンによって、この段階は短縮できます。性能の低いクライアントではネットワーク処理が先に終わり、ユーザーが実際に待つ部分がデコードや描画になることがあります。

実際には、サーバーが高速に生成できるからといって、より大きく鮮明なプレビューが無料になるわけではありません。高解像度の画像ほど、デコード後のピクセルを保持するメモリと、拡大縮小や描画の処理が多く必要です。あるクライアントがフルプレビューの表示や、写真が密集したタイムラインの高速スクロール時だけ遅くなり、単純なメタデータ画面は問題なく動作するなら、サーバー全体の容量不足よりも画像レンダリング経路のほうが有力な説明になります。

キャッシュが温まっているかどうかで再訪時の速度は変わる

すでにアルバムを閲覧したクライアントは、サムネイル、スクリプト、メタデータ、デコード済みリソースなどを再利用できます。一方、初めて使うクライアントは、それらを取得して処理する必要があります。そのため2回目の閲覧は短時間で済みますが、サーバーの処理能力が突然向上したわけではありません。クライアントが1回目よりも温まった状態で開始したことで、リクエスト経路の一部が不要になったということです。

実際のブラウザー調査では、キャッシュヒット率はブラウザー、バージョン、デバイス、時間によって異なります。Facebookの具体的な割合はImmichのベンチマークではありませんが、仕組みは重要です。2台のクライアントが同じサーバーに接続していても、ローカルキャッシュの履歴は異なる可能性があります。そのため、キャッシュが温まったデスクトップブラウザーは、新しくインストールしたスマートフォンアプリよりはるかに反応が良く見えることがありますが、それだけでどちらかのクライアントが本質的に速いとは証明できません。

キャッシュは、比較テストの前後にも誤解を生みます。同じアルバムを何度も更新すると、後続の実行ではダウンロードや処理の一部が不要になるため、最速の結果は代表的な家族全体の利用状況ではなく、再利用の効果を測っていることがよくあります。クライアントを比較するなら、キャッシュが冷えた状態または新しく開いた状態と、再訪時の状態の両方を記録してください。その差自体が、各クライアントがローカルでの再利用にどの程度依存しているかを示す有用な証拠になります。

-15% OFF

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

Single board computer zimaboard2

クライアントの違いでは遅延を説明できなくなる場合

同じ負荷の下で、異なる複数のクライアントが同時に遅くなった場合、クライアントの違いは主な原因ではなくなります。デスクトップブラウザー、スマートフォン、タブレットがすべて、タイムラインデータやプレビューのレスポンスを待つようになり、その間にサーバーCPU、ストレージレイテンシー、データベース処理、ネットワーク使用率が上昇しているなら、単一のクライアント実装よりも共有インフラが応答性の下限を決めている可能性が高くなります。

エンドツーエンドの時間を測るときは、最も測りやすく見えるコンポーネントだけで判断しないでください。Datadogのレイテンシー分析では、ラウンドトリップレイテンシーには、データベース自体以外にも、ネットワーク転送、プロキシ、コネクションプール、アプリケーションによるデコードが含まれることが示されています。同じ原則はImmichにも当てはまります。データベースの数値が健全でも、リクエスト開始から描画済みの結果に至るまでのどこかに遅延がある可能性は排除できません。

有用な境界テストは対称性を見ることです。同じLAN上で同じアルバムを使っている別のクライアントは速いのに、1台だけ遅い場合は、クライアントの実行処理、キャッシュ、ローカルネットワークを重視して調べるべきです。すべてのクライアントがほぼ同じタイミングで同じレイテンシーのしきい値を超える場合、特にインポート、サムネイル生成、バックアップ、その他のホスト処理中に発生するなら、原因はクライアントのばらつきから、共有サーバー、ストレージ、ネットワークの制約へと移っています。

管理されたクライアントテストで境界を見つける

代表的なアルバムを1つ選び、サーバーのバージョン、ネットワーク上の場所、アカウント、画像セット、バックグラウンドジョブの状態を一定に保ちます。各クライアントを1台ずつテストし、タイムラインの初回読み込み、同じ大きなプレビューを開くまでの時間、固定した写真範囲を素早くスクロールしたときの3つの実測時間を記録します。また、各テスト中にサーバーのリソース使用率が上昇したかどうかも記録してください。サンプル間でバックエンドの負荷が変化していると、クライアント比較は無効になるためです。

各クライアントを、意図的にキャッシュを冷やした状態で1回実行し、その直後にもう一度実行します。パフォーマンステストでは、後続のリクエストから処理が取り除かれるため、一般的に初回表示と再表示の結果を分けて考えます。Immichでは、冷えた状態から温まった状態までの差が、再利用によって体験がどの程度変わるかを示します。同じキャッシュ条件でのクライアント間の差は、デバイスやアプリケーションに起因する可能性が高い違いを明らかにします。

サーバーとネットワークの条件が同程度に保たれ、速いクライアントが少なくとも3回の実行で一貫して速い場合にのみ、その差をクライアント側の問題と判断してください。すべてのクライアントが同時に低速化するなら、クライアントの調整をやめて共通経路を調べます。画像を多用する操作だけで差が出るなら、デコードとレンダリングに注目します。初回実行時だけ差が出るなら、持続的なサーバー容量ではなく、キャッシュの状態がより妥当な結論です。