-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uploadsフォルダが、掲載画像の数倍に肥大化する傾向 #1457
Comments
ファイルクリーンアップができれば少しは軽くなるかなぁ。 |
Filesプラグインで一律自動生成してるのをやめて、各プラグインで必用なサイズだけ作成するように変更してもいいのかも。 |
多分、大半の画像はウィジウィグでアップロードした画像かなぁ。 NC2の時だと、ウィジウィグのアップロード時にサイズ決めたら、それ以後の編集では実画像サイズの変更不可でしたね。 デメリットは、既に上げた画像も実画像サイズの変更不可なるとこかなぁ。 |
NC2は1サイズだけ残す仕様だったのかぁ 最終的にはディスクスペースと利便性のどっちをとるかって話になりそうですね^^; |
ファイルクリーンアップ、完成しました。 |
複数のNC3サイトをバックアップしていて気づきましたが、app/Uploads/のディスク消費量が予想外に大きいんですね。450MBとか104MBとかで、画像を数百枚載せたんかというくらいの驚きでした。まだ運用開始して半年も経ってないのに、2, 3年先にはどうなってしまうのかととても心配です。
そこで少し調べて見ました。先にわかったことをまとめると、
(1) 一枚の画像掲載により、サイズの異なる画像が新たに5枚作成される。
(2)PNGは肥大化した不要画像が生成されがち。
例: 125kBのPNG画像を掲載すると、319kB, 140kB, 92kB, 25kB, 7kBの計583kBの画像が追加される。
この例の様子を末尾の画像で示しておきます。
(3)使われなくなった画像も肥大化されたまま残されている。
これらにより、Uploadsフォルダに関し次のような不具合と心配があります。
(1) バックアップに時間がかかる
→ 運用半年程度のサイトでも10数分かかることもある。
(2) バックアップ中は、同一サーバで運用している別サイトの反応が極端に遅くなる。
→ 既に発生しています。
(3) バックアップファイルの保管先の確保は大丈夫だろうか。
→ 何GBものUploadsフォルダを多数個保存し続ける必要が出てくる。世代管理まではできそうにない。
(4) 画像の掲載ルールが必要で、運用が面倒になる。
→ 安易に画像を掲載してはいけない。「最終調整画像を最終の場所に1回だけ載せる」という運用ルールが必要かなと。でないと不要画像でUploadsフォルダがあふれかえってしまう。
以上に鑑みて、改善策を講じていただけるとありがたいです。
The text was updated successfully, but these errors were encountered: