针对大数据集的阿波罗InMemoryCache性能策略(React)

Question

对于我正在尝试调优的应用程序，从Apollo客户端GraphqQL查询收到的初始数据集目前非常大。在“大”中，我的意思是似乎数据规范化到缓存中" data“关键字下的大约7,000个条目。有效负载大约为1.6MB。如果我要保存缓存的数据条目，它将被规范化到大约3MB。我不喜欢初始查询是如何工作的，因为我目前正在重新设计他们的应用程序，以便在图形上使用游标和过滤，而不是客户端获取如此大量的数据和过滤本身。当前实施无法扩展，因为在其他位置安装此软件时将返回更大的数据集。但是，我正在寻找一个短期的解决方案，使这个缓存建立得更快，同时我承担了非常大的重新设计任务。

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

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

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

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

屏幕截图列为:函数|调用计数|时间(秒)

​

​

Answer 1

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

Answer 2

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

Answer 3

我遇到了类似的问题(在Apollo client 3.3.6上)。最终，很明显，这么大的集合不适合Apollo客户端缓存。我强烈建议你在缓存之外自己管理更大的数据集，而不是让自己背上长达数秒的处理(可能就在你加载应用程序的时候)-原生js map/filter/etc速度更快，可能更适合你，这取决于你为什么需要数据。只需传递选项fetchPolicy: 'no-cache'，就可以看到你的应用程序的速度显著提高。任何大的fetch (数千个键入的结果)可能更适合使用这种处理方法。