Nextcloudの内部画像処理を軽くしてサクサク表示させる (2) Preview Generatorを使う

Nextcloudで画面を表示すると、プレビュー画像（サムネイル）が表示されるまで時間がかかる。大量の画像を一覧表示するときは画面表示が待たされる。

一度生成されたプレビュー画像はサーバに保存されて再利用されるので、２回目以降はサクサク表示されるが、初回の閲覧では画像表示に時間がかかる。画面上の画像一覧表示はImageMagickでプレビュー画像を生成しながら画面を表示しているので仕方がない面がある。

ファイル一覧用に小さなプレビュー画像を次々と生成している

Preview Generator

そこで、NextcloudにはPreview Generatorというアプリ（プラグイン）をインストール可能である。このアプリはcronでジョブをバックグラウンドで回し、プレビュー画像を事前に生成しておくというもの。写真や動画をアップロードすると、自動で各サイズのプレビュー画像を裏で作成してくれる。これにより事前にプレビュー画像がサーバに溜められているので、画面表示が速くなるというわけだ。

インストール手順

Nextcloudのアプリ管理画面 > マルチメディア > Preview Generator のインストールボタンを押す。

準備と実行

cronで回すアプリなので、シェルで準備作業を行う。

既存のプレビュー画像のメンテナンス

一度、プレビュー画像を作り直すことにする。

プレビュー画像データのディレクトリを空にする。場所は data/appdata_xxxxxxxx/preview

data/appdataディレクトリのファイルとDBのエントリーを突き合わせて存在しないファイルエントリーをDBから削除するコマンドを実行する。

% php occ files:scan-app-data

プレビュー画像のエントリーを削除するのであれば、MySQLのテーブル"oc_filecache"を直接空にする方法もあるようなのだが、DBに不整合を起こす原因になるのでocc管理スクリプトによる作業を推奨。
もしもDBをついうっかりいじってやってしまった場合は、次の方法でトラブルシュート可能である

また、外部ストレージとの接続（External Storage）を使用している場合は、外部ストレージのファイルエントリー情報も再スキャンする。

% php occ files:cleanup

プレビュー画像を生成する

それでは、Preview Generatorでプレビュー画像を生成させる。初回なので全ファイルのプレビュー生成を行う。

% php ./occ preview:generate-all -vvv

-vvvオプションをつけると、生成状況が表示される。今回は写真と動画合わせて7万ファイルのプレビュー生成に1週間かかった。環境が仮想マシンで非力だったということもあるが、ちょっとあんまりなので後でさらに最適化してみよう。

もしも、全画像を一気に作成することに問題がある場合は、チェックするディレクトリを指定して作業範囲を限定させることもできる、

% php ./occ preview:generate-all -vvv --path=/username/files/hoge

--path= はNextcloudインストールディレクトリのdata/をルートととしたpath。

コマンドが終了するとプレビューが全て事前に準備された状態になるので画面表示はかなり速くなる。
一連の動作に問題なさそうであればwwwアカウントのcronにプレビュー生成のジョブを追加する。

*/15 * * * *    php /usr/local/www/nextcloud/occ preview:pre-generate

15分ごとに新規追加されたファイルのプレビューをバックグラウンドで生成されるようにした。preview:pre-generateは新規にアップロードされたファイルのサムネイルだけを生成するコマンド。

さて、これで画面をサクサク表示させるプロジェクトは完了かと思いきや、しばらく使っているうちに問題を見つけてしまった。何が起きたか続けてご紹介する。

大量のプレビューファイル問題

これで画面表示は速くなったが、新たな問題が起きている。プレビューの事前生成に1週間もかかったので、いくら非力なマシンと言えどもさすがに変だなと思い、ある一枚の画像に対するプレビュー画像の状況を確認してみた。プレビュー画像は元画像1枚分につき１ディレクトリごとに分けて格納されている。

-rw-r--r--  1 www  www   126K Jan  6 15:43 1024-768-max.jpg
-rw-r--r--  1 www  www    99K Jan  6 15:43 768-768-crop.jpg
-rw-r--r--  1 www  www    21K Jan  6 15:43 341-256.jpg
-rw-r--r--  1 www  www    17K Jan  6 15:43 256-256-crop.jpg
-rw-r--r--  1 www  www    14K Jan  6 15:43 256-192.jpg
-rw-r--r--  1 www  www   2.8K Jan  6 15:43 85-64.jpg
-rw-r--r--  1 www  www   2.3K Jan  6 15:43 64-64-crop.jpg
-rw-r--r--  1 www  www   1.9K Jan  6 15:43 64-48.jpg

解像度ごとのバリエーションが8枚も生成されている。ファイル名が-cropはファイルリスト表示用に正方形にクロップしたもの。64 x 48ピクセルまで縮小された64-48.jpgは本当に必要なのだろうか？画面で使われているところを見たことがない。

ストレージには7万枚の写真と動画ファイルがあるので、7万枚 * 8種類のプレビュー = 56万個ものプレビュー用ファイルを生成していたのである。どうりでファイル生成に1週間も時間がかかったわけだ。しかも、これだけの枚数のプレビューを生成するとファイル容量も膨大である。プレビューだけで元のファイルの3割ぐらいのデータサイズになり、ストレージにも優しいとは言えない。