Показать сообщение отдельно
Старый 08.06.2017, 09:54   #39  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,892 / 5650 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от macklakov Посмотреть сообщение
Не совсем. Идея в следующем. Часто AOS разделяют по функциям. Этот MRP считает, а этот всякие системные jobs гоняет, на этом сидят пользователи, а этот для интеграции. Делается это для того, чтобы снизить вероятность конкуренции за ресурсы. И пользователи с разными ролями обычно налегат на разные ресурсы. Поэтому хотелось бы управление кэшированием не из кода, а из настроек. Чтобы, собрав статистику, можно было перенастроить кэширование на конкретом AOS. Или для конекретного подмножества пользователей.
Почему это важно? Потому что, согласно опыту последних 6-ти лет, продуктовая команда имеет очень смутное представление о том, что нужно клиентам. И эта размытость образа происходит, опять таки, из-за средней температуры по больнице. Клиенты разные, им нужно разное. Причем хотелки имет свойство изменяться со временем. Разработчик просто не в состоянии определить как лучше будет откэшировать, т.к. он может лишь догадываться о том, какую топологию предпочтет клиент.
А вот админ, сопровождающий конкретного клиента, обычно точно знает где у него узкое место. Где и что надо откэшировать чтобы разгрузить конкретно вот этот канал и эти таблицы в базе данных.
Во первых - более или менее кэширутся только настроечные и справочные таблицы. У всех более или менее крупных транзакционных таблиц (типа того же MRP), кэширование либо вообще выключено, либо установлено в NotInTTs (То есть - кэшироваться оно будет не с сервера, а только при просмотре клиентов).
Во вторых - ты не поверишь, но обычный LFU-алгоритм позволяет избавиться от табличных кэшей, которые не особо нужны на данном сервере. То есть - если у тебя нечаянно на MRPшном AOS закэшировались основные средства, то алгоритм LFU бодренько вытеснит эту информацию из памяти и заместит данными из групп покрытия например (в общем - той информацией которая часто и регулярно используется именно на данном конкретном AOS). Я просто не вижу чего тут может дать преднастройка того, какие именно таблицы кэшировать. Мелкие таблицы и так закэшируются, а крупные - скорее всего всерьез кэшировать просто нельзя, потому что они могут с множества разных AOS обновляться в рабочем режиме.

Последний раз редактировалось fed; 08.06.2017 в 10:09.