|
![]() |
#1 |
Участник
|
Поговорим о глобальных кэшах в Аксапте? Как правильно?
Начиная с акс2009 все разработчики стандартного функционала все чаще и чаще используют globalCache для кэширования.
Изначально кэшировался доступ к объектам AOT, к treeNode, Dict*. Потом все больше стали кэшировать выбранные записи (вместо свойства ChacheTable=EntireTable), теперь кэшируют все подряд. Для опреденности, напомню, что:
что вы думаете о глобальном кэшировании в Аксапте? как правильно, на ваш взгляд кэшировать, а как неправильно? что подлежит кэшированию, а что кэшировать ни в коем случае нельзя? что можно было бы сделать к кэшем в аксапте, чтобы упростить жизнь всех разработчиков, администраторов и пользователей? чтобы снизить вероятность ошибок, связанных с кэшированием? |
|
|
За это сообщение автора поблагодарили: alex55 (1), macklakov (5). |
![]() |
#3 |
Участник
|
Я правильно понимаю, что ты не предлагаешь избавиться от кэширования,
а использовать синглтон для хранения кэша объектов и Lazy-инициализацию? Подход. Правда только в акс7. И размазывает катастрофу с кэшами по всему приложению. ) Я скорее о том, что кэши сейчас:
кроме того, кэши сейчас делают на очень низкоуровневые "системные" объекты. на мой взгляд кэширование уровнем-двумя выше дало бы намного больший эффект. |
|
![]() |
#4 |
Участник
|
и еще в копилку - кеши для экстеншенов
-отличный пример как "грамотно" надо использовать кэши https://ax.help.dynamics.com/en/wiki...runbase-class/ т.е. на классе перед run устанавливается глобальная переменная, далее эта переменная анализируется в методе на таблице(не связанным никак с классом) и если установлена, то считается что этот метод был вызван из класса. т.е. я так понимаю если очистка в run из-за каких-то причин не сработает, то метод будет все время думать что он вызван из класса. самое грамотное что ошибку никто не сможет повторить ![]() |
|
![]() |
#5 |
Участник
|
За разработчиков не скажу, но консультантам и клиентам любое не прозрачное поведение добавляет много боли. Чем меньше будет бубнов из-за кеша, тем конечным пользователям системы будет комфортнее.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: mazzy (2), ta_and (3), macklakov (2). |
![]() |
#6 |
Модератор
|
SysGlobalCache хранит как правило не объекты, а результаты вычислений, которые иначе зафлудили бы БД миллионами мелких запросов. Что куда в семерке размазывается и как SysGlobalCache в принципе (при существующих паттернах его использования) может иметь низкий hit ratio и гды ты его смотришь, решительно непонятно.
Очистка SysGlobalCache - на совести того кто решает его использовать (он должен понимать какие изменения в системе должны этот кэш сбросить). P.S. вообще есть стойкое ощущение что в исходном сообщении попутаны SysGlobalCache и SysGlobalObjectCache
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: dech (2). |
![]() |
#7 |
Участник
|
Цитата:
Раз автор вопроса такой размазанный и невнятный, Расскажи как правильно, на твой взгляд? что нужно делать на самом деле и куда смотреть настоящему профессионалу? Цитата:
Расскажи подробнее? ))) |
|
![]() |
#8 |
Модератор
|
Я уже написал для чего "правильно" надо использовать SysGlobalCache, мое "правильно" и "правильно" от MS в этом случае совпадают
Ты сделал несколько спорных (на мой скромный взгляд) утверждений
Я предлагаю тебе попытаться их обосновать. Попробуешь ?
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#9 |
Участник
|
Особое внимание прошу обратить на последний абзац: Best Practices
https://blogs.msdn.microsoft.com/axp...-implications/
__________________
// no comments |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#10 |
Участник
|
Цитата:
Сообщение от dech
![]() Особое внимание прошу обратить на последний абзац: Best Practices
https://blogs.msdn.microsoft.com/axp...-implications/ Цитата:
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
Итак, вопросы: что вы думаете о глобальном кэшировании в Аксапте? как правильно, на ваш взгляд кэшировать, а как неправильно? что подлежит кэшированию, а что кэшировать ни в коем случае нельзя? что можно было бы сделать к кэшем в аксапте, чтобы упростить жизнь всех разработчиков, администраторов и пользователей? чтобы снизить вероятность ошибок, связанных с кэшированием? |
|
![]() |
#11 |
Участник
|
Будем справедливы.
Как отметил Vadik и dech, есть SysGlobalObjectCache. Там есть механизм вытеснения. Но вытесняются только те значения, которые не влезают в отведенные количественные лимиты (число записей, объем памяти) Другое дело, что в текущем коде SysGlobalObjectCache и SysGlobalCache используются поровну. Цитата:
Сообщение от dech
![]() Особое внимание прошу обратить на последний абзац: Best Practices
https://blogs.msdn.microsoft.com/axp...-implications/ |
|
![]() |
#12 |
Участник
|
Цитата:
Сообщение от Vadik
![]() Я уже написал для чего "правильно" надо использовать SysGlobalCache, мое "правильно" и "правильно" от MS в этом случае совпадают
Ты сделал несколько спорных (на мой скромный взгляд) утверждений
Я предлагаю тебе попытаться их обосновать. Попробуешь ? Берем акс2012, открываем дерево объектов, смотрим перекрестные ссылки. SysGlobalCache используется используется 1720 раз. хранит всякую гадость. включая, и Record, и изображения и чего только не хранит. SysGlobalObjectCache используется 1627 раз. хранит всякую гадость. включая record. разница между этими кэшами - будут ли значения видны разным клиентским сессиям. SysGlobalObjectCache - виден между сессиями, а SysGlobalCache "живет" в пределах одной сессии. все упомянутые в этой ветке глобальные кэши не имеют механизма устаревания данных. все упомянутые в этой ветке глобальные кэши можно полностью очистить. SysGlobalCache не следят за своим размером. SysGlobalCache не имеют механизма устаревания данных. все упомянутые в этой ветке глобальные кэши можно полностью очистить. на мой взгляд, методика работы с этими кэшами не должна отличаться. но хорошо что ты сказал про SysGlobalObjectCache. =========================== про hitRatio и размер пока придется поверить. или проверить самостоятельно - SysGlobalCache вполне доступен для редактирования. можно добавить измерялки в свой инстанс. =========================== Итак, вопросы: что вы думаете о глобальном кэшировании в Аксапте? как правильно, на ваш взгляд кэшировать, а как неправильно? что подлежит кэшированию, а что кэшировать ни в коем случае нельзя? что можно было бы сделать к кэшем в аксапте, чтобы упростить жизнь всех разработчиков, администраторов и пользователей? чтобы снизить вероятность ошибок, связанных с кэшированием? Последний раз редактировалось mazzy; 06.06.2017 в 14:21. |
|
![]() |
#13 |
Участник
|
Цитата:
= растет используемая память. = а из-за того, что java-объекты не освобождаются, сборщику мусора все сложнее и сложнее работать. = эффективность кэша снижается из-за того, что кэш хранит много объектов вплоть до рекомендации "в профилактических целях периодически перезагружать АОСы" |
|
![]() |
#14 |
Участник
|
1) Касаемо 12-шки появление global cahe связано в основном с нормализацией БД - там, где раньше уповали в основном на кэширование таблиц - теперь приходится собирать из 3-х, 5-ти таблиц и класть в кэш. Т.е. имеем решение проблемы, созданной самостоятельно.
2) Наличие этих кэшей сильно расслабляет разработчиков core. Я находил метод в разноске покупок, в котором кешировались наследники некого класса, и делалось это полным перебором DictClass ТРИ минуты. Соотв. мы долго искали эти тормоза, которые проявляются раз в неделю на холодном AOS у произвольного пользователя. 3) За все время запила 12-шки ни разу не пришлось прибегнуть к глобальному кешированию самостоятельно. Что говорит о том, что необходимость глобал-кеша - либо признак хреновой архитектуры, либо одно из двух. Последний раз редактировалось imir; 06.06.2017 в 17:28. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#15 |
Участник
|
не стал бы так огульно... )
Думаю, что все опытные программисты понимают, что кэш - это зло. И придуман кэш не от хорошей жизни, а потому, что без него с производительностью в некоторых местах была бы совсем труба. Из этих пониманий (у меня) сложились стойкие убеждения: 1. Кэш нужно использовать только тогда, когда пользователь УЖЕ СТОЛКНУЛСЯ с реальными проблемами в производительности. 2. Кэш можно использовать только для улучшения производительности 3. Использование кэша для решения алгоритмических или архитектурных целей - типа передачи параметров - не просто моветон, а грубейшее нарушение и незнание основ программирования. 4. Кэшировать можно все что угодно, если область видимости и изменяемости этого всего чего угодно абсолютно зафиксирована. (пояснять не хочу, догадайтесь сами о чем это я) 5. Какой механизм выбрать для кэширования - клиент, сервер, тд.. тп.. зависит от решаемой задачи по улучшению производительности и от пункта 4. вот как то так. |
|
|
За это сообщение автора поблагодарили: mazzy (2), Ivanhoe (2). |
![]() |
#16 |
Участник
|
Цитата:
Из этого следует, что опытные-то "знают, как надо", но новички будут использовать к месту и не к месту, поскольку не знают других способов. Или банально нет времени искать. При этом и "опытные" здесь не исключение. Если "сроки горят", то не до красоты. Успеть бы... Ну, и как результат. Сам факт наличия такого инструмента приведет к тому, что он очень быстро превратиться в глобальную помойку непонятно чего. Что, собственно, и так уже происходит...
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Ivanhoe (2). |
![]() |
#17 |
Banned
|
Цитата:
Не нужно кэширование до тех пор пока нет отдельной задачи на улучшение производительности. При первоначальной разработке и тестировании ничего кроме геморроя это не приносит. Понятно что при разработке некий минимум как табличные индексы, приемлимые join и прочее. Но так чтобы изначально писать с кэшированием - крайне глупо. Одни проблемы приносит. |
|
|
За это сообщение автора поблагодарили: Ivanhoe (2). |
![]() |
#18 |
Участник
|
спасибо выступившим.
я бы все-таки предложил сосредоточиться на вопросе: а что можно сделать? в какой-то момент у меня была идея сделать стоп-лист по ключам кэша. была идея перехватить set и удалять старое. или что-то вроде сборщика мусора, который работает по таймеру. но все это как-то кисло. что можно сделать в текущей ситуации? Последний раз редактировалось mazzy; 06.06.2017 в 19:46. |
|
![]() |
#19 |
Участник
|
|
|
![]() |
#20 |
Участник
|
Цитата:
Сообщение от mazzy
![]() я бы все-таки предложил сосредоточиться на вопросе: а что можно сделать?
в какой-то момент у меня была идея сделать стоп-лист по ключам кэша. была идея перехватить set и удалять старое. или что-то вроде сборщика мусора, который работает по таймеру. но все это как-то кисло. что можно сделать в текущей ситуации? Думаю так будет проще для генерации идей. |
|
Теги |
sysglobalcache, кэширование |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|