Well, I think I have a very basic doubt here:
好吧,我想我在这里有一个非常基本的疑问:
I'm developing an app on GAE (Java) and performing a query to the datastore that returns a lot of entities, so I need to cache it. I was using memcache and it was working great, but if I keep the list of entities in a static variable, the whole request goes as twice as fast than using memcache. I think that's because I'm not deserializing the entities all the time.
我正在开发一个关于GAE(Java)的应用程序,并对返回大量实体的数据存储区执行查询,因此我需要对其进行缓存。我使用的是memcache并且工作得很好,但是如果我将实体列表保存在静态变量中,整个请求的速度是使用memcache的两倍。我认为那是因为我不是一直在反序列化实体。
What would be the drawback of using a static variable instead on memcache? I don't know if there could be several instances of my application in the cloud, and thus several instances of my static variable?
在memcache上使用静态变量会有什么缺点?我不知道我的应用程序在云中是否有多个实例,因此我的静态变量的几个实例?
The list of entities I'm trying to cache are the best (greater score) posts of the last week. I take that list and choose 5 random posts and show them in a couple of pages.
我正在尝试缓存的实体列表是上周的最佳(更高分)帖子。我拿这个列表并选择5个随机帖子并在几页中显示它们。
Thanks for the help!
谢谢您的帮助!
3 个解决方案
#1
App Engine scales by creating new instances of your application as the number of users hitting it increases. As drudru said, different users might be served by different instances. In general, memcache is the fastest place to store something you want to be globally consistent. However, in your case there may be some room for improvement.
App Engine通过创建应用程序的新实例来扩展,因为用户数量会增加。正如drudru所说,不同的用户可能会被不同的实例服务。通常,memcache是存储您希望全局一致的最快的地方。但是,在您的情况下,可能还有一些改进空间。
You mention you have a list of posts and you randomly choose 5 to show to users. Does it matter if 2 different users see a different set of 5? If you're choosing random ones anyway, maybe it doesn't matter. Then you could store the full list of posts in memcache, and pull 5 random ones out of memcache and store them in a static variable.
你提到你有一个帖子列表,你随机选择5向用户显示。如果2个不同的用户看到不同的5个集合,这是否重要?无论如何,如果你选择随机的,也许没关系。然后你可以在memcache中存储完整的帖子列表,并从memcache中拉出5个随机的帖子并将它们存储在一个静态变量中。
Second, what exactly are you memcaching, and how are you pulling it out? Are you storing a whole bunch of full posts in memcache, getting them all, then choosing 5? Maybe you could just download the list of posts, choose 5, and only get the 5 you need? If you think it's the deserializing that's slowing you down, this might help. Are you doing any processing on the posts after you get them? If so, could the results of that processing be cached?
第二,你到底记得什么,你是如何把它拉出来的?你是否在memcache中存储了一大堆完整的帖子,将它们全部存入,然后选择5?也许你可以只下载帖子列表,选择5,只获得你需要的5?如果您认为反向排序会减慢您的速度,那么这可能会有所帮助。你得到它们后,你是否正在对帖子进行任何处理?如果是这样,是否可以缓存该处理的结果?
#2
You cannot rely on static variables (or anything else in JVM memory) to be around when the next request hits, because Google is free to start and stop virtual machines when they feel like it. From the looks of it, they seem to prefer to start additional JVMs instead of additional threads in the same JVM, which compounds this issue.
当下一个请求命中时,您不能依赖静态变量(或JVM内存中的任何其他内容),因为Google可以随时启动和停止虚拟机。从它的外观来看,它们似乎更喜欢在同一个JVM中启动其他JVM而不是其他线程,从而加剧了这个问题。
But, you should be able to use static variables as a cache layer, provided you have a way to load the data from somewhere else if it went away.
但是,您应该能够将静态变量用作缓存层,前提是您可以从其他位置加载数据(如果它已经消失)。
I would also not try to go overboard with memory usage there, there must be a quota on how much memory you can use.
我也不会尝试过度使用内存,必须有一个可以使用多少内存的配额。
#3
Yeah, there is no guarantee that your instance will be the same for various users on the internet. You could end up constantly reading this into a static in the worst case. The memcache has a higher guarantee of being available. I would just use the memcache, and your app should not have any scale issues in the future.
是的,无法保证您的实例对于互联网上的各种用户都是一样的。在最坏的情况下,你最终可能会不断地将其读入静态。内存缓存有更高的可用保证。我只想使用内存缓存,你的应用程序将来不应该有任何扩展问题。
#1
App Engine scales by creating new instances of your application as the number of users hitting it increases. As drudru said, different users might be served by different instances. In general, memcache is the fastest place to store something you want to be globally consistent. However, in your case there may be some room for improvement.
App Engine通过创建应用程序的新实例来扩展,因为用户数量会增加。正如drudru所说,不同的用户可能会被不同的实例服务。通常,memcache是存储您希望全局一致的最快的地方。但是,在您的情况下,可能还有一些改进空间。
You mention you have a list of posts and you randomly choose 5 to show to users. Does it matter if 2 different users see a different set of 5? If you're choosing random ones anyway, maybe it doesn't matter. Then you could store the full list of posts in memcache, and pull 5 random ones out of memcache and store them in a static variable.
你提到你有一个帖子列表,你随机选择5向用户显示。如果2个不同的用户看到不同的5个集合,这是否重要?无论如何,如果你选择随机的,也许没关系。然后你可以在memcache中存储完整的帖子列表,并从memcache中拉出5个随机的帖子并将它们存储在一个静态变量中。
Second, what exactly are you memcaching, and how are you pulling it out? Are you storing a whole bunch of full posts in memcache, getting them all, then choosing 5? Maybe you could just download the list of posts, choose 5, and only get the 5 you need? If you think it's the deserializing that's slowing you down, this might help. Are you doing any processing on the posts after you get them? If so, could the results of that processing be cached?
第二,你到底记得什么,你是如何把它拉出来的?你是否在memcache中存储了一大堆完整的帖子,将它们全部存入,然后选择5?也许你可以只下载帖子列表,选择5,只获得你需要的5?如果您认为反向排序会减慢您的速度,那么这可能会有所帮助。你得到它们后,你是否正在对帖子进行任何处理?如果是这样,是否可以缓存该处理的结果?
#2
You cannot rely on static variables (or anything else in JVM memory) to be around when the next request hits, because Google is free to start and stop virtual machines when they feel like it. From the looks of it, they seem to prefer to start additional JVMs instead of additional threads in the same JVM, which compounds this issue.
当下一个请求命中时,您不能依赖静态变量(或JVM内存中的任何其他内容),因为Google可以随时启动和停止虚拟机。从它的外观来看,它们似乎更喜欢在同一个JVM中启动其他JVM而不是其他线程,从而加剧了这个问题。
But, you should be able to use static variables as a cache layer, provided you have a way to load the data from somewhere else if it went away.
但是,您应该能够将静态变量用作缓存层,前提是您可以从其他位置加载数据(如果它已经消失)。
I would also not try to go overboard with memory usage there, there must be a quota on how much memory you can use.
我也不会尝试过度使用内存,必须有一个可以使用多少内存的配额。
#3
Yeah, there is no guarantee that your instance will be the same for various users on the internet. You could end up constantly reading this into a static in the worst case. The memcache has a higher guarantee of being available. I would just use the memcache, and your app should not have any scale issues in the future.
是的,无法保证您的实例对于互联网上的各种用户都是一样的。在最坏的情况下,你最终可能会不断地将其读入静态。内存缓存有更高的可用保证。我只想使用内存缓存,你的应用程序将来不应该有任何扩展问题。