Cantaloupe IIIF画像サーバーのパフォーマンスチューニング
AWS EC2上で運用しているCantaloupe IIIF画像サーバーで、初回タイルアクセスに8.8秒かかっていたため、いくつかのチューニングを行いました。最終的に0.84秒まで改善できたので、その過程を記録します。 環境 AWS EC2 (us-east-1), CPU 2コア, メモリ 7.6GB Cantaloupe: islandora/cantaloupe:6.3.12（最終的なバージョン） ソース: S3Source フロントエンド: Traefik（Let’s Encrypt TLS終端） テスト画像: 46825×28127px の大判TIFファイル ボトルネック分析 初期状態を調べると、以下の状況でした。 項目 状況 JVMヒープ上限 512MB（コンテナメモリ2GBに対して少なめ） FilesystemCache 386MB / 13,950ファイル（稼働中） キャッシュボリューム 未永続化（docker-compose.ymlで起動していたため再起動ごとに消失） ソース画像形式 strip形式TIF（1タイル取得にS3から9チャンク×約2MBの読み込みが必要） 特にソース画像の形式が問題で、strip形式TIFはIIIFのタイル配信に適していません。1タイルを返すために画像全体の広範囲をS3から読み込む必要がありました。 施策1: ピラミッドタイルTIFF変換 効果が最も大きかった施策です。libvipsのtiffsaveでピラミッドタイルTIFFに変換しました。 vips tiffsave input.tif output.tif --tile --pyramid --tile-width 256 --tile-height 256 --compression jpeg --Q 85 変換後のファイルサイズは219MB（Q85、ピラミッド付きタイルTIFF）。元のstrip TIFと比較すると、タイル単位でのランダムアクセスが可能になり、S3からの読み込みチャンク数が大幅に減りました。 変換前後の比較: 指標 変換前 (strip TIF) 変換後 (ptif Q85) 初回タイル (cold) 8.8秒 0.7〜1.3秒 2回目タイル (cold, 別領域) 1.7秒 0.7秒 キャッシュ済みタイル 0.04秒 0.01秒 S3チャンク読み込み 9回 少数 画像処理時間 1073ms 510ms 施策2: JVMヒープ増加 コンテナメモリ上限2GBに対してデフォルトヒープが512MBだったため、1536MBに増やしました。 ...