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

[macklakov]

Цитата:

Сообщение от mazzy

что вы думаете о глобальном кэшировании в Аксапте?

музейный экспонат

Цитата:

Сообщение от mazzy

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

Сначала надо определиться, зачем вообще нужно кэширование?
Я могу предположить что цель это снизить количество обращений клиент-сервер. Тогда:

Цитата:

Сообщение от mazzy

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

Для начала, админам надо дать инструменты управления кэшем. У них должны быть инструменты собирать статистику отправляемых запросов, с точностью до AOS и с точностью до клиента. У них должны быть инструменты упраления кэшем через настройки, без необходимости менять исходники. Опять таки, в разрезе AOS. И у них дожны быть инструменты управления механизмом кэширования. Как минимум, принудительный сброс на выбранных серверах.
Почему в разрезе AOS? Потому что разные сервера обычно занимаются разными задачами. Одному нужна хорошо откэшированная ГК, а другому хорошо откэшированный склад. А не "средняя температура по больнице" как сейчас.
Еще не плохо бы эти настройки сделать экспортируемыми/импортируемыми. Тогда можно будет поднимать "событийные" настройки кэширования. К примеру, на закрытие склада или финансового периода, рассчеты сводного планирования и т.д.
Еще важный вопрос, это синхронизация кэша между серверами. Это отнюдь не тривиальная задача. И если у SQL админа есть куча инструментов по отлову блокировок и избавления от них, то в случае множественных AOS-ов, остается лишь скакать с бубном и приносить девственников в жертву, в попытке умилостивить сереверных духов.

[mazzy]

Цитата:

Сообщение от macklakov

с точностью до AOS и с точностью до клиента.

другими словами, с точностью до сессии?
но тогда получается внутриаксаптовский инструмент типа онлайнпользователей.

внешний инструмент с точностью до компа.
или не?

[macklakov]

Цитата:

Сообщение от mazzy

другими словами, с точностью до сессии?
но тогда получается внутриаксаптовский инструмент типа онлайнпользователей.

Не совсем. Идея в следующем. Часто AOS разделяют по функциям. Этот MRP считает, а этот всякие системные jobs гоняет, на этом сидят пользователи, а этот для интеграции. Делается это для того, чтобы снизить вероятность конкуренции за ресурсы. И пользователи с разными ролями обычно налегат на разные ресурсы. Поэтому хотелось бы управление кэшированием не из кода, а из настроек. Чтобы, собрав статистику, можно было перенастроить кэширование на конкретом AOS. Или для конекретного подмножества пользователей.
Почему это важно? Потому что, согласно опыту последних 6-ти лет, продуктовая команда имеет очень смутное представление о том, что нужно клиентам. И эта размытость образа происходит, опять таки, из-за средней температуры по больнице. Клиенты разные, им нужно разное. Причем хотелки имет свойство изменяться со временем. Разработчик просто не в состоянии определить как лучше будет откэшировать, т.к. он может лишь догадываться о том, какую топологию предпочтет клиент.
А вот админ, сопровождающий конкретного клиента, обычно точно знает где у него узкое место. Где и что надо откэшировать чтобы разгрузить конкретно вот этот канал и эти таблицы в базе данных.

[fed]

Цитата:

Сообщение от macklakov

Не совсем. Идея в следующем. Часто AOS разделяют по функциям. Этот MRP считает, а этот всякие системные jobs гоняет, на этом сидят пользователи, а этот для интеграции. Делается это для того, чтобы снизить вероятность конкуренции за ресурсы. И пользователи с разными ролями обычно налегат на разные ресурсы. Поэтому хотелось бы управление кэшированием не из кода, а из настроек. Чтобы, собрав статистику, можно было перенастроить кэширование на конкретом AOS. Или для конекретного подмножества пользователей.
Почему это важно? Потому что, согласно опыту последних 6-ти лет, продуктовая команда имеет очень смутное представление о том, что нужно клиентам. И эта размытость образа происходит, опять таки, из-за средней температуры по больнице. Клиенты разные, им нужно разное. Причем хотелки имет свойство изменяться со временем. Разработчик просто не в состоянии определить как лучше будет откэшировать, т.к. он может лишь догадываться о том, какую топологию предпочтет клиент.
А вот админ, сопровождающий конкретного клиента, обычно точно знает где у него узкое место. Где и что надо откэшировать чтобы разгрузить конкретно вот этот канал и эти таблицы в базе данных.

Во первых - более или менее кэширутся только настроечные и справочные таблицы. У всех более или менее крупных транзакционных таблиц (типа того же MRP), кэширование либо вообще выключено, либо установлено в NotInTTs (То есть - кэшироваться оно будет не с сервера, а только при просмотре клиентов).
Во вторых - ты не поверишь, но обычный LFU-алгоритм позволяет избавиться от табличных кэшей, которые не особо нужны на данном сервере. То есть - если у тебя нечаянно на MRPшном AOS закэшировались основные средства, то алгоритм LFU бодренько вытеснит эту информацию из памяти и заместит данными из групп покрытия например (в общем - той информацией которая часто и регулярно используется именно на данном конкретном AOS). Я просто не вижу чего тут может дать преднастройка того, какие именно таблицы кэшировать. Мелкие таблицы и так закэшируются, а крупные - скорее всего всерьез кэшировать просто нельзя, потому что они могут с множества разных AOS обновляться в рабочем режиме.

[macklakov]

Цитата:

Сообщение от fed

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

LFU не всегда так бодренько чистит как хотелось бы. Если MRP упирается в лимит по кэшу, то может и заклинить. Но самое главное, я очень не люблю когда мне по работе приходится полагаться на веру. А в случае с объектным кэшем приходится. Я могу лишь догадываться что там происходит. Я тупо не могу узнать, степень заполнения. Понять что система тормозит из-за хронического превышения лимита и что надо этот лимит подкрутить, весьма нетривиально бывает.