1
動態內容在一定程度上，我做的非常相似，這篇文章的內容：how to serve dynamic content in playframework 2服務在玩2.X
這是我有一個web應用程序，在這裏客戶可以指定各種參數和我們有玩！服務器啓動一個進程，生成一個自定義圖像文件...然後需要回饋給該客戶端，最好通過Play！
預期的圖像預期壽命可以從幾秒到幾分鐘（甚至幾小時）。從這個角度來看，我們有理由相信嘗試直接用響應發送圖像數據並不是一種可行的方法......而是將URL發送回該動態圖像。
我也非常希望不要依賴一個單獨的HTTP服務器來設置這些動態圖像的各種原因。我相信原因很多，包括但不限於......爲開發人員工作環境和生產服務器維護更簡單的體系結構。我們有一個非常小的/限制的用戶羣，併發用戶很少（我不相信提供這些圖像需要非常高的性能 - 假設Play！可以提供這些動態圖像，我發現很難想象考慮到簡單的權衡，性能不會是完全可以接受的）。
我讀過那個Play！公共/文件夾中的資源被編譯爲.jar文件的構建/編譯時間，這似乎解釋了爲什麼我的動態圖像生成和回送測試不能按預期工作 - 回送的結果始終來自以前的版本。
任何人都可以提出一種服務動態資產的方式而不依賴於另一臺服務器嗎？
1.不要嘗試將靜態資產（在'public /'目錄中）與保存在磁盤上的動態生成的圖像混合使用。這可能最終會導致某人受傷。 2.提供這些圖像的正確方法是在每個請求上生成這些圖像。所以現在我們已經有了一種方法來生成你的響應（圖像），唯一要加速的是緩存。首先：你提到你沒有太多的服務要求。只是在沒有足夠快速緩存的情況下即時生成它們？否則，你能緩存整個圖像嗎？ – Carsten 2013-05-14 18:14:19