![]() |
#28 |
Moderator
|
Цитата:
Сообщение от macklakov
![]() Не совсем. Идея в следующем. Часто AOS разделяют по функциям. Этот MRP считает, а этот всякие системные jobs гоняет, на этом сидят пользователи, а этот для интеграции. Делается это для того, чтобы снизить вероятность конкуренции за ресурсы. И пользователи с разными ролями обычно налегат на разные ресурсы. Поэтому хотелось бы управление кэшированием не из кода, а из настроек. Чтобы, собрав статистику, можно было перенастроить кэширование на конкретом AOS. Или для конекретного подмножества пользователей.
Почему это важно? Потому что, согласно опыту последних 6-ти лет, продуктовая команда имеет очень смутное представление о том, что нужно клиентам. И эта размытость образа происходит, опять таки, из-за средней температуры по больнице. Клиенты разные, им нужно разное. Причем хотелки имет свойство изменяться со временем. Разработчик просто не в состоянии определить как лучше будет откэшировать, т.к. он может лишь догадываться о том, какую топологию предпочтет клиент. А вот админ, сопровождающий конкретного клиента, обычно точно знает где у него узкое место. Где и что надо откэшировать чтобы разгрузить конкретно вот этот канал и эти таблицы в базе данных. Во вторых - ты не поверишь, но обычный LFU-алгоритм позволяет избавиться от табличных кэшей, которые не особо нужны на данном сервере. То есть - если у тебя нечаянно на MRPшном AOS закэшировались основные средства, то алгоритм LFU бодренько вытеснит эту информацию из памяти и заместит данными из групп покрытия например (в общем - той информацией которая часто и регулярно используется именно на данном конкретном AOS). Я просто не вижу чего тут может дать преднастройка того, какие именно таблицы кэшировать. Мелкие таблицы и так закэшируются, а крупные - скорее всего всерьез кэшировать просто нельзя, потому что они могут с множества разных AOS обновляться в рабочем режиме. Последний раз редактировалось fed; 08.06.2017 в 10:09. |
|
Теги |
sysglobalcache, кэширование |
|
|