【发布时间】：2013-05-14 15:56:15
【问题描述】：
在某种程度上，我正在做与这篇文章非常相似的事情：how to serve dynamic content in playframework 2
也就是说，我有一个网络应用程序，客户端可以在其中指定各种参数，我们有 Play！服务器启动一个生成自定义图像文件的过程......然后需要将其返回给该客户端，最好由 Play！
图像的预期寿命可能从几秒到几分钟（甚至几小时）不等。从这个角度来看，我们有理由相信，尝试将图像数据直接与响应一起发回并不是一种可行的方法……而是将返回一个指向该动态图像的 URL。
出于各种原因，我也非常希望不依赖单独的 HTTP 服务器来提供这些动态图像。我相信原因很多，包括但不限于……为开发人员的工作环境和生产服务器维护一个更简单的架构。我们的用户群非常小/受限，并发用户很少（我不认为提供这些图像需要非常高性能 - 假设 Play! 可以提供这些动态图像，我发现很难想象考虑到简单的权衡，性能不会完全可以接受）。
我读过那部戏剧！ public/ 文件夹中的资产被编译成一个 .jar 文件构建/编译时间，这似乎解释了为什么我的动态图像生成和回送测试没有按预期工作 - 回送的结果总是来自以前的构建。
任何人都可以提出一种无需依赖其他服务器即可返回动态资产的方法吗？
【问题讨论】：
-
1.不要尝试将静态资产（在
public/目录中）与您保存在磁盘上的动态生成的图像混合在一起。那可能只是以某人受伤而告终。 2. 提供这些图像的正确方法是在每次请求时生成它们。所以现在我们已经有了一种方法来生成你的响应（图像），唯一要加快速度的就是缓存。首先：你提到你没有太多的服务请求。只是动态生成它们而没有足够快的缓存吗？否则，你可以只缓存整个图像吗？