Поговорим о глобальных кэшах в Аксапте? Как правильно?

[mazzy]

Начиная с акс2009 все разработчики стандартного функционала все чаще и чаще используют globalCache для кэширования.

Изначально кэшировался доступ к объектам AOT, к treeNode, Dict*.
Потом все больше стали кэшировать выбранные записи (вместо свойства ChacheTable=EntireTable), теперь кэшируют все подряд.

Для опреденности, напомню, что:

• речь идет о классе SysGlobalCache.
• в Аксапте есть 4 глобальных кэша: Infolog.globalCahce(), Appl..globalCahce(), ClassFactory..globalCahce() серверная и клиентская части
• глобальный кэш основан на dictionary (new Map(types::string, types:class))
• глобальный кэш содержит статическую и волатильную часть
• что нет способа ограничить размер глобального кэша, нет механизма устаревания данных, очистки устаревших данных. есть только сброс волатильной части при помощи flush. При этом сброс вызывается только из двух мест - InventDim и Kanban

что вы думаете о глобальном кэшировании в Аксапте?
как правильно, на ваш взгляд кэшировать, а как неправильно?
что подлежит кэшированию, а что кэшировать ни в коем случае нельзя?
что можно было бы сделать к кэшем в аксапте, чтобы упростить жизнь всех разработчиков, администраторов и пользователей? чтобы снизить вероятность ошибок, связанных с кэшированием?

[EVGL]

https://blogs.msdn.microsoft.com/mfp...tatic-members/

[mazzy]

Quote:

Originally Posted by EVGL

https://blogs.msdn.microsoft.com/mfp...tatic-members/

Я правильно понимаю, что ты не предлагаешь избавиться от кэширования,
а использовать синглтон для хранения кэша объектов и Lazy-инициализацию?

Подход.
Правда только в акс7.
И размазывает катастрофу с кэшами по всему приложению. )

Я скорее о том, что кэши сейчас:

• хранят устаревшие объекты
• имеют чудовищно низких hitRatio
• раздуваются в памяти безо всяких ограничений.

кроме того, кэши сейчас делают на очень низкоуровневые "системные" объекты.
на мой взгляд кэширование уровнем-двумя выше дало бы намного больший эффект.

[Ivanhoe]

За разработчиков не скажу, но консультантам и клиентам любое не прозрачное поведение добавляет много боли. Чем меньше будет бубнов из-за кеша, тем конечным пользователям системы будет комфортнее.

[Vadik]

SysGlobalCache хранит как правило не объекты, а результаты вычислений, которые иначе зафлудили бы БД миллионами мелких запросов. Что куда в семерке размазывается и как SysGlobalCache в принципе (при существующих паттернах его использования) может иметь низкий hit ratio и гды ты его смотришь, решительно непонятно.
Очистка SysGlobalCache - на совести того кто решает его использовать (он должен понимать какие изменения в системе должны этот кэш сбросить).
P.S. вообще есть стойкое ощущение что в исходном сообщении попутаны SysGlobalCache и SysGlobalObjectCache

[trud]

Quote:

Originally Posted by mazzy

Я скорее о том, что кэши сейчас:[*]хранят устаревшие объекты

и еще в копилку - кеши для экстеншенов
-отличный пример как "грамотно" надо использовать кэши
https://ax.help.dynamics.com/en/wiki...runbase-class/
т.е. на классе перед run устанавливается глобальная переменная, далее эта переменная анализируется в методе на таблице(не связанным никак с классом) и если установлена, то считается что этот метод был вызван из класса.
т.е. я так понимаю если очистка в run из-за каких-то причин не сработает, то метод будет все время думать что он вызван из класса. самое грамотное что ошибку никто не сможет повторить можно будет устраивать конкурсы на найди ошибку

[mazzy]

Quote:

Originally Posted by Vadik

Что куда в семерке размазывается и как SysGlobalCache в принципе (при существующих паттернах его использования) может иметь низкий hit ratio и гды ты его смотришь, решительно непонятно.

Именно. Так вопрос и составлен.

Раз автор вопроса такой размазанный и невнятный,
Расскажи как правильно, на твой взгляд? что нужно делать на самом деле и куда смотреть настоящему профессионалу?

Quote:

Originally Posted by Vadik

P.S. вообще есть стойкое ощущение что в исходном сообщении попутаны SysGlobalCache и SysGlobalObjectCache

Прекрасно!!!!
Расскажи подробнее?

Quote:

Originally Posted by trud

можно будет устраивать конкурсы на найди ошибку

)))

[Vadik]

Я уже написал для чего "правильно" надо использовать SysGlobalCache, мое "правильно" и "правильно" от MS в этом случае совпадают

Ты сделал несколько спорных (на мой скромный взгляд) утверждений

• хранят устаревшие объекты
• имеют чудовищно низких hitRatio
• раздуваются в памяти безо всяких ограничений.

Я предлагаю тебе попытаться их обосновать. Попробуешь ?

[dech]

Особое внимание прошу обратить на последний абзац: Best Practices
https://blogs.msdn.microsoft.com/axp...-implications/

[mazzy]

Quote:

Originally Posted by Vadik

Я уже написал для чего "правильно" надо использовать SysGlobalCache, мое "правильно" и "правильно" от MS в этом случае совпадают

Ты сделал несколько спорных (на мой скромный взгляд) утверждений

• хранят устаревшие объекты
• имеют чудовищно низких hitRatio
• раздуваются в памяти безо всяких ограничений.

Я предлагаю тебе попытаться их обосновать. Попробуешь ?

легко.
Берем акс2012, открываем дерево объектов, смотрим перекрестные ссылки.

SysGlobalCache используется используется 1720 раз.
хранит всякую гадость. включая, и Record, и изображения и чего только не хранит.

SysGlobalObjectCache используется 1627 раз.
хранит всякую гадость. включая record.

разница между этими кэшами - будут ли значения видны разным клиентским сессиям. SysGlobalObjectCache - виден между сессиями, а SysGlobalCache "живет" в пределах одной сессии.

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

SysGlobalCache не следят за своим размером.
SysGlobalCache не имеют механизма устаревания данных.
все упомянутые в этой ветке глобальные кэши можно полностью очистить.

на мой взгляд, методика работы с этими кэшами не должна отличаться.
но хорошо что ты сказал про SysGlobalObjectCache.

===========================
про hitRatio и размер пока придется поверить.
или проверить самостоятельно - SysGlobalCache вполне доступен для редактирования. можно добавить измерялки в свой инстанс.

===========================
Итак, вопросы:

что вы думаете о глобальном кэшировании в Аксапте?
как правильно, на ваш взгляд кэшировать, а как неправильно?
что подлежит кэшированию, а что кэшировать ни в коем случае нельзя?
что можно было бы сделать к кэшем в аксапте, чтобы упростить жизнь всех разработчиков, администраторов и пользователей? чтобы снизить вероятность ошибок, связанных с кэшированием?

[mazzy]

Quote:

Originally Posted by dech

Особое внимание прошу обратить на последний абзац: Best Practices
https://blogs.msdn.microsoft.com/axp...-implications/

точно! размер кэша и количество хранимых элементов в SysGlobalObjectCache можно задавать. Ура, товарищи.

Quote:

SGOC is an LRU cache. When the cache is full, the least recently used element will be removed to accommodate newer element. Sizing the SGOC correctly will pay significant performance improvement over poorly sized SGOC setting. The number of elements Global Object cache can hold is defined in Server Configuration form under performance Optimization fast tab

===========================
Итак, вопросы:

что вы думаете о глобальном кэшировании в Аксапте?
как правильно, на ваш взгляд кэшировать, а как неправильно?
что подлежит кэшированию, а что кэшировать ни в коем случае нельзя?
что можно было бы сделать к кэшем в аксапте, чтобы упростить жизнь всех разработчиков, администраторов и пользователей? чтобы снизить вероятность ошибок, связанных с кэшированием?

[imir]

1) Касаемо 12-шки появление global cahe связано в основном с нормализацией БД - там, где раньше уповали в основном на кэширование таблиц - теперь приходится собирать из 3-х, 5-ти таблиц и класть в кэш. Т.е. имеем решение проблемы, созданной самостоятельно.

2) Наличие этих кэшей сильно расслабляет разработчиков core. Я находил метод в разноске покупок, в котором кешировались наследники некого класса, и делалось это полным перебором DictClass ТРИ минуты. Соотв. мы долго искали эти тормоза, которые проявляются раз в неделю на холодном AOS у произвольного пользователя.

3) За все время запила 12-шки ни разу не пришлось прибегнуть к глобальному кешированию самостоятельно. Что говорит о том, что необходимость глобал-кеша - либо признак хреновой архитектуры, либо одно из двух.

[ta_and]

Quote:

Originally Posted by imir

признак хреновой архитектуры

не стал бы так огульно... )

Думаю, что все опытные программисты понимают, что кэш - это зло. И придуман кэш не от хорошей жизни, а потому, что без него с производительностью в некоторых местах была бы совсем труба.

Из этих пониманий (у меня) сложились стойкие убеждения:
1. Кэш нужно использовать только тогда, когда пользователь УЖЕ СТОЛКНУЛСЯ с реальными проблемами в производительности.
2. Кэш можно использовать только для улучшения производительности
3. Использование кэша для решения алгоритмических или архитектурных целей - типа передачи параметров - не просто моветон, а грубейшее нарушение и незнание основ программирования.
4. Кэшировать можно все что угодно, если область видимости и изменяемости этого всего чего угодно абсолютно зафиксирована. (пояснять не хочу, догадайтесь сами о чем это я)
5. Какой механизм выбрать для кэширования - клиент, сервер, тд.. тп.. зависит от решаемой задачи по улучшению производительности и от пункта 4.

вот как то так.

[Владимир Максимов]

Quote:

Originally Posted by ta_and

не стал бы так огульно... )

Думаю, что все опытные программисты понимают, что кэш - это зло. И придуман кэш не от хорошей жизни, а потому, что без него с производительностью в некоторых местах была бы совсем труба.

Проблема в том, что у Axapta довольно высокий "порог вхождения" для новых разработчиков. Причем чем дальше, тем порог все выше и выше. А для новичков глобальные объекты (любые, не только кеш) - это "палочка-выручалочка".

Из этого следует, что опытные-то "знают, как надо", но новички будут использовать к месту и не к месту, поскольку не знают других способов. Или банально нет времени искать. При этом и "опытные" здесь не исключение. Если "сроки горят", то не до красоты. Успеть бы...

Ну, и как результат. Сам факт наличия такого инструмента приведет к тому, что он очень быстро превратиться в глобальную помойку непонятно чего. Что, собственно, и так уже происходит...

[ax_mct]

Quote:

Originally Posted by ta_and

...
кэш - это зло.
...
Кэш нужно использовать только тогда, когда пользователь УЖЕ СТОЛКНУЛСЯ с реальными проблемами в производительности.
...

Точно так. Я тут столкнулся на днях когда коснулся рабочих календарей. Спасибо создателем есть волшебная переменная на отключение кэша. А то задолбался тестировать.

Не нужно кэширование до тех пор пока нет отдельной задачи на улучшение производительности. При первоначальной разработке и тестировании ничего кроме геморроя это не приносит.

Понятно что при разработке некий минимум как табличные индексы, приемлимые join и прочее.
Но так чтобы изначально писать с кэшированием - крайне глупо. Одни проблемы приносит.

[mazzy]

спасибо выступившим.

я бы все-таки предложил сосредоточиться на вопросе: а что можно сделать?

в какой-то момент у меня была идея сделать стоп-лист по ключам кэша.
была идея перехватить set и удалять старое. или что-то вроде сборщика мусора, который работает по таймеру.
но все это как-то кисло.

что можно сделать в текущей ситуации?

[ta_and]

Quote:

Originally Posted by mazzy

что можно сделать

Была такая поговорка у нас:
- Хлам нельзя исправить. Хлам можно только выкинуть и написать заново.

[Logger]

Quote:

Originally Posted by mazzy

я бы все-таки предложил сосредоточиться на вопросе: а что можно сделать?

в какой-то момент у меня была идея сделать стоп-лист по ключам кэша.
была идея перехватить set и удалять старое. или что-то вроде сборщика мусора, который работает по таймеру.
но все это как-то кисло.

что можно сделать в текущей ситуации?

Может быть стоит озвучить хотя бы 5 проблем с которыми столкнулись из-за кеширования и от них отталкиваться уже.
Думаю так будет проще для генерации идей.

[mazzy]

Quote:

Originally Posted by mazzy

SysGlobalCache не следят за своим размером.
SysGlobalCache не имеют механизма устаревания данных.

в результате
= растет используемая память.
= а из-за того, что java-объекты не освобождаются, сборщику мусора все сложнее и сложнее работать.
= эффективность кэша снижается из-за того, что кэш хранит много объектов

вплоть до рекомендации "в профилактических целях периодически перезагружать АОСы"

[belugin]

Quote:

Originally Posted by mazzy

в результате
= растет используемая память.
..."

Как-то было доказано, что это именно из-за SysGlobalCache или это предположение?