All*_*ard 8 amazon-web-services amazon-cloudfront
我们目前在许多边缘位置中使用CloudFront来提供产品图像(接近50万),这些图像会动态调整为不同大小的尺寸.我们的Cloudfront发行版使用原始EC2 php脚本从S3检索原始图像,根据提供的查询字符串条件(宽度,高度,裁剪等)动态转换它,然后将其流回Cloudfront,将其缓存在边缘位置.
但是,第一次加载非缓存图像的网站访问者会受到这种相当大的转换.
我们希望能够"预先缓存"我们的图像(通过使用请求每个图像URL的批处理作业),以便最终用户不是第一个以特定大小拍摄图像的人,等等.
遗憾的是,由于图像仅缓存在分配给预缓存服务的边缘位置上,因此使用其他边缘位置的网站访问者将无法获取缓存图像,并且会在原始服务器上使用大量调整大小脚本进行搜索.
我们唯一能解决的问题是,每个边缘位置都可以在合理的加载时间内检索图像,这是:
我们有一个Cloudfront发行版,指向原始EC2 php脚本.但是,原始脚本不是执行上述图像转换,而是将请求和查询字符串参数转发到另一个Cloudfront分发.该发行版具有原始EC2 php脚本,用于执行图像转换.这样,图像始终缓存在我们的EC2实例(爱尔兰)附近的边缘位置,从而避免在从另一个边缘位置请求图像时执行另一次转换.
因此,例如,瑞典的请求命中/ image/stream/id/12345,瑞典边缘位置没有缓存,因此它向原点发送请求,该请求是爱尔兰的EC2机器.然后,EC2'流媒体'页面从另一个Cloudfront发行版加载/ image/size/id/12345,该发行版访问爱尔兰边缘位置,该位置也没有缓存.然后它再次向原点发送请求,同样是相同的EC2机器,但是向调整大小的'size'页面发送请求.在此之后,瑞典和爱尔兰的边缘位置都缓存了图像.
现在,来自法国的请求请求相同的图像.法国边缘位置没有缓存,所以它称为原点,这是爱尔兰的EC2机器,它称第二个CF发行版再次击中爱尔兰边缘位置.这次它确实缓存了图像,并且可以立即返回.现在,法国边缘位置也可以缓存图像,但无需调用"调整大小"页面 - 只有"爱尔兰"中带有缓存图像的"流媒体"页面.
这也意味着我们在爱尔兰的"预缓存"批量服务可以请求爱尔兰边缘位置,并在我们的网站访问者请求之前预先缓存图像.
我们知道它看起来有点荒谬,但是根据我们的愿望,最终用户在调整图像大小时不应该等待很长时间,这似乎是唯一有形的解决方案.
我们忽略了另一个/更好的解决方案吗？对上述有何评论？
我不确定这会减少加载时间（如果这是您的目标）。
是的，此设置将节省一些“转换时间”，但另一方面，这也会在服务器之间创建额外的通信。
IE客户端调用法国 POP >> 法国 POP 调用爱尔兰 POP = 下载时间（和一些）的两倍，可能比“转换时间”更长...
我在 Incapsula 工作，我们实际上开发了自己独特的行为分析启发式过程来处理动态内容缓存。（此处简要记录：http://www.incapsula.com/the-incapsula-blog/item/414-advanced-caching-dynamic-through-learning）
我们的场地是：
虽然一个网站可以拥有数百万个动态对象，但只有其中一些对象会受到重复请求。
遵循这个逻辑，我们有一个算法，可以学习访问模式，找到缓存的良好“候选者”，然后将它们缓存在冗余服务器上。（从而避免了上述的“双重下载”）
然后，每 5 分钟重新扫描一次内容，以保持新鲜度，并且启发式系统进行跟踪，以确保内容仍然受欢迎。
这是一个过于简单化的解释，但它展示了核心思想，即：找出用户最需要的东西。加入所有 POP。跟踪以保持新鲜度并发现趋势。
希望这可以帮助。