caching - 大数据集的 Apollo InMemoryCache 性能策略(React)

Question

从 Apollo 客户端 GraphqQL 查询接收到的初始数据集当前非常大。在“大”中，我的意思是数据似乎在缓存中的“数据”键下规范化为大约 7,000 个条目。有效载荷约为 1.6MB。如果我要保存缓存的数据条目，它会标准化为大约 3MB。我不喜欢初始查询的工作方式，因为我目前正在重新设计他们的应用程序以在图表上使用游标和过滤，而不是客户端获取如此大量的数据并自行过滤。当前的实现无法扩展，因为在其他位置安装此软件时将返回更大的数据集。但是，我正在寻找一种短期解决方案，以便在我承担非常大的重新设计任务时更快地构建此缓存。

*2018 年 7 月 25 日更新** 游标方法不起作用，因为在获取数据的每个页面/游标期间添加更多条目时缓存写入性能会下降。

真正的问题是 IE 11，由于这个浏览器的行业(医疗保健)使用，我们必须支持它，它非常慢。它很难衡量，但在 Apollo 缓存和 react 集成代码方面比 Chrome 慢 8-10 倍。 Chrome 可能需要 1-2 秒才能在这些较慢的虚拟桌面上构建缓存，而 IE 则需要 10-20 秒。

所以，我的问题是:是否有任何性能调整来帮助更快地构建缓存？我附上了一个截图来显示瓶颈所在。它在 chrome 中和 IE 中是一样的，只是在 IE 中慢了一个数量级。我不确定这是否是 IE 的缺点，或者是否是一些可怕的疯狂 polyfill 问题。屏幕截图显示了性能结果中出现的热点。是的，这个屏幕截图是 React 的开发版本，但我们没有看到生产中的任何真正明显的性能提升。屏幕截图实际上只是对图形的调用，最简单的 HTML 表格被渲染了大约 260 行。渲染阶段可以忽略不计。在这个阶段似乎有很多排队的事件或“工作”。也许有办法暂停这个？ Chrome 的分析器显示相同的热点，只是没有那么慢。

无论如何，非常感谢任何建议。

截图列是:函数 |调用次数 |时间(秒)

Answer 1

我们的团队也面临着类似的问题。我们当前的方法是将服务器模式的一部分“非规范化”为 String 类型，该类型包含一个 JSON 字符串。在客户端，我们将解析 Apollo 客户端返回的 JSON 字符串。