目前我們的網站存儲2/3固定圖像大小。這些都是在上傳時生成的，並通過我們的CDN分發。但是，我們需要實施更靈活的解決方案，我們開發的手機和平板電腦應用需要多種不同的尺寸。我們提出的解決方案是創建一個PHP腳本，它可以接受圖像標識符（id/type/url等）和大小限制。然後腳本可以即時創建映像並在下次緩存它。PHP動態圖像調整大小（動態）
這是一個可行的解決方案？
此刻，CDN屏蔽了我們的Web服務器，使其承受了相當大的負載。無論如何，只要圖像生成一次，就可以將CDN融入到這個過程中？我能想到的唯一方法就是讓腳本向圖像資源返回一個URL，但客戶端需要創建2個HTTP請求。重定向可能會更快，但對速度來說這不是一個壞習慣嗎？
我們剛剛做了類似的事情。用戶上傳文件。對文件的任何版本的任何請求都會經過一個腳本，該腳本檢查圖像是否已經生成，並生成它或以其他方式提供。這裏有一些開銷，但到目前爲止我沒有問題。然後，腳本將文件排隊發送到我們的CDN（我們的案例中的S3），並且一旦發送更新本地引用，所以下一次使用CDN的引用呈現頁面。重定向是你絕對想避免的。
如果您的服務器安裝了Imagik，因爲大部分都是按標準安裝的。 Imagik實際上支持它，只是要建立一個功能來做到這一點，對不起，這不是很有幫助，但我過去曾經使用它。
這種系統被認爲是更多的讀取然後寫入。
爲了讓您的系統運行得更快，您應該儘可能多地預處理以降低較大部分（讀取）的性能影響，即使它增加了較小部分的性能影響（寫入）。
從這個意義上說，您應該確定所需的尺寸，並在上傳時（即上傳之後）創建這些調整大小的圖像。
有沒有數十億有效尺寸，大多數智能手機/平板電腦都落入其中，但最終有幾個可能的解決方案，預處理沒有辦法變得比即時慢 - 全面的用戶體驗下來的東西。
再次，不要被愚弄，任何時間只是A_LOT_SLOWER，因爲你有isincache檢查，創建部分，然後只有返回。
EVERY_SINGLE_IMG_REQUEST將包含緩存檢查，有些會在重要的時間（讀取）不必要地變慢，而不必在不重要的時間吃掉幾個cpu週期（iE產生永遠不會看到的圖像） ）。
我會列出可以生成的有效尺寸;否則，這樣的系統容易遭受拒絕服務攻擊，其在每次大小的迭代中都快速請求圖像。即使對於最大尺寸爲100x100的單個圖像，也有10,000個可能的迭代，每個迭代可以單獨請求和生成，而不受限制，消耗時間，內存和磁盤空間。 – 2011-04-15 08:24:08
爲什麼您不要求CDN提供文件的緩存版本，請求的文件大小已滿，如果不存在，請創建一個新文件，將其存儲以供將來使用並將其返回給客戶端？我的意思是這對我來說是一個可行的解決方案，並且是服務器負載方面最好的解決方案。 – 2011-04-15 08:25:08
因此，PHP腳本服務於CDN，但如果它不存在，請創建並返回映像（並緩存到CDN）？ – Gcoop 2011-04-15 08:28:11