Search code examples
performancecachingaxaptadynamics-ax-2012-r2

Dynamics AX Preload Behaviour

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

Solution

  • 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.