![]() |
#1 |
Участник
|
Кеширование средствами аксапты
Уважаемые коллеги, кто делал кеширование таблицы средствами Аксапты ? Какой способ лучше ?
Хочется проверить поможет ли кеширование большой таблицы на АОСе написанное на X++ В руководстве написано что для очень больших таблиц нет смысла использовать кеширование, которое предоставляет ядро. Таблица содержит около 100 тыс. записей. (каждая запись небольшая, скажем используется таблица UnitConvert ) Реально в кеше будет лежать меньше - только последние использовавшиеся, т.е.аналог foundAndEmpty кеширования. Хотелось бы понять имеет смысл вообще пытаться делать кеширование таблицы средствами X++ и если да, то как лучше. Пока идеи такие : 1. RecordSortedList (по аналогии с \Classes\ClassFactory\exchRateCache) (записи хранятся в объекте RecordSortedList) 2. Map (по составному строковому ключу хранятся record-ы) 3. Временная таблица Реально наверно придется делать выбор между вариантом 1 и 2 так как именно при этих вариантах хранимый кеш живет в памяти (не в свопе - так как занимает порядка 10 мегов памяти, а на АОСе памяти достаточно) |
|
![]() |
#2 |
Участник
|
Цитата:
1. забьет сеть трафиком, при котором записи таблицы будут переносится на всех клиентов 2. лишит вас возможности связывать актуальные значения кэша с другими таблицами в SQL-запросах. 3. забьет своп клиентского копьютера (что резко повысит требования к объему памяти клиентского компа) Нафига вам большая таблица, которую нельзя использовать в SQL-запросах? |
|
![]() |
#3 |
Участник
|
Цитата:
Сообщение от mazzy
![]() Нет. Кэширование:
1. забьет сеть трафиком, при котором записи таблицы будут переносится на всех клиентов 2. лишит вас возможности связывать актуальные значения кэша с другими таблицами в SQL-запросах. 3. забьет своп клиентского копьютера (что резко повысит требования к объему памяти клиентского компа) Нафига вам большая таблица, которую нельзя использовать в SQL-запросах? 1. Сеть трафиком загружена, но ситуация несильно поменятся. Так как фактически я стою перед выбором брать данные из оракла или из кеша сервера приложений. (вопрос в том как его организовать) 2. Некритично. Это таблица UnitConvert она используется в куче мест - очень частое обращение идет. Записи в ней практически не обновляются - только чтение. В общем, полная аналогия с курсами валют ExchRate (только в ExchRate число записей измерялось сотнями - тысячами, а моем случае десятками тысяч). 3. Не понял почему забьет своп клиентской машины ? я ведь кеш хочу организовать не на клиенте а на сервере. Да если бы и на клиенте, то объем его будет порядка 10 мегов. По идее некритично для современных тачек. Другое дело что менеджер памяти Аксапты может с таким объемом не справиться. Но это я буду проверять при тестировании. Большая таблица мне нафиг не нужна. Ну так просто сложилось, что она есть уже. И к ней идет туча запросов на чтение, а время исполнения бывает по 10-15 милисекунд на один find() - при большом числе запросов становится критичным. Фактически идет куча запросов UnitConvert::find(). Нужно заставить их исполняться быстрее. P.S. Интересно вообще понять как реализовать кеширование, а не только для данного случая. Также непонятно зачем для курсов валют сделали свой кеш на classFactory посредством X++ связка мап и recordSortedList. Видимо стандартное кеширование которое ядро дает - не подошло. А может просто написали и забили, не переделывать же раз уже сделано. Последний раз редактировалось Logger; 09.10.2007 в 22:26. |
|
![]() |
#4 |
Участник
|
|
|
![]() |
#5 |
Участник
|
Цитата:
Ключевое слово для поиска globalCache: Цитата:
First get the globalCache variable located on the ClassFactory class:
SysGlobalCache globalCache = classFactory.globalCache(); |
|
![]() |
#6 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: Logger (2). |
![]() |
#7 |
Участник
|
|
|
![]() |
#8 |
MCT
|
Цитата:
Среда исполнения 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 процентов старых записей, сканированием целого дерева. |
|
![]() |
#9 |
Участник
|
Цитата:
На этом могут быть большие потери производительности, поэтому стандартное кеширование, которое предоставляет ядро, может в некоторых случаях наоборот замедлить работу (например, когда активно используемые данные не влезают в кеш) . |
|
![]() |
#10 |
MCT
|
Цитата:
Вот еще цитаты которые полагаю тебе помогут Сценарий, который повторяет поиски тех же записей и ожидает найти записи в кэше, может понизить производительность, если кэш постоянно заполнен не только потому, что записи не найдены в кэше, а потому что они были удалены на основе устаревшей схемы, применяющей поиск в базе данных, но так же потому что постоянное сканирование дерева удаляет старые записи. Перед тем как среда исполнения Dynamics AX ищет, вставляет, обновляет или удаляет записи в кэше, тербуется эксклюзивная блокировка, которая снимется, пока операция не закончится. Это означает, что два запущенных процесса на одном и том же сервере не могут выполнять такие операции в кэше в одно и то же время; только один процесс может держать блокировку одно время, и упомянутые процессы блокируются. Блокировка происходит только тогда, когда среда исполнения использует кэш сереверного уровня (server-side cache). Хотя возможности кэширования, поддерживаемые средой исполнения, очень полезная возможность, ими не стоит злоупотреблять. Если вы можете повтороно использовать буфер записи (record buffer), который уже выбран, то лучше использовать его. |
|
|
За это сообщение автора поблагодарили: Logger (2). |
![]() |
#11 |
Участник
|
В общем так.
Сделал проверку. 2 джоба. 1-й кладет в мап по строковому ключу 90 тысяч record-ов. Затем с шагом в 100 перебирает эти записи. (примерно 1000 обращений) Для большинства обращений время - 0 миллисекунд. Для некоторых оно скакнуло до 15 миллисекунд. Но это редко. В среднем на 1000 обращений суммарное время около 250 миллисекунд. т.е. усредненно на одно обращение получается 0,25 миллисекунды. 2-й кладет те же 90 тысяч записей в recordSortedList и таким же образом выбирает. Времена абсолютно те же. Вывод: оба способа по проивзодительности одинаковы. Возможно внутри реазизация у них одна. P.S. Написал и задумался - в приведенных тестах при замере скорости чтения ключ по которому читали - монотонно увеличивался через 100 делений. Это могло повлиять. Нужно сделать случайную выборку. |
|
![]() |
#12 |
Участник
|
Цитата:
Возможно что и при обращении к глобальным объектам (application, ClassFactory) на сервере произойдет то же самое. Пока правда не знаю, как можно было бы это проверить |
|
![]() |
#13 |
MCT
|
И на это похоже есть ответ
![]() Следующий код 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 //вместо этого. } |
|
![]() |
#14 |
Участник
|
Я имел в виду, не блокировку при обращении к кешу ядра Аксапты (на этот счет никаких сомнений нет).
А блокировку при обращениях к глобальным классам на сервере. |
|
![]() |
#15 |
Участник
|
Все плохо
![]() Если сделать не последовательный перебор индекса а случайный, то частота долгих обращений возрастает. Примерно каждоей четвертое обращение длится 15 миллисекунд. т.е. в среднем на таком объеме будет 4,5 миллисекунды. Все. На таким объемах кеширование не спасет. |
|
![]() |
#16 |
MCT
|
|
|
![]() |
#17 |
Участник
|
Может стоит выбрать реализацию smart cache, который бы анализировал и выбирал оптимальную стратегию кэширования
|
|
![]() |
#18 |
Участник
|
|
|
![]() |
#19 |
MCT
|
|
|
![]() |
#20 |
MCT
|
|
|
Теги |
ax3.0, кэширование |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|