如何解决 S3/memcache 延迟问题？
我们的服务器有时会出现严重的延迟问题。
我们在 S3 中存储 3 个感兴趣的内容，并将它们也填充到内存缓存中。
- 用户头像平均 ~25k
- 文本 ~1.5k
- xml ~1.5k
目前我们已经为 memcached 提供了专用的 128meg 内存... 截至目前，它占用了 74 兆的内存，
进行一些基本的数学计算，我们应该能够轻松拥有大约 30,000 个文本文档（及其 xml 表示形式）和 1,000 个用户头像，并且目前仍低于专用于内存缓存的 128 兆
我们拥有大约 100 个可以在任何给定时间调出的用户头像 我们有数十万个 text/xml 文档，但没有人查看它们 就像化身一样......这是这里，那里的一种事情，
有时在白天，用户头像加载速度非常慢（表明它们必须从 s3 加载），而其他时候（当然在加载之后）您可以告诉他们由 memcached 提供服务；与文本文档相同，
我们在 apache phusion 下使用 REE 运行 merb。 我们正在使用基于 libmemcached-0.25.14 构建的 evan weaver 的 memcached gem（我完全理解它不是最新的库；这个 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 下，当它分叉时，共享连接会出现问题，如果我们不关闭连接，它们将继续建立，直到我们用完文件描述符。
我开始密切关注内存缓存，看看是否可以找到我的问题，但有什么建议吗？我们应该摆脱 S3 吗？
We have SERIOUS latency issues SOMETIMES on our server.
We store 3 things of interest in S3 and stuff them into memcache as well.
- User avatars averaging ~25k
- text ~1.5k
- xml ~1.5k
we have dedicated 128meg of ram for memcached as of right now...
as of right now it is riding 74 meg of it
doing some basic math we should easily be able to have around 30,000 text documents (with the xml representation of them) and 1,000 user avatars and still be under our 128meg dedicated to memcache
right now we have ~100 user avatars that could be pulled up at any given time
we have in the hundred thousands of the text/xml documents but they don't get viewed
like the avatars do...it's one here, on there type of thing
sometimes during the day the user avatars load super slowly (indicating they have to be loaded from s3) and other times (after they load of course) you can tell they are being served from memcached; same thing with the text documents
we are running merb under apache phusion with REE.
we are using evan weaver's memcached gem built upon libmemcached-0.25.14 (which I fully understand is not the most up to date lib; this gem requires it)
From what I can see our latency issues are because of S3 which does have serious latency issues (sometimes 500ms for a single avatar). However, it seems that it should not be an issue considering it should be cached all the time. The default expiry on the cache is set to 1 week.
Relevant code is:
@cache = MMCACHE.clone
begin
picture = @cache.get("/avatars/#{user.avatar}")
rescue
picture = user.picture
@cache.set("/avatars/#{user.avatar}", picture)
end
@cache.quit
the cloning/quitting is important since under apache/phusion will have problems sharing the connections when it forks it and if we didn't close out our connections they'd keep building up until we run out of file descriptors.
I'm starting to keep a much closer eye on memcache to see if I can track down my problems but any suggestions?? Should we just get rid of S3??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果我理解正确的话，您将图像文件存储在 S3 支持的 memcached 中。
为什么不直接从 S3 引用图像，而是在它们上设置 Expires HTTP 标头，这样客户端就不会每次都拉取它们，这将有两个优点：
页面加载速度更快，因为浏览器将拉取页面来自多个域的组件。
简化架构。
If I understand this correctly, you're storing image files in memcached backed by S3.
Why not just reference the images directly from S3, but set Expires HTTP headers on them so that they aren't pulled every time by the clients, this would have two advantages:
Pages would load more quickly as browsers would be pulling page components from multiple domains.
Simplification of your architecture.
您可以将 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 无需签订任何合同或每月承诺 – 您只需为通过该服务实际交付的内容付费。
西尔马克
You can use Amazon CloudFront for static resources that will be fetched by client browser (like image, static html, css, javascript). CDN (Content Delivery Network) services eliminates the latency issues for this type of data; below is the description of the service:
Amazon CloudFront is a web service for content delivery. It integrates with other Amazon Web Services to give developers and businesses an easy way to distribute content to end users with low latency, high data transfer speeds, and no commitments.
Amazon CloudFront delivers your content using a global network of edge locations. Requests for your objects are automatically routed to the nearest edge location, so content is delivered with the best possible performance. Amazon CloudFront works seamlessly with Amazon Simple Storage Service (Amazon S3) which durably stores the original, definitive versions of your files. Like other Amazon Web Services, there are no contracts or monthly commitments for using Amazon CloudFront – you pay only for as much or as little content as you actually deliver through the service.
Regards,
Sirmak