Кто использовал "Use roaming user profile to store client-side cache"

[Logger]

Привет всем.

Коллеги, поделитесь опытом использования настройки в конфигурации ax2012 r3
"Use roaming user profile to store client-side cache"
"Path to global client cache file (AUC)"

Судя по документации, при включении опции "Use roaming user profile to store client-side cache"клиент аксапты при старте сперва смотрит в файл "Path to global client cache file (AUC)" и если он есть и новее локального пользовательского auc файла то начитывает кеш из него. Но затем при работе все равно обновляет и использует обычный auc файл из профиля пользователя.


В чем же мы можем получить ускорение от этих настроек ?
Если я все правильно понял, то
1. Если сгенерировать кеш заранее и обновить после обновления приложения, то клиенты аксапты в терминальной ферме возьмут кеш по пути "Path to global client cache file (AUC)". Формы будут открываться быстрее. Но сам мастер auc файл они не обновят. Только начитают. Т.е. он быстро устареет.

2. Не ускорение, но некое удобство. Если обновить дату время создания мастер auc файла "Path to global client cache file (AUC)" прописав там например пустое содержимое, то это приведет к массовому сбросу кешей auc у всех юзеров, что очень удобно. Но ничего не ускоряет. (Этой же цели можно достичь административными способами)

3. Если галка "Use roaming user profile to store client-side cache" не включена то кеши хранятся в папке
c:\Users\UserName\AppData\Local\
если галка взведена то тут
c:\Users\UserName\AppData\Roaming\
В чем может быть выигрыш
нередко админы так настраивают терминальный сервер что в папке
c:\Users\UserName\AppData\Local\
всё очищается при перелогоне. Т.е. теряется выгода от кеширования и добавляются тормоза на открытии больших и сложных форм. Но при этом уходят глюки связанные с просроченными auc файлами.

с папкой
c:\Users\UserName\AppData\Roaming\
очистки обычно не происходит, так что с ней кеширование начинает работать.



В некоторых публикациях
https://community.dynamics.com/ax/b/...-feature-in-r3
https://www.dynamicon.de/en/teilen-v...in-ax-2012-r3/
https://community.dynamics.com/ax/f/...e-cache/773447

утверждают, что можно заставить мастер кеш "Path to global client cache file (AUC)" быть общим для разных юзеров и тем самым получить выигрыш. (Не нужно после каждого обновления приложения обновлять этот кеш руками, все на автомате. Один юзер зашел после обновления аксапты, поработал, кеш обновился, все кто позже зашел, получили выигрыш, не начитывают кеш с аоса, а используют файл).

Так ли это ? Похоже они просто не разобрались как это реально работает. Или я чего-то недопонял ?


А мы можем как-то рулить расположением auc файла ?
Например расположить его не в папке
c:\Users\UserName\AppData\Roaming\
а
c:\Users\UserName\AppData\Roaming\AxAucCache\

[Logger]

На всякий случай уточню как можно это вживую проверить.

Если форма содержит много контролов и датасорсов а датсорсы по табличкам с кучей полей и методов, то при первом открытии формы аксапта делает тысячи запросов на каждый узел, начитывая в кеш определение формы и всего на чем она основана.
В моем примере есть простая форма а-ля SalesTable от ax3.0 (немножко контролов и 4-5 датасорсов). Ее определение затягивается в кеш из базы модели примерно от 15 до 35 секунд (зависит от сервера) в то время как начитка самих данных из датасосров и расчет дисплей методов длится секунды 3 не более.

В стандарте похожим поведением отличаются формы закупок и заказов (но там все намного хуже).
Для того чтобы это увидеть можно настроить для юзера в качестве дефолтной компанию dat (предполагаю, что тогда время связанное с получением данных из бд будет очень маленьким и все время открытия формы займет время начитки из базы модели и раскладывание в памяти аоса и в кешах)

Выйти из аксапты,
удалить auc файлы
зайти снова
померять первое время открытия формы закупок
у меня доходило до 40 секунд.

2-й открытие - несколько секунд всего.

[Logger]

Самое неприятное вот еще в чем.
Сервер БД - быстрый. Хранилище на SSD.
Сеть быстрая. Пинг от терминальника до аоса маленький (один и тот же датацентр)

Но все равно идут медленные открытия форм.
Я хотел сперва оптимизировать запросы к базе моделей.
Померял время, и оказалось что из 17 секунд пока форма затягивалась в кеш из базы моделей, сумма длительности всех тысяч SQL запросов к базе модели была меньше чем 4 секунды. т.е. не более 25 % времени ожидания
Остальное время аос тупил переваривал то, что получил от SQL.

вот тут делал замеры на другой форме
AX 2012 ускорение синхронизации базы в 3-5 раз

схожая картина. Длительность SQL запросов составила 1,5 секунды из 6. Примерно четверть.

Надо тюнить кеширование раз аос такой тормоз.