存儲多個尺寸的圖像或只存儲主要和調整大小？

Question

我正在開發一個CMS，我試圖找出做REST樣式圖像請求的常見做法。我有三種尺寸，小，中和全。我的想法是隻存儲完整的內容並編寫一個函數，以調整每個頁面請求的大小。這有明顯的CPU成本。另一方面是我可以存儲所有三種尺寸，並且只能在上傳時計算，這似乎浪費了空間。

我的環境是一個內聯網，所以存儲的請求相對較低，圖像數量較多。思考？

注意：我意識到我不必擔心太多，因爲它是Intranet，任何解決方案都可以工作，只是想知道哪些方面會更好。

Answer 1

另一種選擇是保持縮放後的圖像的緩存。提供可用的那些。如果它們不可用，請創建新的。刪除一段時間未請求的圖像。

這將是CPU和存儲問題之間的妥協。

Answer 2

存滿，然後根據需要生成其他大小並緩存它們;在第一次請求時，頁面處理速度會稍微減慢，但隨後緩存版本將用於所有後續請求。

Answer 3

由於您認爲會存儲很多圖片而且請求數量並不多，因此我會選擇使用動態調整大小的解決方案，因爲它聽起來像是您已知道的存儲空間將是更大的問題。

如果你想獲得幻想，你可以建立一個MRU（最近使用）ñ - 大多數常用請求縮放後的圖像的緩存，但同樣的，如果請求的數量較少，這將可能是矯枉過正 - 但仍然可能是一個有趣的項目！ ;）

Answer 4

REST的一個關鍵點和標準HTTP動詞的用法是它支持緩存;我認爲這將支持動態調整大小的意圖。不過，這實際上是存儲空間與請求時間計算之間折衷的問題。

Answer 5

如果系統負載不是問題（假設一個低容量的intranet應用程序），我會去存儲全尺寸圖像並在運行時縮放它。這樣，如果您需要其他尺寸，則不需要替換所有圖像。

但你如上所述，瞭解權衡，使系統的負載，磁盤空間的需求變化似然等一些好的估計

Answer 6

你自己回答了這個問題，這是一個CPU空間折衷。 你知道每條路徑的成本，只問自己，哪個資源對你來說成本更高。

Answer 7

我們對真實世界的Web應用程序使用實時調整大小的概念。 檢查這個鏈接： http://test.bizbnk.com/ResizedImage/From/Content/Images/Ads/ad_201d1aa49015a2cc9cca1866630b02bf.png,Size=256X256 所有的性能測試都是成功的。 你只需要真正關心良好的緩存（運行時，服務器和客戶端）。 祝你好運。