java memcached 存储对象_java – 从Memcache中获取低级别数据存储区实体对象时的慢速反序列化...

事实证明,检索存储内存缓存的低级数据存储实体非常缓慢.由于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中的代码已更新,部署的示例应用程序也有最新代码,因此可以随意在此处运行此测试并查看结果.