图像缓存策略

Question

场景

我正在构建一个web应用程序，其中可以动态生成报告(基于从SQL数据库中检索到的信息)。这些报告将包含图表，这些图表也可以动态生成。因为这些图表包含敏感信息，所以使用第三方图表API (即: Google Charts)是不可能的。

问题所在

我使用PHP的GD扩展来生成这些图表。这是相当慢的。缓存是可行的，但问题是有大量可能的图表；尽管我相信大多数请求的图表都是以前生成的图表。

部分解

图表由数据和其他信息(大小、图表类型等)生成。因为它们可以唯一地标识一个图表，所以我根据这些信息为每个图表提供一个惟一的散列并保存它。现在，我可以计算新请求的图表的散列，并查看是否已经呈现它。

这样做的问题是发生了冲突。为了解决这个问题，我正在考虑将散列和数据的序列化形式保存在一个SQL表中。然后如果我有一个缓存命中，我仍然会比较数据本身。

我是在过度设计这个吗？(它是一个160位的散列- SHA1)

有没有更好的方法来处理这件事？

Answer 1

我使用PHP扩展来生成这些图表。这是相当慢的。

我怀疑这不是GD，这是缓慢的一点。最有可能的候选者是整理数据的处理(从数据库？)。在这种情况下，您可能会从优化数据库模式和/或使用预先整合的数据中获得显著的好处。

虽然您也可以考虑缓存查询输出，但除非您在其他地方使用相同的数据，否则缓存图形图像可能会更简单。

这样做的问题是发生了冲突。

过早优化--这是不会发生的。但是如果你真的需要的话，拆分你用来生成图形的元数据，并将其存储在一个单独的文件中(同样是通过相同的散列索引)-然后在运行时进行比较。如果你撞车了，我们就请你喝一杯。

我建议你去看看jpgraph --这是一个很棒的软件，它内置了缓存。

结果表明，C.

Answer 2

最有可能的是，如果你的散列数据长度小于160位，你是安全的。否则，如您所说，可能会发生冲突，因此需要比较数据。

Answer 3

看看我们在工作中使用的ChartDirector，它不依赖于GD库，应该会更快。