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

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