Хранимые процедуры и производительность

[vey]

Здравствуйте!
Функция «Развертывание» в сводном плане выполняется порядка 28 минут для большого изделия (несколько тысяч составляющих, более 10 уровней вложенности спецификации). Время неприемлемое, разумеется. В алгоритме класса, осуществляющего развертывание (ReqTransExplode) коренных улучшений добиться не удалось; были выбраны требуемые поля в запросах вместо записи целиком, поэкспериментировали с индексами. Основная проблема в том, что суть алгоритма – рекурсивный спуск (или подъем при развертывании вверх) по дереву. А рекурсия никогда особой шустростью не отличалась... В результате для сложного изделия имеем много погружений в рекурсию и множество мелких запросов к БД (таблицы ReqTrans, ReqCalc). Как один из вариантов улучшения ситуации был рассмотрен перенос алгоритма развертывания на SQL-server (написание Stored Procedure). Однако в таком случае алоритм отрабатывает еще медленнее, 4 минуты против 12 секунд в стандартном варианте. С чем это может быть связано? Алгоритм перенесен практически 1:1. Единственное отличие – погружение по дереву реализовано не вширину, а вглубину (соответственно чаще вызывает сама себя ф-ция). Имеются сильные подозрения, что именно в этом дело.:-( Но только ли в этом? Был у кого-нибудь опыт переведения части кода в хранимые процедуры? Насколько хорошо MS SQL server 2000 справляется с рекурсией? Может, возможно повысить скорость отработки хранимой процедуры использованием каких-то ключевых слов, инструкций, параметров и т.д.? Ни за что не стали бы так возиться с развертыванием, однако данный класс используется в очень критичном для клиента алгоритме.

[vey]

извините, сделала опечатку.... таблицы ReqTrans, ReqTransCov

[Logger]

Вынос обработки в хранимую процедуру и не должен был помочь, так как у вас много маленьких запросов к базе, а SQL сервер читает данные страницами по 8 кб. Так что реально объем прочитанных данных очень велик. (Я уже не говрю про время поиска).

Самое надежное в данном случае попробовать изменить алгоритм расчета, так чтобы используемые записи кешировались вами. Например в map-е или во временной таблице.

Как вариант использования map посмотрите
класс расчета себестоимости InventCostItemDim
методы
load()
loadTrans()

[mazzy]

Боюсь советовать не видя базу глазами.

Logger советует в правильном направлении. Надо думать в сторону кэширования. Стоит попробовать изменить режим кэширования у таблицы. Но надо быть очень осторожным.

Программировать надо в последнюю очередь.

[Logger]

http://www.axforum.info/forums/showt...&threadid=8443

[Vadik]

Сейчас крамольную мысль скажу: если уж решили переносить, то точно не 1:1.

С рекурсией вообще надо бы поосторожнее - ее максимальная глубина в сиквеле ограничена, да и не затачивался он под эти цели

С чтением по 8кб позволю себе маленькое уточнение - все-таки чтение осуществляется не страницами, а экстентами (т.е. как минимум 64к). Про время поиска и объем ввода-вывода спорить можно долго, но это не принципиально

С кэшированием согласен на 100%

[vey]

По поводу рекурсии в SQL, но и правда вещь сомнительная, полностью согласна. Кажется, допускается всего 32 уровня вложенности, так что полагаться на то, что этого хватит, опасно, даже если бы прирост производительности был серьезный при переходе на процедуру. :-( Что касается кеширования, то обе таблицы (ReqTrans, ReqTransCov) относятся к типу Transaction. Метод кеширования, соответственно, None...

[vey]

А при отработке развертывания из Ахарта те же запросы, посылаемые к серверу, по-другому считываются и обрабатываются разве (не такими же страницами или экстентами), что получается быстрее?
Не совсем понятен этот момент.:-(
Можно подробней объяснить?

[Logger]

Так в том то и дело, что выносом алгоритма в хранимую процедуру вы нисколько не изменили запросы. Нагрузка на движок базы данных осталась прежней. Вы его на колени поставили...

А если используется кеширование, то тогда многих запросов к базе просто нет. Необходимые данные запоминатся на сервере приложений Аксапты и заново не запрашиваются. За счет этого и ускорение.

[fed]

Как альтернативу включению кэша таблицы или полного переписывания алгортима на использование map, хочу посоветовать почитать системную документацию по классу recordViewCache. Посмотреть на то как это используется можно в классе inventMovement.viewCacheInventTransId. В вашем случае - основные кандидаты на кэширование - reqTrans и reqTransCov. Есь надежда что все это для данного плана в память на сервере влезет.

Правда - я не знаю чего будет происходить если AOS (ну или клиенту) не хватит на кэширование тех 2Гб которые ему Windows может выделить. Памяти на сервер добавлять бесполезно, поскольку 64битного режима у AOS нету, а AWE как, скажем, MS SQL, он не поддерживает.

[vey]

Спасибо за идею, посмотрим; а пока действительно переписали алгоритм развертывания на мар и получили время 10 секунд против прежних почти 30 минут.

[mazzy]

Цитата:

Изначально опубликовано vey
Спасибо за идею, посмотрим; а пока действительно переписали алгоритм развертывания на мар и получили время 10 секунд против прежних почти 30 минут.

Это ровно до тех пор, пока map в память клиента помещается
Как только мап подрастет будет жуткий своп.

Я ведь не ошибся? Вы, наверняка, начали делать обработку мапа на сервере, правда?

[vey]

Получается, не спасет ни использование класса map, ни RecordViewCache, учитывая ограничения на память, и все это лишь временное решение, для сравнительно небольшого объема данных?:-( Очень плохо, конечно. Остаются, значит, только эксперименты с кешированием? Как я уже писала выше, обе таблицы имеют тип "Проводка" (Transaction). Какой тип кеширования может помочь в этом случае?

[mazzy]

Цитата:

Изначально опубликовано vey
Остаются, значит, только эксперименты с кешированием?

Кэширование тоже завязано на объем памяти.

Но помни! В 12 часов твоя карета превратится в тыкву...
Кучер в крысу... Платье - в гряную рвань..
Туфли... А, собственно, что это я? Я же добрый фей... (С) КВН