如何在社交网络环境中使用memcache?

时间:2012-10-25 04:00:35

标签: google-app-engine webserver memcached

我知道这是一个非常模糊的问题,但我正在寻找一个非常抽象的答案。自从几个月前我开始使用GAE以来,我总是对memcache不屑一顾,因为它没有用,也是一种麻烦的麻烦,它真的不那么重要了。但似乎memcache被认为是一个非常有益的功能,谷歌甚至说“高性能可扩展的Web应用程序经常在某些任务的前面或代替强大的持久存储使用分布式内存数据缓存。”等等我认为必须有一些值得关注的事情。

我只是不明白。它对性能有何益处?首先,您必须检查内存中是否有内容,如果没有,请查询。我一直认为没有必要处理这个问题会更快,而且无论如何只是查询,但似乎这可能是一个天真的方法?这有多大差异?

我想我从未理解的内容是memcache有用的地方。我可以看到它在Stackoverflow主页中是多么有用,其中所有用户几乎都看到相同的东西,所以它会很有用,实际上很难在这种情况下不使用memcache。但是像Facebook这样的社交网络。每个用户看到不同的东西。没有两个人看到相同的数据和内容,并且事情变化如此之快以至于memcache可能不断需要更新。 memcache在这种情况下可以扮演什么角色?

此外,在像社交网络这样的私人网站中,如果每个用户都必须在memcache中存储不同的信息,那么memcache真正适合多少?我知道GAE没有谈到其内存缓存的大小,那么存储数十万条记录是否安全?

2 个答案:

答案 0 :(得分:7)

您可以将memcache用于经常需要的内容。检查内存是否在memcache中是快速。从memcache获取它是快速。如果您可以节省自己不得不进行查询,则可以节省大量时间。

例如,请考虑以下两种情况:

  • 两个人请求您的主页。这两个请求都是作为页面加载的一部分进行查询。
  • 两个人请求您的主页。两者都检查缓存;一个查询并存储它,另一个获取缓存结果。

Ballpark从memcache(或存储它)获取内容的时间大约为2-3ms。从球场获取内容的球场时间是100毫秒。

因此,对于第一种情况,您有100毫秒x2 =总共200毫秒。

在第二种情况下,您有3ms(查找失败)+ 100ms(查询)+ 3ms(存储)+ 3ms(成功查找)=总共109ms。

你的整体节省了近50%。

现在考虑可能有10个人请求您的主页。第一个场景中的每个额外的人将是另一个100ms。第二种情况中的每个人只有3毫秒。


另请注意,您不必一次在memcache中存储整个页面。您也可以存储部分页面。当然,并非所有用户都拥有相同的数据,但肯定会有一些东西在他们之间共享。

答案 1 :(得分:1)

<强>尺寸

您无法依赖内存缓存的大小。已经有各种尝试来确定每个应用程序有多少数据,结果各不相同。

<强>可靠性

它不可靠。你的memcache条目&#39;生命周期与一组黑盒子(用户)值相关,例如他们请求的频率以及自上次请求以来已经过了多长时间。

Google会尝试保留经常使用的条目,并会随机(从您的角度)将其从memcache中删除。

<强>提示

尝试在所有人共享或经常请求的项目上使用它,或者计算成本很高。好的例子是用户实体,因为只加载了用户,他们可能不止一次与您的应用互动。另一个可能是您放置用户特定数据的模板,如果只有一小部分数据会发生变化,则可能是整页。对于Facebook来说,它可能是整个模板,例如&#34;这些朋友正在聊天&#34;,公司范围的部分,例如&#34;你可能想尝试这个游戏&#34;,或者一个新帖子,将被推送给许多目前在线的朋友。

为每种类型的实体使用不同的缓存期。通过设置一个实体的到期日期比另一个更短,提示最有用的App Engine。缓存页面可能仅在30秒内有用,用户条目可能在一小时内有用。

这是一种有限的资源,Google将针对所有客户的利益优化多个客户/应用程序。如果你的应用程序没有受到攻击而另一个需要更多内存缓存,那么Google推出你的memcached条目是合理的。