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

[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 упирается в лимит по кэшу, то может и заклинить. Но самое главное, я очень не люблю когда мне по работе приходится полагаться на веру. А в случае с объектным кэшем приходится. Я могу лишь догадываться что там происходит. Я тупо не могу узнать, степень заполнения. Понять что система тормозит из-за хронического превышения лимита и что надо этот лимит подкрутить, весьма нетривиально бывает.