автор статьи:
Виктор Болбат (Enot)
Источник hare.ru
Итак, перед нами стоит задача оптимизации проведения документов при групповом проведении (в более широком смысле при автоматическом проведении нескольких документов сразу).
Действия, производимые при проведении документа, можно условно (как мне сейчас удобно) разбить на следующие части (которых может и не быть в реальных документах):
- Установка периодических реквизитов справочника.
- Запись бухгалтерских проводок. Напомню, что при этом происходит не только запись в журнал проводок, но и обновляются бухгалтерские итоги (далее БИ).
- Запись движений регистров. Как и в случае с проводками, дополнительно обновляются итоги.
- Запись записей журнала расчетов (по данной части я не имею глубоких познаний и поэтому далее рассматривать не буду).
- Выполнение запросов для получения данных по оборотам и остаткам БИ.
- Выполнение запросов для получения данных по оборотам и остаткам регистров.
- Запись данных, за исключением предыдущих пунктов.
- Чтение, анализ данных.
Для оптимизации любой записи данных (в том числе и движений документа) можно воспользоваться механизмом транзакций. Для этого перед стартом групповой обработки выполняется команда
Эффект такой оптимизации получается очень значительный, производительность может вырасти в разы.
Есть и недостаток если документов проводиться очень много (или данных много), то буфер, в котором накапливаются изменения, сам становиться узким местом (деталей внутренней организации транзакций я не знаю, но на практике это выглядит именно так). Оптимальной является следующая тактика: разбить всю массу документов на пакеты (количество документов в пакете подбирается экспериментально, исходя из обЪёма данных, хранимых в документе) и проведение каждого пакета оформляется в виде транзакции.
Запись проводок (непосредственно запись в журнал проводок) оптимизировать не получится (за исключением использования транзакций). А вот обновление итогов запросто. Принцип очень простой. Попробуйте записать проводки в большую базу данных вначале с датой, на пару лет раньше текущей (при этом идет обновление итогов за пару лет), а потом с текущей датой. И посмотрите на производительность.
Возможно несколько вариантов оптимизации:
- Можно установить бухгалтерские итоги на начало всех времен. При этом обновление их происходить не будет. Максимальная скорость записи проводок. Но этот метод можно использовать только в специфических случаях, т.к. в процессе проведения часто (как правило) возникает необходимость получения данных БИ. Этот способ рекомендуется для документов, которые не обращаются БИ в модулях проведения.
-
Можно воспользоваться методом
Актуальность() обЪектаБухгалтерскиеИтоги (можно подсмотреть реализацию в обработке "ОбработкаДокументов"). Смысл в том, что обЪектБухгалтерскиеИтоги будет поддерживать БИ в актуальном состоянии при проведении документов. При обновлении БИ, данные будут браться из обЪектаБухгалтерскиеИтоги ,/tt> (здесь я не уверен, а если точнее не помню, сказывается ли это на скорости записи проводок, или нет). - И, наконец, можно воспользоваться встроенным механизмом "Проведение документов". При этом БИ рассчитываются на момент проведения документа, а расчёт итогов "на после документа" не производится (система рассчитывает промежуточные итоги на начало проведения документа, после проведения эти данные обновляются и используются далее, и только в конце периода они записываются в базу). Это самый лучший вариант.
Запросы r БИ при проведении документов, как правило, выполняются на дату документа (вернее, на "начало" документа). Например, чтобы рассчитать цену, исходя из текущих остатков. Для оптимизации скорости выполнения именно таких запросов (если запрос выполняется на произвольную дату, то ничего сделать не получится) можно воспользоваться рассмотренными выше методами: использование встроенного механизма "Проведение документов" или метода
Кроме того, если используется метод
Оптимизация запросов к итогам регистров похожа на оптимизацию запросов к БИ. Если документ двигает ТА, то можно сразу же обращаться к итогам. Это проверяется точно так же, функцией
Подведем итог. Что нужно в модулях проведения:
- Для оптимизации записи движений никаких действий предпринимать не надо.
- Для получения итогов регистров необходимо выбирать остатки или выполнять запросы на ТА. Перед этим всегда нужно проверять актуальность итогов.
- Для получения БИ в случае выполнения запроса (в том числе при помощи обЪекта БухгалтерскиеИтоги) никаких действий предпринимать не надо. В случае прямого обращения к БИ без запроса, нужно предварительно проверять необходимость выполнения расчета (актуальность итогов).
- Встроенным механизмом "ПроведенияДокументов". Это самый оптимальный и универсальный вариант.
- Дополнительной обработкой с использованием транзакций и проведением пакетами. Например, "ОбработкаДокументов" НЕ в монопольном режиме (именно в этом режиме включаются транзакции в данной обработке). В некоторых случаях (незначительное использование регистров и проводок, отсутствие обращений к итогам) получается значительный выигрыш по сравнению с предыдущим методом.
- Дополнительной обработкой, которая поддерживает итоги в актуальном состоянии с проведением документов. Например, "ОбработкаДокументов" В монопольном режиме (именно в этом режиме поддерживаются актуальными итоги). Работает медленнее первого варианта (хотя, существуют случаи, когда быстрее, из-за оптимизации БИ по счетам), но незначительно.
- Дополнительной обработкой, которая использует п.2 и п.3. В обработке "ОбработкаДокументов" одновременно эти методы не используются. Почему, я не знаю. Практическая проверка показывает, что всё работает нормально. Но, на всякий случай, используйте этот метод с осторожностью.
Начать дискуссию