aEremenko: Update_RecordSet

[Garic]

Цитата:

Сообщение от mazzy

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

Более правильный код:

.....

Этот код позволяет:
1. отделить запрос и процесс его оптимизации от программирования.
2. позволяет работать с пользовательскими критериями
3. полностью совместим со всей функциональностью форм и отчетов
4. полностью совместим с пакетной обработкой
5. информирует пользователя о ходе выполнения.

Ну зачем же так однозначно
1.) Ваш код замедляет работу из-за множества мелких транзакций.
2.) Визуализация тоже стоит времени - на длительных операциях замечал разницу, если не ошибаюсь, в 30%.

[AlGol]

В работе операций update_recordset есть некоторые ньюансы которые дают сложноотлавливаемые баги.

На одной из версий Аксапты (уже и не помню какой) применение двух последовательных update_recordset давало некорректный результат. Осталось предположение, что отправив запрос на обновление на sqlсервер система продолжила выполнение последующего кода, не дожидаясь полного выполнения запроса. Как результат, следующий update_recordset, использующий результаты предыдущего давал некорректные результаты.

Поборолось обрамлением каждого update_recordset в отдельных ttsbegin/ttscommit. Но осадочек остался...

[Recoilme]

У каждого подхода есть свои плюсы минусы. Можно 30 минут показывать пользователю "градусник", а можно за пару минут выполнить туже операцию, но без градусника.

И каждый метод может дать "неожиданные" результаты, особенно если не понимать как они работают.

Я лишь присоединюсь к первоначальному посту А.Еременко:

Супер!

[mazzy]

Цитата:

Сообщение от Recoilme

Можно 30 минут показывать пользователю "градусник", а можно за пару минут выполнить туже операцию, но без градусника.

Можно пример?

[mazzy]

Цитата:

Сообщение от Garic

Ну зачем же так однозначно
1.) Ваш код замедляет работу из-за множества мелких транзакций.

Я ждал такого замечания. Не ожидал от вас.

Приведенный мной код замедляет работу ТОЛЬКО одного пользователя.
НО приведенный мной код ускоряет работу НЕСКОЛЬКИХ одновременно работающих пользователей. Из-за снижения вероятности блокировок.

За подробностями обращайтесь к совету Еременко.

Цитата:

Сообщение от Garic

2.) Визуализация тоже стоит времени - на длительных операциях замечал разницу, если не ошибаюсь, в 30%.

30% на визуализацию? ужас.
Пользуйтесь стандартным классом SysOperationProgress.
Разберитесь как и когда он обновляется и при каких условиях.

Обсуждение этого класса наверное оффтопик в этой ветке.

[slava]

Цитата:

Сообщение от mazzy

Пользуйтесь стандартным классом SysOperationProgress.

Особенно чудные результаты дает этот класс при работе с несколькими компаниями.

[mazzy]

Цитата:

Сообщение от slava

Особенно чудные результаты дает этот класс при работе с несколькими компаниями.

Для обсуждения прогрессбара создал Какие проблемы у SysOperationProgress?
Здесь давайте вернемся к групповым операциям в Аксапте?

[Garic]

Цитата:

Сообщение от mazzy

Я ждал такого замечания. Не ожидал от вас.

Приведенный мной код замедляет работу ТОЛЬКО одного пользователя.
НО приведенный мной код ускоряет работу НЕСКОЛЬКИХ одновременно работающих пользователей. Из-за снижения вероятности блокировок.

В большинстве случаев нужна одна транзакция - для целостности данных.
Если ожидается что транзакция будет слишком большой что чревато блокировками да и просто тормозит работу, надо стараться разбить её, в многих случаях это возможно.
Можно делать ttscommit/ttsbegin например после каждых 500 строк. Но за маленькие транзакции я бью по рукам

Чтобы не быть голословным - провёл тест (по 5 тестов на каждый вариант) на табличке inventTrans (14 тыс. записей). Добавил в неё текстовое поле 10 - в него пишу timenow.

В случае одной транзакции - 34,8 сек. (100%)
В случае маленьких транзакций с прогрессбаром - 68,3 сек (196%)
В случае маленьких транзакций без прогрессбара - 65,2 сек (187%)

Версия Axapta - 4.0 SP1

Цитата:

Сообщение от mazzy

30% на визуализацию? ужас.
Пользуйтесь стандартным классом SysOperationProgress.
Разберитесь как и когда он обновляется и при каких условиях.

Обсуждение этого класса наверное оффтопик в этой ветке.

Как показал тест, действительно немного он тратит, зря я его так. Хотя может это в четвёрке стало быстрее. Мне запомнилась цифра в 30%, надо бы проверить на трёшке.

[mazzy]

Цитата:

Сообщение от Garic

Можно делать ttscommit/ttsbegin например после каждых 500 строк.

Да, например.

Цитата:

Сообщение от Garic

Но за маленькие транзакции я бью по рукам

А вот это зря.

Цитата:

Сообщение от Garic

Чтобы не быть голословным - провёл тест (по 5 тестов на каждый вариант) на табличке inventTrans (14 тыс. записей). Добавил в неё текстовое поле 10 - в него пишу timenow.

В случае одной транзакции - 34,8 сек. (100%)
В случае маленьких транзакций с прогрессбаром - 68,3 сек (196%)
В случае маленьких транзакций без прогрессбара - 65,2 сек (187%)

Я еще раз повторяю, что вы не тот случай оптимизируете.
Вы оптимизируете работу ОДНОГО пользователя.
Попробуйте запустить хотя бы 10-20, а лучше 50-100 пользователей, которые работают с InventTrans, пишут и читают один и тот же набор данных.
Оцените производительность больших и маленьких транзакций для МНОГОПОЛЬЗОВАТЕЛЬСКОЙ системы.

Про прогресс бар пожалуйста сюда Какие проблемы у SysOperationProgress?
Здесь предлагаю сосредоточиться на больших и маленьких транзакциях, групповых и негрупповых обработках данных.

[mazzy]

Цитата:

Сообщение от Garic

14 тыс. записей

Кстати, 14 тыс - это небольшое число. Все записи, скорее всего, помещаются в кэш сервера.
О влиянии кэша см. http://axapta.mazzy.ru/lib/axapta_itanium/

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

Пожалуйста, не надо из Аксапты делать однопользовательскую ЕРП.
Пожалуйста, тестируйте для многих пользователей.