事实证明,检索存储内存缓存的低级数据存储实体非常缓慢.由于objectify将实体缓存为低级数据存储区实体类型,因此当使用objectify从memcache中获取许多实体时,这会导致性能不佳.
真正的问题是为什么从memcache反序列化实体类型的速度慢?我整理了一个示例项目来演示从memcache与普通字符串或简单Map中检索实体的差异.
这是代码:
此外,我部署了它,因此您可以看到它在生产中有多大差异:aleemsandbox.appspot.com/perftest.它是一个天真的探测器,但它确实表现出巨大的性能差异.刷新页面几次以查看差异.这是一些示例输出:
Storing String Data Test
-------------------------
generateData: 0ms
storeData: 10ms
fetchData: 9ms
Storing Map Data Test
-------------------------
generateData: 0ms
storeData: 21ms
fetchData: 92ms
Storing Entity Data Test
-------------------------
generateData: 69ms
storeData: 24ms
fetchData: 792ms
第一部分显示了在memcache中存储1000个字符串然后立即获取它所需的时间.下一个示例对1000个Map对象执行相同操作,最后一个示例存储并检索1000个低级实体类型.您可以看到检索实体类型的时间增加.
任何想法为什么实体可能很慢从memcache反序列化?
更新1
根据其中一个答案中的建议,我还记录了存储在memcache中的对象的累积大小,结果没有打印出来.我还添加了另一个测试用例 – 而不是直接存储实体,而是首先将Entity序列化为byte [],然后将其存储在memcache中.结果如下:
StringBenchmark
----------------
Average Fetch Time: 40.16ms
Fetch Size: 24.41KB
MapBenchmark
----------------
Average Fetch Time: 27.36ms
Fetch Size: 102.54KB
EntityBenchmark
----------------
Average Fetch Time: 1029.88ms
Fetch Size: 463.87KB
EntityPreSerializedBenchmark
----------------
Average Fetch Time: 218.82ms
Fetch Size: 490.23KB
这里有趣的是最后两个结果.尽管它们的大小大致相同,但手动获取和反序列化byte []需要大约1/5的时间.
github repo中的代码已更新,部署的示例应用程序也有最新代码,因此可以随意在此处运行此测试并查看结果.