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

[Logger]

Уважаемые коллеги, кто делал кеширование таблицы средствами Аксапты ? Какой способ лучше ?

Хочется проверить поможет ли кеширование большой таблицы на АОСе написанное на X++

В руководстве написано что для очень больших таблиц нет смысла использовать кеширование, которое предоставляет ядро.

Таблица содержит около 100 тыс. записей. (каждая запись небольшая, скажем используется таблица UnitConvert ) Реально в кеше будет лежать меньше - только последние использовавшиеся, т.е.аналог foundAndEmpty кеширования.

Хотелось бы понять имеет смысл вообще пытаться делать кеширование таблицы средствами X++ и если да, то как лучше.

Пока идеи такие :
1. RecordSortedList (по аналогии с \Classes\ClassFactory\exchRateCache) (записи хранятся в объекте RecordSortedList)
2. Map (по составному строковому ключу хранятся record-ы)
3. Временная таблица

Реально наверно придется делать выбор между вариантом 1 и 2 так как именно при этих вариантах хранимый кеш живет в памяти (не в свопе - так как занимает порядка 10 мегов памяти, а на АОСе памяти достаточно)

[mazzy]

Цитата:

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

Хотелось бы понять имеет смысл вообще пытаться делать кеширование таблицы средствами X++ и если да, то как лучше.

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

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

[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. Некритично.

как скажете.

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

[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

[Logger]

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

Цитата:

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

как скажете.

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

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

[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]

В общем так.

Сделал проверку.
2 джоба.

1-й кладет в мап по строковому ключу 90 тысяч record-ов. Затем с шагом в 100 перебирает эти записи. (примерно 1000 обращений) Для большинства обращений время - 0 миллисекунд. Для некоторых оно скакнуло до 15 миллисекунд. Но это редко. В среднем на 1000 обращений суммарное время около 250 миллисекунд. т.е. усредненно на одно обращение получается 0,25 миллисекунды.

2-й кладет те же 90 тысяч записей в recordSortedList и таким же образом выбирает. Времена абсолютно те же.

Вывод: оба способа по проивзодительности одинаковы. Возможно внутри реазизация у них одна.

P.S. Написал и задумался - в приведенных тестах при замере скорости чтения ключ по которому читали - монотонно увеличивался через 100 делений. Это могло повлиять. Нужно сделать случайную выборку.

[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
//вместо этого.
}

[Logger]

Я имел в виду, не блокировку при обращении к кешу ядра Аксапты (на этот счет никаких сомнений нет).

А блокировку при обращениях к глобальным классам на сервере.

[Logger]

Все плохо

Если сделать не последовательный перебор индекса а случайный, то частота долгих обращений возрастает. Примерно каждоей четвертое обращение длится 15 миллисекунд.

т.е. в среднем на таком объеме будет 4,5 миллисекунды.

Все.
На таким объемах кеширование не спасет.

[MikeR]

Цитата:

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

Все.
На таким объемах кеширование не спасет.

на больших таблицах кэш не рулит

[Diman]

Цитата:

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

Все плохо

Если сделать не последовательный перебор индекса а случайный, то частота долгих обращений возрастает. Примерно каждоей четвертое обращение длится 15 миллисекунд.

т.е. в среднем на таком объеме будет 4,5 миллисекунды.

Все.
На таким объемах кеширование не спасет.

Может стоит выбрать реализацию smart cache, который бы анализировал и выбирал оптимальную стратегию кэширования

[Logger]

Цитата:

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

Может стоит выбрать реализацию smart cache, который бы анализировал и выбирал оптимальную стратегию кэширования

А что вы под этим подразумеваете ?

[MikeR]

Цитата:

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

Может стоит выбрать реализацию smart cache, который бы анализировал и выбирал оптимальную стратегию кэширования

И примерчик не помешал бы

[MikeR]

Видно

Цитата:

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

smart cache,

так и останется загадкой