Dynamics AX 预加载行为答案

【问题标题】：Dynamics AX Preload BehaviourDynamics AX 预加载行为
【发布时间】：2015-10-08 12:16:45
【问题描述】：

问题

用户选项preload是指客户端缓存还是服务器缓存？
是否有任何方法可以使这种情况异步发生，以便用户在首次从表中请求数据时不会受到很大的性能影响？

更多信息

在 Dynamics Ax 2012 中，在 File > User Options > Preload 下，用户可以选择在首次访问时预加载哪些表。

我没有找到任何说明此行为是否与客户端或 AOS 上的缓存有关。

它是用户设置这一事实意味着它是客户端。
但它可能是一个 AOS 设置，其中具有此选项的用户首先会预加载整个表，而没有此选项的用户将受益于其他用户引起的任何缓存，但不会自己触发加载。

如果是后者，我们可以通过从所有（人类）用户中删除此选项来提高性能，仅在我们的批处理用户帐户上启用它，在每个 AOS 上安排作业以从每个表中请求记录，从而触发预加载没有任何用户受到负面影响。

参考：http://dynamicbusinesssolutions.ru/axshared.en/html/9cd36702-2fa7-470c-a627-08

【问题讨论】：

不是答案，但可能是一些有用的信息：根据预加载帮助，预加载仅适用于具有EntireTable CacheLookup 属性的表。根据 Inside Microsoft Dynamics AX 书籍，EntireTable 只是一个服务器端缓存。如果对此类表的查询从客户端层开始，则此表的缓存将作为Found 表缓存处理。
您的链接无效。

标签： performance caching axapta dynamics-ax-2012-r2

【解决方案1】：

如果表很大或经常更改，则它不是整个表缓存的候选者。这适用于普通用户和批量用户。

EntireTable 缓存位于服务器上，但加载是由用户发起的，第一个执行select 的用户会受到性能影响。

要成功禁用预加载表，您可以使用Admin 用户禁用它，它将适用于所有用户。或者您可以让所有用户自行禁用它。

就我个人而言，我从不更改用户设置。如果表很大，我将表 CacheLookup 属性更改为自定义。

See Set-based Caching:

当您将表的 CacheLookup 属性设置为 EntireTable 时，所有表中的记录在第一次选择后被放入缓存中。这种类型的缓存遵循单记录缓存的规则。这表示 SELECT 语句的 WHERE 子句必须包含相等测试表中定义的唯一索引的所有字段 PrimaryIndex 属性。

EntireTable 缓存位于服务器上并由到应用程序对象服务器的所有连接共享（AOS）。如果在客户端层上选择了一个表，该表是 EntireTable 缓存，它首先在自己的缓存中查找，然后搜索服务器端的 EntireTable 缓存。

创建了一个 EntireTable 缓存给定公司的每个表。如果您有两个相同的选择不同公司的表整个表被缓存了两次。

注意：避免对大表使用 EntireTable 缓存，因为一旦缓存大小达到 128 KB 缓存从内存移动到磁盘。磁盘搜索比内存搜索慢得多。

【讨论】：

谢谢一月；所以它与 AOS 上的缓存而不是客户端上的缓存有关/我应该能够创建一个批处理作业来在第一个用户访问它们之前预加载这些表，以避免对该用户造成不必要的性能影响。
如果你为每个 AOS 都这样做，它会起作用，但你又走错了路。如果表包含数千条记录，则不应缓存EntireTable（但可能是Found）。如果它包含较少的性能影响将是可以忽略的。实际上，您可能会通过用未使用的记录填充内存来降低性能。