如何解决我的 S3/memcache 延迟问题？答案

【问题标题】：How do i fix my S3/memcache latency problem?如何解决我的 S3/memcache 延迟问题？
【发布时间】：2010-11-29 14:21:57
【问题描述】：

我们的服务器有时会遇到严重的延迟问题。

我们在 S3 中存储 3 个感兴趣的东西并将它们也填充到 memcache 中。

用户头像平均约 25k
文本 ~1.5k
xml ~1.5k

截至目前，我们已经为 memcached 提供了 128meg 的内存...... 截至目前，它的容量为 74 兆。

做一些基本的数学运算，我们应该很容易拥有大约 30,000 个文本文档（使用它们的 xml 表示）和 1,000 个用户头像，并且仍然在我们专用于 memcache 的 128meg 之下

现在我们有大约 100 个用户头像可以在任何给定时间提取我们有数十万个 text/xml 文档，但它们没有被查看就像化身一样......这是一个在这里，在那里类型的东西

有时用户头像加载速度非常慢（表明他们必须从 s3 加载），而其他时候（当然是在加载之后）你可以知道他们是从 memcached 提供的；与文本文档相同

我们正在使用 REE 在 apache phusion 下运行 merb。我们使用的是基于 libmemcached-0.25.14 构建的 evan weaver 的 memcached gem（我完全理解它不是最新的 lib；这个 gem 需要它）

据我所知，我们的延迟问题是因为 S3 确实存在严重的延迟问题（有时单个头像需要 500 毫秒）。但是，考虑到它应该一直被缓存，它似乎不应该是一个问题。缓存的默认到期时间设置为 1 周。

相关代码为：

@cache = MMCACHE.clone
begin
  picture = @cache.get("/avatars/#{user.avatar}")
rescue
  picture = user.picture
  @cache.set("/avatars/#{user.avatar}", picture)
end
@cache.quit

克隆/退出很重要，因为在 apache/phusion 下，当它分叉时共享连接会出现问题，如果我们不关闭我们的连接，它们会继续建立，直到我们用完文件描述符。

我开始密切关注 memcache，看看我是否可以追踪我的问题，但有什么建议吗？我们应该摆脱 S3 吗？？

【问题讨论】：

您是否希望大大增加应用程序的头像数量和使用率？我问是因为在你目前的水平上，memcached 似乎没有必要。
是的，我们是——是的，我完全同意在这个阶段完全没有必要使用内存缓存

标签： memcached amazon-s3 amazon-ec2

【解决方案1】：

如果我理解正确，您将图像文件存储在由 S3 支持的 memcached 中。

为什么不直接从 S3 引用图像，而是在它们上设置 Expires HTTP 标头，这样它们就不会每次都被客户端拉取，这有两个好处：

页面加载速度会更快，因为浏览器会从多个域中提取页面组件。
简化您的架构。

【讨论】：

【解决方案2】：

您可以将 Amazon CloudFront 用于将由客户端浏览器获取的静态资源（如图像、静态 html、css、javascript）。 CDN（内容交付网络）服务消除了此类数据的延迟问题；以下是服务说明：

Amazon CloudFront 是一种用于内容交付的 Web 服务。它与其他 Amazon Web Services 集成，为开发人员和企业提供了一种以低延迟、高数据传输速度和无承诺的方式向最终用户分发内容的简单方法。 Amazon CloudFront 使用全球边缘站点网络交付您的内容。对您的对象的请求会自动路由到最近的边缘位置，因此以最佳性能交付内容。 Amazon CloudFront 与 Amazon Simple Storage Service (Amazon S3) 无缝协作，后者可持久存储您文件的原始最终版本。与其他 Amazon Web Services 一样，使用 Amazon CloudFront 没有合同或每月承诺 - 您只需为通过该服务实际交付的内容支付多少费用。

问候，西尔马克

【讨论】：