微风.js缓存限制?或浏览器

Breeze.js cache limitations? Or Browser?

本文关键字:浏览器 js 缓存 微风      更新时间:2023-09-26

我们正在研究使用Breeze进行一些工具的现场部署。 情况是这样的 - 审计员将访问现场的站点,大多数时候没有 - 或者非常降级 - 互联网接入。我们希望使用 Breeze 缓存数据,然后将其存储在本地,以便在没有可用连接时可以访问它,而不是在所有笔记本电脑和平板电脑上复制我们的 SQL 数据库(如果可能的话(。

不幸的是,Breeze 在缓存任何大量数据时似乎会窒息。 通常在Chrome上,它的价值在8到13MB之间(由HTTPResponse标头测量(。 这可能会根据我打开的选项卡数量等而有所变化,但我无法移动超过 10%。 我得到的错误是Chrome标签崩溃并告诉我重新加载。 该错误是可复制的(我以 100K 块下载数据,每次都在同一次读取时失败,如果我在上次读取后停止它,它工作正常(当我更改页面大小时,它总是在同一范围内失败。

这是微风或铬的限制吗?还是窗户? 我在Firefox上尝试过,在整个浏览器崩溃之前,它处理的数据更少。 IE的表现要好一点,但没有一个做得好。

查看任务管理器中的性能,我得到以下结果:

  1. 在缓存过程中,IE 的内存使用量从 250M 增加到 1.7G,在引发内存不足错误之前总共缓存了大约 14MB。
  2. Chrome 的内存使用量从 206B 增加到约 850M,同时缓存总计约 9MB
  3. Firefox从大约400M增加到大约750M,并设法在整个程序崩溃之前缓存约5MB。
我可以计算使用任何

选择标准将下载多少数据,但我找不到一种方法来计算任何特定浏览器实例可以处理多少数据。 这使得使用 Breeze 进行离线审计几乎毫无用处。

还有其他人解决这个问题吗? 处理这样的事情的最佳方法是什么。 我想过几件事,但没有一件是理想的。 任何想法将不胜感激。

应史蒂夫施密特的要求添加:

以下是一些有用的链接:

  • 元数据
  • 实体图 (pdf( (以及 html 和 edmx(

第一个查询(仅用于填充页面上的代码(运行速度快,并下载最少的数据:

var query = breeze.EntityQuery
                .from("Countries")
                .orderBy("Name")
                .expand("Regions.Districts.Seasons, Regions.Districts.Sites");

一旦用户选择了他/她希望缓存的站点,就会启动以下两个查询(以前是一个查询,但我将其分成两个,希望它能减轻资源负担 - 它没有帮助(。 第一个查询(通常为 2-3K 个实体和大约 2MB(按预期运行。 列出的谓词的某种组合用于筛选数据。

var qry = breeze.EntityQuery
                    .from("SeasonClients")
                    .expand("Client,Group.Site,Season,VSeasonClientCredit")
                    .orderBy("DistrictId,SeasonId,GroupId,ClientId")
    var p = breeze.Predicate("District.Region.CountryId", "==", CountryId);
    var p1 = breeze.Predicate("SeasonId", "==", SeasonId);
    var p2 = breeze.Predicate("DistrictId", "==", DistrictId);
    var p3 = breeze.Predicate("Group.Site.SiteId", "in", SiteIds);

第一个查询运行后,第二个查询(如下(运行(也使用列出的谓词的某种组合来筛选数据(。大约 9MB,它将有大约 50K 行可供下载(。 当两个查询之间的总下载负担在 10MB 到 13MB 之间时,浏览器将崩溃。

var qry = breeze.EntityQuery
                    .from("Repayments")
                    .orderBy('SeasonId,ClientId,RepaymentDate');
    var p1 = breeze.Predicate("District.Region.CountryId", "==", CountryId);
    var p2 = breeze.Predicate("SeasonId", "==", SeasonId);
    var p3 = breeze.Predicate("DistrictId", "==", DistrictId);
    var p4 = breeze.Predicate("SiteId", "in", SiteIds);

谢谢你的关注,史蒂夫。 您应该知道,实体关系是继承的,并且当前正在生产中,支持组织的大部分操作,因此最好尽可能少地更改。 此外,希望将其从报告应用程序发展为可以在现场完成数据输入的应用程序(因此,据我了解,使用投影来限制数据是行不通的(。

感谢您的兴趣,如果还有其他需要,请告诉我。

以下是一些建议,这些建议基于我使用 breeze 在支持离线的 Web 应用程序上进行构建的经验。 其中一些或全部可能对您的用例没有意义......

  1. 确定哪些实体类型需要可编辑,哪些用于填充下拉列表等。 使用 noTracking 查询选项加载不可编辑的数据,并使用 JSON.stringify 自行将它们缓存在本地存储中。 这避免了将数据强制转换为实体、更改跟踪等的开销。 模型中此方法的良好候选项可能是国家、地区、地区、站点等实体类型。

  2. 如果可能,请在应用程序中提供一个工具,供用户确定他们想要"脱机"的记录。 这样,您就不需要加载和缓存所有内容,这可能会变得非常昂贵,具体取决于关系,实体,属性等的数量。

  3. 结合建议 #2,避免一次加载所有可编辑数据,并避免使用相同的 EntityManager 实例加载每组数据。 例如,如果 Client 实体需要在没有连接的情况下在字段中进行编辑,请创建新的 EntityManager,加载单个客户端(展开任何也需要可编辑的子客户端(,并将此数据与其他客户端分开缓存。

  4. 缓存一次微风元数据。 调用 exportEntities 时,includeMetadata 参数应为 false。 有关此内容的更多信息,请点击此处。

  5. 若要创建新的 EntityManager 实例,请使用 createEmptyCopy 方法。

编辑:

我想回应这条评论:

假设我有一个客户有账单和付款。该客户端位于 组、站点、区域和国家/地区。你是说 客户、付款和账单信息可能各自有自己的 EM, 而位置层次结构可能位于没有跟踪的第 4 个 EM 中? 然后,当我引用它们时,我会根据需要使用 不同 EM 上的 LINQ(给我客户 A 的所有帐单,给 我为客户 A 支付所有款项(?

决定如何分离事物方面,这有点像判断。 我的一些建议可能是矫枉过正,这实际上取决于数据量和应用程序的使用方式。

假设您不需要在离线时编辑组、站点、地区和国家/地区,我要做的第一件事就是使用 noTracking 选项加载组列表并将它们缓存在 localStorage 中以供离线使用。 然后对站点、地区和国家/地区执行相同的操作。 请记住,使用 noTracking 选项加载的实体不会缓存在实体管理器中,因此您需要获取查询结果,JSON.stringify 它,然后调用 localStorage.setItem。 此处的目的是确保您的应用程序始终有权访问组、站点、区域等的列表,以便在显示用于编辑客户端实体的表单时,您将获得填充组、站点、区域和国家/地区选择/组合框/下拉列表所需的数据。

假设用户已经确定了他们想要在离线时使用的客户子集,那么我将一次加载一个客户端(包括他们的付款和账单信息,但不扩展他们的组、站点、地区、国家/地区(,并使用 entityManager.exportEntities 缓存每个客户端 + 付款 + 账单集。 这里的原因是,每次要编辑特定客户端时,将多个客户端及其付款和账单加载到同一个 EntityManager 中是没有意义的。 这可能是很多不必要的开销,但同样,这是一个判断电话。

@Jeremy的回答非常好,很有帮助,但实际上并没有回答这个问题,我开始认为这是无法回答的,或者至少是错误的问题。 但是,评论中的@Steve为我提供了这个问题最合适的信息。

它既不是微风也不是浏览器,而是淘汰赛。 显然,breeze 实体周围的淘汰包装器使用了所有这些内存(至少在加载实体时和在我的环境中(。 如上所述,Knockout/Breeze在读取大约5MB的数据后会崩溃,导致Chrome崩溃,内存使用量超过1.7GB(下载前内存使用量约为300MB(。 用ANgularJS重写应用程序消除了这个问题。 到目前为止,我已经能够从完全相同的EF6型号下载超过50MB到Breeze/Angular,Chrome内存的总使用量从未超过625MB。

我将测试更大的有效载荷,但 50 MB 足以满足我目前的需求。 感谢大家的帮助。