О влиянии транзакций на скорость модификации информации в 1С #126781

Предыстория тут и тут и тут Напомню, что вопрос мой был такой: "У меня сложелось впечатление, что многие пользуют транзакции для увеличения скорости. Кто мне объяснит, как и почему транзакция увеличивает скорость (если я правильно понял)."По совету Макс 1С и по привычке никому не верить на слово написал-таки 2 теста. Тестировалось на v.7.7-SQL ТиС ред. 936 (почти не тронутая, только установлен МОД и прописаны его процедуры). MS SQL server 2000 на отдельном серваке. В 1-м тесте: а) в цикле создается 10000 элементов справочника ОКЕИ и записываются без использования механизма транзакций; б) в цикле же без использования транзакций удаляются эти элементы; в) точно такая же процедура создания и записи 10000 элементов справочника ОКЕИ с использованием транзакций в которых по 200 штук создаются/записываются элементы справочника; г) процедура удаления созданных и записанных элементов этого справочника по 200 шт. на 1 транзакцию.Результаты:г) 103,84 сек.Т.о. прирост скорости при массовом создании записи документов с использованием механизма транзакций по операций создания/записи элементов справочника составил 31%, а при массовом удалении элементов - 53%.Тест второй: а) отменялось проведение приблизительно 990 доков (за выбранный интервал времени), все доки образуют ненарушенную последовательность без использования механизма транзакций; б) за этот же период времени "распроведенные" доки проводились без использования механизма транзакций; в) повторят процедуру распроведения документов (а), но с использованием транзакций по 200 доков на транзакцию; г) провдение доков как в (б), но с использованием механизма транзакций по 200 доков на транзакцию.Результаты:а) 47;в) 41;Г) 454.Т.е. разницы в скорости массовой "отмены проведения документов" и "проводки документов" с использованием и без использования транзаций я не обнаружил.Код тестов по требованию готов предоставить. Кто-нибудь прокомментирует?

монопольно?

монопольно

Учимся грамотно составлять тесты...На данную тему было подробное обсуждение на www.sql.ru

Ты б ссылку кинул, и лучше без менторского тона.

Проводить документы, использующие неявное открытие транзакции, в рамках тразакции? Мощно.

А теперь те же тесты на файловой версии :)

Блин, ты по ссылкам ходил? Я ж говорю, неоднократно вижу что в целях повышения производительности пытаются использовать транзакции. Я спросил почему. Мне сказали, что этот вопрос неоднократно на территории обсуждался, и вроде как установли, что производительность повышается. Рекомендовали проверить, что я и сделал. Вон и МуМу что-то обмолвился об обсуждении этой темы на sql.ru, но уточнять ссылку скромно не стал. Результаты налицо. Не к теме разговора, но кстати, ничего не слышал о сложенных транзакциях?

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

>> само по себе использование транзакций при проведении/распроведении документов лишено смыслаНе согласен, ибо существуют ситуации, когда еэто необходимо. Но, не для ускорения массовых операций с документами.Что касается операций со справочниками (удаление), то разница отличается на 30-50%, не так уж и значительно, не правда ли?

На файловой - лениво.

ну мы же горим о приросте скорости.... использование транзакций вне документов - ни коим образом не способствует увеличению скорости, согласен?, а даже наоборот увеличивает её за счет не нужных действий....а использование транзакций именно в контексте непосредственного применения транзакций, т.е. для сохранения целостности данных при проведении группы документов, скорее всего себя не оправдает (щас проверять некогда, завтра может получится) но боюсь что внешняя транзакция не отменит внутреннюю...про справочники 30-50% - это очень значительно...... представь тебе предложат повысить з/п на 30-50%... ты считаешь этого мало?

В плане скорости основной эффект от транзакций при записи/удалении данных - в возможности заменить много мелких операций с диском - одной большой. И будет очень хорошо, если эта операция будет как можно менее фрагментированной.Если в это вдуматься, то становится понятным, почему во втором эксперименте ты не получил результата (точнее говоря - получил, но незначительный). А результата ты не получил потому что при проведении/распроведении документа задним числом основное время тратится на расчет/обновление временных итогов регистров/бухитогов.Для того, чтобы увидеть эффект от транзакции при проведении документов - необходимо проводить документы со сдвигом ТА.Для того, чтобы увидеть эффект от транзакции при распроведении документов - необходимо установить ТА на самый первый распроводимый документ, распровести документы, поставить ТА обратно.. "получается транзакция в транзакции - вывод: много лишних, не нужных транзакций... это аксиома"Посылка верная - вывод неверный. "Лишних" (правильнее сказать - "дополнительных") транзакций получается не так и много, и они оказываются очень даже нужными. Скорость-то увеличивается.

По моим наблюдениям на файловой версии в локальном режиме объединение десяти .Записать в одну транзакцию уменьшает время записи в 2-3 раза. Соответственно 100 .Записать в транзакции уменьшит время в 4-9 раз и так далее. Однако тут главное не переборщить, и не раздуть транзакцию до размеров оперативной памяти, ибо тогда из-за своппинга начнется обратный процесс. Внешняя транзакция никак не может отменить внутреннюю. При всем желании - она этого сделать не сможет. Чтобы понять - почему - достаточно 10 секунд подумать.А вот внутренняя транзакция с успехом отменяет внешнюю.

>> боюсь что внешняя транзакция не отменит внутреннююОтменит.>> а использование транзакций именно в контексте непосредственного применения транзакций, т.е. для сохранения целостности данных при проведении группы документов, скорее всего себя не оправдаетНичего не понял.>> использование транзакций вне документов - ни коим образом не способствует увеличению скорости, согласен?Тест показывает, что как раз несколько увеличивает скорость записи/удаления элементов *справочника*. А при проведении *документов* в условиях данного теста изменения скорости практически не отмечалось.

А встроенная обработка проведения документов ("Операции" - "проведение документов") тоже транзакции использует? Если к.-л. документ не провелся, остаются непроведенными предыдущие((( Я раньше считала, что до этого документа все проводится. В групповой обработке документов от режима зависит, а во встроенной?

>> Внешняя транзакция никак не может отменить внутреннюю... А вот внутренняя транзакция с успехом отменяет внешнюю.Согласен, в предыдущем посте поторопился.

думать не охота, вечер уже.... заватра будет время подумаю, сэмулирую и продолжим.... >> Ничего не понял. -о как завернул ;-)... короче пример 100 доков проводим в транзакции на 20 ошибка, что будет ни один не проведен? или 19 проведены? я завтра проверю, но в данном случае использовании транзакции именно по прямому назначению, т.е. для сохранения целостности данных....>> использование транзакций вне документов - ни коим образом не способствует увеличению скорости, согласен?имелось ввиду не для справочников, а проведение N документов в одной транзакции, т.е. кк бы ВНЕ документов, не в смысле что не с документами, а в смысле что над документами чтоли....зы. завтра, все завтра....

Спи, дорогой товарищ. И не баламуть своим сумеречным сознанием наше кристально чистое знание.

спи спи... тут еще студенту 1С объяснять часа на 2..... :-(...зы. хр.хр.хр.хр......

я именно поэтому и написал.На сиквельной версии прирост скорости чаще всего невелик.(11, 17) для целостности работает. То есть при ошибке ппроведения транзакция не фиксируется с сообщением "Ошибка при фиксации транзакции" или схожим.

в возможности заменить много мелких операций с диском - одной большой. И будет очень хорошо, если эта операция будет как можно менее фрагментированной.Согласен, но... если ошибка в одной единственной операции - и все будут отменены. Думаю, что не всегда это хорошо.

>> По моим наблюдениям на файловой версии в локальном режиме объединение десяти .Записать в одну транзакцию уменьшает время записи в 2-3 раза...Такие выводы хорошо делать на массовых операциях и желательно повторять тест достаточно большое количество раз. Но, ты, я думаю, именно так и делал.

> если ошибка в одной единственной операции - и все будут отменены.> Думаю, что не всегда это хорошо.это чаще хорошо, чем плохо :)

Для случая, когда было плохо:Когда надо было сделать перепроведение большого числа документов,при чем чтобы перепроведение не останавливалось на сбойном,пришлось делать конструкцию типавсе документы в список значенийТА на перый докНачатьТранзакциюУспешно = 0;цикл по списку  Если документ в списке непроводимых тогда   продолжить    добавить док в список непроводимых    сместить счетчик цикла на последний успешно проведенный    сдвинуить ТА на последний успешный.зафиксироватьЗаписать лог по списку непроводимых.

Не все, а последние 1-300 в зависимости от размера транзакции и от везения. Иногда это бывает неприятно, но в моем опыте еще ни разу не было фатальным. Я именно так и делал, причем повторял тесты на разном железе/релизах/версиях ОС/конфигурациях в общей сложности на протяжении пяти лет как минимум.

Несколько видоизменил тест в соответствие с рекомендациями в . Проводился тест в *разделенном режиме*, но с отсутствием других пользователей в базе, с проведением документов за определенный промежуток времени, располагающихся последовательно,с предварительной установкой точки актуальности на последний непроведенный документ перед массовым проведением. Т.е. видоизменный тест 2(б - без использования транзакций и г - с использованием).Резульаты:б) 228 сек;г) 208 сек.Итого прирост производительности на 9,6% с использованием транзакций.

так, ну вот и я. я так понял ты опыты делаешь работаешь на сКУЛе?

Да, база в скуль положена.

у меня ДБФ.... собственно вопрос со скоростью оставлю на твоем фронте...меня больше интересует проведение доков во внешней транзакции....что сделал:отменил проведение доков, в модуль документа РКО в обработкуПРоведения тупа вставил СтатусВозврата; Возврат;....написал обработку:КонецПроцедурырезультат (да, забыл сказать РКО встречается один раз)1. галка установлена, собственно результаты оправдалисьдокументы до РКО - не проведены, документы После РКО - проведены, т.е. срабатыват ОтменитьТранзакцию и транзакция отменяет всё что было сделано ДО отменить.2. галка не установлена....не проведен ни один из документов.......комментарии есть?

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

А что ту рабираться? Штатная ситуация.

Использовал транзакции на DBF монопольно при импорте справочников из текста самописной обработкой. Время не засекал, но разница В РАЗЫ.

Дык, то в код вчитываться нужно:).

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

Меня в свое время в школе (высшей) учили, что бывает научное впечатление, а бывает научное доказательство. Это не одно и тоже. Ты оперируешь в терминах "научного впечатления". Я вполне допускаю, что так оно и есть, но самому проверять на DBF версии, вроде как, без надобности. Ты проверь работу двух процедур, совершенно идентичных, работающих в идентичных условиях, различающихся лишь отсутствием или наличием явного вызова НачатьТранзакцию, замеряй время, тогда и поговорим. Еще раз я не подвергаю сомнению, что в DBF базе, возможно, мы и получим другие результаты, но субстрата для разговора пока нет. Вот fez тестировал, замерял. Он же и недостатки такого подхода указал. Для себя я решил так, что в SQL версии нужно использовать явный вызов НачатьТранзакцию *только в тех случаях*, для которых транзакции и придумывались, т.е. тогда, когда по условиям логики требуется, чтобы все операции модификации информации завершились успешно, либо ни одна из них. Попытки ускорить выполнение кода с помощью прямых вызовов НачатьТранзакцию в SQL версии чаще не стоят усилий, на них затраченных. Кроме того, я так подозреваю, что пока длится транзакция (особенно длительная) остальные пользователи в сети будут сидеть и курить бамбук. Так что, как скажется бесконтрольное использование вызовов НачатьТранзакцию на производительность всей системы - это еще посмотреть нужно (скорее всего, негативно скажется - это мое частное "научное впечатление").

А вот попробуй зайди двумя пользователями на разных машинах в одну базу, и протестируй создание большого количества элементов в справочнике с транзакцией и без нее. Сразу увидишь очень большую разницу.Особенно в ДБФ, в скуле будет поменьше.

"я так подозреваю, что пока длится транзакция (особенно длительная) остальные пользователи в сети будут сидеть и курить бамбук".Так и есть.Собственно, разговор уже ни о чем. Понятно, что на SQL прирост незначительный. Понятно, что на DBF прирост значительный, но бездумно пользоваться не стоит. Впрочем голова - это всегда нелишний инструмент.

Тест SQL 200 SP2 1с Предприятие 25 релизКонфа в ней 1 документ "Новый1" 1 регистр "Новый1" 1 обработка в модуле документаПроцедура ОбработкаПроведенияВремя = 3705 мсекВывод в разница приуменьшена.

Тебя в школе учили сравнивать сравнимые вещи? Ты условия теста читал? Ты разницу улавливаешь между реальным типовым ТиСом и созданной тобой моделью? Результаты, полученные в 0 я, по-твоему, выдумал? Они говорят лишь о том, что при реальном проведении разных доков в реальной конфигурации значительное время тратится на операции, которым пофиг выполняются ли они в транзакции или нет.

Ай молодца!Дык с одним-то документом в конфе сильно натестируешься?И что-то незаметно, чтобы в обработках были пакетные транзакции, читай внимательно

Возможно у тебя во втором тесте документы проводились "задним числом", без установки на них ТА принудительно (или как вариант на самый первый из них с автосдвигом), поэтому у тебя документы в основном рассчитывают регистры в модуле проведения поэтому выигрышь не большой.    Использование транзакций для ускорения работы имеет смысл только при внесении больших изменений в базу, а если при этом выполняется значительное время расчет, тогда выигрыш будет минимальным (да еще мешать блокировать базу для работы других пользователей).    В свое время написал ночной робот, который базу перепроводит как раз в Тис'е формат базы SQL (ТА находиться на документе который проводят). После того как добавил транзакции по 200 док-ов скорость выросла раза в два и стала примерно равной стандартному восстановлению ГП (если посмотреть на счетчик типового восстановления ГП там видно что по 200 док-ов фиксируется транзакции).

Умерь тон. из совсем не ясно на чем проводились тесты кроме того что это ТиС. Так что не надо говорить что что это реальное проведение разных документов в реальной конфигурации. Цифры в студию как говорится. Какие документы в каком количестве? Сколько пользователей работало в момент теста с конфигурацией? Локальная сетевая работа с конфигурацией? и т.п. А то это все пустой треп. И утверждать об объективности твоих цифр ничуть не лучше чем утверждать об не объективности моих цифр.

>> Возможно у тебя во втором тесте документы проводились "задним числом", без установки на них ТА

Из 0:>> v.7.7-SQL ТиС ред. 936 (почти не тронутая, только установлен МОД и прописаны его процедуры). MS SQL server 2000 на отдельном серваке.>> отменялось проведение приблизительно 990 доков (за выбранный интервал времени), все доки образуют ненарушенную последовательность без использования механизма транзакций; б) за этот же период времени "распроведенные" доки проводились без использования механизма транзакцийЧто еще я не указал? Из ясно, что первая серия тестов проводилась в монопольном режиме. В изложены изменения в условиях теста.>> Сколько пользователей работало в момент теста с конфигурациейСмеешься? Такие тесты в боевой базе?Я не говорил о необъективности твоих цифр. У меня нет оснований в них сомневаться. Я говорил о том, что данные получены в иных условиях. Только и всего.