10.10.2007, 21:18 | #21 |
Участник
|
|
|
10.10.2007, 23:37 | #22 |
Участник
|
Цитата:
Вы еще не ознаете тот объем работ и количество глюков, которые вы на себя повесили этой задачей. Причем абсолютно добровольно. Причем полностью осознавая, что на больших таблицах любой кэш не спасет. Что ж, удачи. Расскажете о результатах через полгодика? "Задумался" - это хорошо А это не ваш случай, где какой-то чудик отключил режим кэширования EntrieTable на CompanyInfo, InventTTSadmin, Currency и и других параметрических таблицах? И теперь при каждом округлении, при каждой записи складской проводки, при каждом обращении к валютам происходит запрос к базе данных? Вы точно там ищете? А вот так делать не надо. Если есть ответ, скажите всем. |
|
10.10.2007, 23:45 | #23 |
Banned
|
|
|
11.10.2007, 00:13 | #24 |
Участник
|
А... Причем продает в стиле:
|
|
11.10.2007, 10:07 | #25 |
MCT
|
|
|
11.10.2007, 13:16 | #26 |
Участник
|
Маззи, это уже хамство.
Ты общаешься в таком тоне, словно твой собеседник дурак, а ты один умнее всех на свете. Если устал или плохое настроение - не пиши. Тебя же никто не обязывает на все сообщения отвечать. Организация кеша на сервере приложений - это нормально. То что я предложил - фактически повторение уже работающего в Аксапте кеширования курсов валют. Правда на бОльших объемах. Т.е. разработчики приложения посчитали что для нескольких тысяч записей (примерный объем таблицы курсов валют) - стандартный механизм ядра неприемлем, а RecordSortedList - приемлем. Про результаты я уже рассказал. см.выше. От кеширования решил отказаться. Буду отрубать функционал, который так издевается над базой. Кстати, по поводу чудика - в некоторых случаях обращение к базе данных может быть быстрее чем использование кеширования средствами аксапты. см. Книга Inside Microsoft Dynamics 4.0 Chapter 17 Transaction Performance - The EntireTable Cache Pontoppidan пишет про EntireTable Cache, что Цитата:
The database search engines have also evolved over time and are faster than the ones implemented in the Dynamics AX application runtime. It might be faster to let the database search for the records than to set up and use an entire-table cache, even though a database search involves round trips to the database tier.
Я думаю, что критерием выбора может быть только проведение тестирования. В случае таблицы UnitConvert и числа записей около 100 тыс - кеширование мапом или при помощи RecordSortedList - неэффективно. |
|
11.10.2007, 14:28 | #27 |
Участник
|
Сделал проверку на меньших обьемах для RecordSortedList
Для 10 тыс. записей - среднее время порядка 1-2 миллисекунд. Для 5 тыс. примерно 0,5 миллисекунд Для 2 тыс.примерно 0,2 - 0,3 миллисекунды (повторюсь - это среднее время. Реально длительность в большинстве случаев 0, а для некоторых - пики на 15 миллисекунд, просто в зависимости от числа записей - частота пиков разная - отсюда и разное среднее время) |
|
11.10.2007, 14:40 | #28 |
Участник
|
Цитата:
Сообщение от Logger
Организация кеша на сервере приложений - это нормально.
... То что я предложил - фактически повторение уже работающего в Аксапте кеширования курсов валют. Правда на бОльших объемах. Т.е. разработчики приложения посчитали что для нескольких тысяч записей (примерный объем таблицы курсов валют) - стандартный механизм ядра неприемлем, а RecordSortedList - приемлем. Про результаты я уже рассказал. см.выше. Кэширование курсов валют |
|
Теги |
ax3.0, кэширование |
|
|