gpt4 book ai didi

javascript - Breeze.js 缓存限制?还是浏览器?

转载 作者:行者123 更新时间:2023-11-28 15:31:25 25 4
gpt4 key购买 nike

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

不幸的是,当缓存大量数据时,Breeze 似乎会卡住。一般来说,在 Chrome 上,实体的大小在 8 到 13MB 之间(通过 HTTPResponse header 测量)。这可能会根据我打开的选项卡数量等而发生一些变化,但我无法移动超过 10%。我收到的错误是 Chrome 选项卡崩溃并告诉我重新加载。该错误是可复制的(我以 100K block 下载数据,每次读取时都会失败,如果我在上次读取后停止它,则工作正常)当我更改页面大小时,它总是在同一范围内失败。

这是 Breeze 或 Chrome 的限制吗?还是 window ?我在 Firefox 上尝试过,在整个浏览器崩溃之前它处理的数据甚至更少。 IE 的表现稍好一些,但没有一个做得很好。

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

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

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

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

根据 Steve Schmitt 的要求添加:

以下是一些有用的链接:

第一个查询,只是为了填充页面上的标签,运行速度很快并下载最少的数据:

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 将它们缓存在 localStorage 中。这避免了将数据强制转换为实体、更改跟踪等的开销。模型中这种方法的良好候选者可能是国家/地区、地区、地区、站点等实体类型。

  2. 如果可能,请在您的应用程序中提供一种工具,以便用户识别他们想要“离线”的记录。这样您就不需要加载和缓存所有内容,根据关系、实体、属性等的数量,这可能会变得相当昂贵。

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

  4. 缓存 Breeze 元数据一次。调用exportEntities时includeMetadata 参数应该为 false。有关此的更多信息 here .

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

编辑:

我想回复此评论:

Say I have a client who has bills and payments. That client is in a group, in a site, in a region, in a country. Are you saying that the client, payment, and bill information might each have their own EM, while the location hierarchy might be in a 4th EM with no-tracking? Then when I refer to them, I wire up the relationships as needed using LINQs on the different EMs (give me all the bills for customer A, give me all the payments for customer A)?

在决定如何区分事物时,这有点需要判断。我建议的一些建议可能有点过头了,这实际上取决于数据量和应用程序的使用方式。

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

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

关于javascript - Breeze.js 缓存限制?还是浏览器?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27231698/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com