4

Questions

  • Does the user option preload refer to caching on the client or on the server?

  • Are there any ways to make this occur asynchronously so that users don't take a large performance hit when first requesting data from a table?

More Info

In Dynamics Ax 2012, under File > User Options > Preload a user can select which tables are preloaded the first time they're accessed.

I've not found anything to say whether this behaviour relates to caching on the client or the AOS.

  • The fact it's a user setting implies that it's the client.
  • But it could be an AOS setting where users with this option take the initial hit of preloading the entire table, whilst those without would benefit from any caching caused by other users, but wouldn't trigger the load themselves.

If it's the latter we could improve performance by removing this option from all (human) users, leaving it enabled only on our batch user account, having scheduled jobs on each AOS to request a record from each table, thus triggering the preload without any user being negatively impacted.

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

JohnLBevan
  • 22,735
  • 13
  • 96
  • 178
  • 2
    Not an answer, but but maybe some useful information: according to the preload help, preloading is only available for tables with the `EntireTable` CacheLookup property. According to the Inside Microsoft Dynamics AX books, `EntireTable` is a server-side cache only. If the query on such a table starts from the client tier, caching for this table will be handled as a `Found` table cache. – FH-Inway Oct 08 '15 at 14:27
  • 1
    Your link does not work. – Jan B. Kjeldsen Oct 13 '15 at 07:18

1 Answers1

2

If a table is large or frequently changed it is not a candidate for entire table cache. This applies to ordinary users and batch users alike.

The EntireTable cache is located on the server, but the load is initiated by the user, the first user doing the select takes a performance hit.

To succesfully disable a table from preload, you can disable it using the Admin user, it will apply to all users. Or you can let all users disable it by themselves.

Personally I never change the user setup. If a table is large I change the table CacheLookup property as a customization.

See Set-based Caching:

When you set a table's CacheLookup property to EntireTable, all the records in the table are placed in the cache after the first select. This type of caching follows the rules of single record caching. This means that the SELECT statement WHERE clause must include equality tests on all fields of the unique index that is defined in the table's PrimaryIndex property.

The EntireTable cache is located on the server and is shared by all connections to the Application Object Server (AOS). If a select is made on the client tier to a table that is EntireTable cached, it first looks in its own cache and then searches the server-side EntireTable cache.

An EntireTable cache is created for each table for a given company. If you have two selects on the same table for different companies the entire table is cached twice.

Note: Avoid using EntireTable caches for large tables because once the cache size reaches 128 KB the cache is moved from memory to disk. A disk search is much slower than an in-memory search.

Community
  • 1
  • 1
Jan B. Kjeldsen
  • 17,817
  • 5
  • 32
  • 50
  • Thanks Jan; so it relates to caching on the AOS rather than the Client / I should be able to create a batch job to preload these tables ahead of the first user accessing them to avoid an unnecessary performance hit for that user. – JohnLBevan Oct 14 '15 at 09:17
  • It will work if you do it for each AOS, but again your are on the wrong track. If the table contains thousands of records, it should not be `EntireTable` cached (but maybe `Found`). If it contains less the performance hit will be neglectable. Actually, you may reduce performance by filling memory with records not used. – Jan B. Kjeldsen Oct 15 '15 at 06:43