![]() |
#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. |
|
Теги |
ax3.0, кэширование |
|
|