Кеширование средствами аксапты

[Logger]

Цитата:

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

Нет. Кэширование:
1. забьет сеть трафиком, при котором записи таблицы будут переносится на всех клиентов
2. лишит вас возможности связывать актуальные значения кэша с другими таблицами в SQL-запросах.
3. забьет своп клиентского копьютера (что резко повысит требования к объему памяти клиентского компа)

Нафига вам большая таблица, которую нельзя использовать в SQL-запросах?

1. Сеть трафиком загружена, но ситуация несильно поменятся. Так как фактически я стою перед выбором брать данные из оракла или из кеша сервера приложений. (вопрос в том как его организовать)
2. Некритично. Это таблица UnitConvert она используется в куче мест - очень частое обращение идет. Записи в ней практически не обновляются - только чтение. В общем, полная аналогия с курсами валют ExchRate (только в ExchRate число записей измерялось сотнями - тысячами, а моем случае десятками тысяч).
3. Не понял почему забьет своп клиентской машины ? я ведь кеш хочу организовать не на клиенте а на сервере. Да если бы и на клиенте, то объем его будет порядка 10 мегов. По идее некритично для современных тачек. Другое дело что менеджер памяти Аксапты может с таким объемом не справиться. Но это я буду проверять при тестировании.

Большая таблица мне нафиг не нужна. Ну так просто сложилось, что она есть уже. И к ней идет туча запросов на чтение, а время исполнения бывает по 10-15 милисекунд на один find() - при большом числе запросов становится критичным. Фактически идет куча запросов UnitConvert::find(). Нужно заставить их исполняться быстрее.

P.S.
Интересно вообще понять как реализовать кеширование, а не только для данного случая.
Также непонятно зачем для курсов валют сделали свой кеш на classFactory посредством X++ связка мап и recordSortedList. Видимо стандартное кеширование которое ядро дает - не подошло. А может просто написали и забили, не переделывать же раз уже сделано.

[mazzy]

Цитата:

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

2. Некритично.

как скажете.

кэш на сервере...

[Logger]

Спасибо за ссылки.

Цитата:

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

как скажете.

кэш на сервере...

Сарказм мне непонятен.
Ядро преспокойно организует кеши на сервере. Есть кеш клиентский, есть серверный. Это нормальная практика.

[mazzy]

Цитата:

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

Интересно вообще понять как реализовать кеширование, а не только для данного случая.

BestPractice. Раздел с названием "Using global variables"

Ключевое слово для поиска globalCache:

Цитата:

First get the globalCache variable located on the ClassFactory class:

SysGlobalCache globalCache = classFactory.globalCache();

[mazzy]

См. также
aEremenko: Доступность appl.globalCache() для всех сессий DAX
Кэширование курсов валют
dax-dilettante: 15. System Classes \ The Global Session Classes

[MikeR]

Цитата:

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

Интересно вообще понять как реализовать кеширование, а не только для данного случая.

В случае DAX я читал про это:
Среда исполнения Dynamics AX создает и использует кэш и на клиенте и на сервере. Кэш client-side локален для rich client, а server-side кэш разделяется между всеми соединениями к серверу, включая соединения от rich clients, Web clients, Business Connector, или других соединений.
Кэш использует зависимость уровня (клиент или сервер), на каком ведется поиск. Если поиск ведется на сервере, то используется server-side кеш. Если поиск выполняется с уровня клиента, то клиент сначала просматривает client-side кеш; если ничего не найдено, предпринимается поиск в server-side кэш. Если запись все еще не найдена, то выполняется поиск в базе данных. Когда база данных возвращает record на сервер и на клиента, то record вставляется и в server-side кэш и в client-side кешь.
Кэш реализован с помощью AVL дерева (которое является балансированным binary деревом), но дереву не позволено расти неопределенно. Сlient-side кэш может содержать maximum 100 записей для одной таблицы в компании, а расделенный server-side кеш может содержать maximum 2,000 записей. Когда новая запись вставляется в кэш и достигается максимум, среда исполнения удаляет приблизительно от 5 до 7 процентов старых записей, сканированием целого дерева.

[Logger]

Цитата:

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

Сlient-side кэш может содержать maximum 100 записей для одной таблицы в компании, а расделенный server-side кеш может содержать maximum 2,000 записей.

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

Цитата:

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

Когда новая запись вставляется в кэш и достигается максимум, среда исполнения удаляет приблизительно от 5 до 7 процентов старых записей, сканированием целого дерева.

На этом могут быть большие потери производительности, поэтому стандартное кеширование, которое предоставляет ядро, может в некоторых случаях наоборот замедлить работу (например, когда активно используемые данные не влезают в кеш) .

[MikeR]

Цитата:

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

На этом могут быть большие потери производительности, поэтому стандартное кеширование, которое предоставляет ядро, может в некоторых случаях наоборот замедлить работу (например, когда активно используемые данные не влезают в кеш) .

По всей видимости да
Вот еще цитаты которые полагаю тебе помогут

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

Перед тем как среда исполнения Dynamics AX ищет, вставляет, обновляет или удаляет записи в кэше, тербуется эксклюзивная блокировка, которая снимется, пока операция не закончится. Это означает, что два запущенных процесса на одном и том же сервере не могут выполнять такие операции в кэше в одно и то же время; только один процесс может держать блокировку одно время, и упомянутые процессы блокируются. Блокировка происходит только тогда, когда среда исполнения использует кэш сереверного уровня (server-side cache). Хотя возможности кэширования, поддерживаемые средой исполнения, очень полезная возможность, ими не стоит злоупотреблять. Если вы можете повтороно использовать буфер записи (record buffer), который уже выбран, то лучше использовать его.

[Logger]

Цитата:

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

Это означает, что два запущенных процесса на одном и том же сервере не могут выполнять такие операции в кэше в одно и то же время

Да, это может быть проблемой.
Возможно что и при обращении к глобальным объектам (application, ClassFactory) на сервере произойдет то же самое.

Пока правда не знаю, как можно было бы это проверить

[MikeR]

Цитата:

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

Пока правда не знаю, как можно было бы это проверить

И на это похоже есть ответ

Следующий код X++ показывает, что одина и та же запись выбирается дважды: Вторая выборка использует кэш, даже если использовался первый выбранный буфер записи. При выполнении следующего кода X++ на сервере, процесс может блокироваться, когда среда исполнения ищет кэш.
static void ReuseRecordBuffer(Args _args)
{
CustTable custTable;
;
select custTable
where custTable.AccountNum == '4000';

// Еще код, который не меняет запись the custTable
select custTable //Используется кэш, но
where custTable.AccountNum == '4000'; //может произойти блокировка.
//Используйте повторно record buffer
//вместо этого.
}