大数据集的 Apollo InMemoryCache 性能策略 (React)答案

【问题标题】：Apollo InMemoryCache Performance Strategies for Large Data Set (React)大数据集的 Apollo InMemoryCache 性能策略 (React)
【发布时间】：2018-11-10 14:32:13
【问题描述】：

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

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

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

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

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

截图栏目为：function |调用次数 |时间（秒）

【问题讨论】：

标签： caching graphql apollo

【解决方案1】：

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

【讨论】：

这种方法现在对你有什么作用？

【解决方案2】：

Apollo 3.0 将有一个选项来禁用一个类型的缓存规范化： https://www.apollographql.com/docs/react/v3.0-beta/caching/cache-configuration/#disabling-normalization

【讨论】：

【解决方案3】：

我遇到了类似的问题（在 Apollo 客户端 3.3.6 上）。最终，很明显，这么大的集合不适合 Apollo 客户端缓存。我强烈建议您在缓存之外自行管理较大的数据集，而不是让自己承受数秒长的处理（可能就在您加载应用程序时）——本机 js map/filter/etc 更快，并且可能更适合取决于您需要数据的原因。只需通过选项fetchPolicy: 'no-cache'，然后观察您的应用程序显着加速。使用这种处理可能会更好地获取任何大型获取（数千个输入结果）。

【讨论】：