Тестирование проводилось в 1С++ версии 2.0.3.7 с применением “Microsoft OLE DB Provider for Visual FoxPro 9.0” версии 1.2 от 16/05/2008. Время выполнения запроса по методике, описанной в http://infostart.ru/profile/2905/blogs/482/ составляет 28-30 секунд.
Внимание!
Версии 8.0.0.x – бета-тестирование. Пробуйте разработку на отладочной базе данных.
Установка.
В каталоге …BIN переименовать DBEng32.dll в DBEng33.dll и распаковать архив в этот каталог.
Что делает данная разработка?
Перехватываются все функции DBEng32.dll. В функциях открытия таблиц выполняется проверка режима запуска сессии 1С. Если 1С запускается в монопольном режиме, то таблицы открываются в эксклюзивном режиме, закрываются и открываются в разделяемом режиме. Для функций, требующих эксклюзивного доступа к таблицам (реиндексация, упаковка, удаление всех записей), таблица закрывается, открывается в эксклюзивном режиме, выполняется “эксклюзивная функция”, закрывается и открывается в разделяемом режиме. Для рабочих таблиц, используемых в штатных запросах, режим открытия не изменяется.
Т.е. особенности выполнения прямых запросов через “OLE DB VFP 9” остаются и при использовании данной разработки – блокировка таблицы при выполнении запроса. И, как следствие появление ошибки “File is in use by another user” при выполнении следующей последовательности операторов:
НачатьТранзакцию();
Обновление таблицы “ААА”.
Запрос к таблице “ААА”.
ЗафиксироватьТранзакцию();
И это происходит в рамках одной сессии в любом режиме запуска сессии 1С с использованием или без использования данной разработки.
История изменений версий.
8.0.0.1 (бета-версия)
Первая опубликованная версия.
8.0.0.2 (бета-версия)
Добавлена возможность вывода отладочной информации в файлы C:DBEng32_*.log.
Для активизации этого режима необходимо установить переменную среды текущего процесса в единицу: “SET DBEng32_Debug=1”. При включенном флаге вывода отладочной информации, система 1С будет работать очень медленно.
8.0.0.3 (бета-версия)
1) Убраны отладочные операторы. Это снижает загрузку процессора и повышает скорость работы в некоторых задачах до 30%. При этом повышение общей производительности сильно зависит от условий запуска сессии 1С. Наибольший эффект достигается при использовании системы в локальном режиме одним пользователем. Т.к. доля времени, затрачиваемая на операции ввода/вывода, уменьшается в общем времени, за счет системного и аппаратного кэширования.
2) Добавлена возможность вывода подробной отладочной информации: “SET DBEng32_Debug=2”.
P.S. В разработке “DBEng32 SEQ” отладочные операторы убираться не будут.
8.0.0.4 (бета-версия)
Добавлены переменные среды текущего процесса:
SET DBEng32_NoSEQ=1 – отключает алгоритм исправления ошибки “CodeBase –56”.
SET DBEng32_NoShare=1 – отключает алгоритм открытия таблиц БД в разделяемом режиме при запуске сессии 1С в монопольном режиме.
SET DBEng32_StopSEQ=1 – включает выдачу сообщения с ожиданием действия пользователя после выполнения метода BeginReadSequence().
По умолчанию значение всех переменных равно нулю (выключено). Значения переменных считываются в момент запуска сессии 1С.
Примеры:
1) Штатный режим работы 1С:
SET DBEng32_NoSEQ=1
SET DBEng32_NoShare=1
2) Максимальная производительность при использовании прямых запросов 1SQLite с защитой от возникновения ошибки “CodeBase –56”:
SET DBEng32_NoSEQ=0
SET DBEng32_NoShare=1
3) Возможность использования прямых запросов через “OLE DB VFP 9” c защитой от возникновения ошибки “CodeBase –56”:
SET DBEng32_NoSEQ=0
SET DBEng32_NoShare=0
4) Возможность использования прямых запросов через “OLE DB VFP 9” без защиты от возникновения ошибки “CodeBase –56”:
SET DBEng32_NoSEQ=1
SET DBEng32_NoShare=0
При использовании данного режима следует учитывать, что ошибка может возникнуть и без применения 1SQLite. Но вероятность этого очень мала.
5) Тест на появление ошибки “CodeBase –56” при использовании прямых запросов 1SQLite:
SET DBEng32_NoSEQ=1
SET DBEng32_NoShare=1
SET DBEng32_StopSEQ=1
Тест проводится в двух сессиях 1С. Локальный/сетевой режим – безразлично. В процессе запуска 1С будут выдаваться диалоговые окошки с заголовком “DBEng32 Share” и именем таблицы, для которой выдан метод BeginReadSequence(). Их нужно “угрюмо прожимать”.
После загрузки обеих сессий 1С надо в одной сессии запустить запрос 1SQLite, дождаться появления окошка с заголовком “DBEng32 Share” но не “прожимать” это окошко. А в другой сессии запустить любую задачу, обновляющую таблицу, имя которой выдалось в окошке. На моей тестовой платформе сбой происходит примерно через одну минуту. Если не удастся получить эту ошибку – выходите со мной на контакт.
8.0.0.5 (бета-версия)
Восстановлен монопольный режим открытия рабочих таблиц. Это может повысить скорость выполнения штатных запросов.
8.0.0.6 (бета-версия)
Исправлена ошибка «При добавлении любого реквизита в шапку…». Подробнее см. сообщения 33-35 данной темы.
8.0.0.7 (бета-версия)
Исправлена ошибка «…при изменении кодовой страницы в Висте…». Подробнее см. сообщение 36 данной темы.
8.0.0.9 (бета-версия)
1) Добавлен алгоритм взаимодействия с утилитой LockDB. См. //infostart.ru/public/86647/
2) Добавлена переменная среды текущего процесса: DBEng32_LockDB — задаёт количество миллисекунд между опросами блокировок транзакций со стороны «DBEng32 Share» при взаимодействии с утилитой LockDB. Рекомендуется устанавливать значение — 1000 (одна секунда) и более. Умолчание для переменной — одна секунда.
8.0.1.1
Добавлена переменная среды текущего процесса DBEng32_Exclusive.
Описание см.: //infostart.ru/public/87339/ .
8.0.1.2
Исправлена ошибка в полном пересчете бухгалтерских итогов.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
49 Comments
hogik Внеочередное обновление разработки для завершения разговора с kms 😉
slavapil (19)+
dbeng32 8.0.0.3 без транзакции:
Время выполнения запроса: 28518
Элементов в базе (тест): 100000
Итерация 1: 2671
Итерация 2: 2685
Итерация 3: 2668
dbeng32 8.0.0.3 с транзакцией:
Время выполнения запроса: 27637
Элементов в базе (тест): 100000
Итерация 1: 1856
Итерация 2: 1856
Итерация 3: 1853
+++++ 🙂
hogik (23)(slavapil)
Еще раз прошу обратить внимание на условия проведения тестирования. Ниже приведены замеры для выборки из БД (, но в локальном режиме и без второго пользователя. Выборка (получение суммы) производилась штатным запросом. Перед каждым тестом производилась перезагрузка компьютера. Время в секундах.
8.0.0.2
189
132
132
Native
150
88
87
8.0.0.3
139
73
72
Но если данный запрос выполнять по методике описанной в ссылке (см. выше), то расхождения будут значительно меньше. Как между тестами, так и между замерами в рамках каждого теста.
slavapil (24)
Я понимаю так, по запросам DBF всё было хорошо и раньше!
Но версия 8.0.0.2 тормозила процедуры написанные на языке 1С (например получить реквизит из обекта Справочник «Элемент.Наименование», не запросы к базе),
в версии 8.0.0.3 вы это исправили, за это Вам еще раз огромное спасибо!
slavapil Исходники сего чуда, будут доступны?
hogik (25-26)(slavapil)
“Я понимаю так, по запросам DBF всё было хорошо и раньше!”
Нет. В сообщении (24) приведены замеры выполнения штатного запроса. И числа там разные.
Тормозили ВСЕ вызовы библиотеки DBEng32 из-за того, что у меня остались отладочные операторы от базовых разработок “DBEng32 CodeBase/Advantage”. С помощью этих операторов мне проще отслеживать и контролировать корректность перехвата функций этой библиотеки. Они не оказывали никакого влияния на снижение скорость выполнения операций ввода/вывода, но увеличивали количество команд процессора при КАЖДОМ обращении к ЛЮБОЙ функции этой библиотеки, но с разными накладными расходами. Я планировал разобраться с этими операторами в окончательной версии разработки. Но т.к. пользователи начали тестировать мою разработку, на мой взгляд, “не с того конца” – я решил это сделать досрочно, чтобы не вносить путаницу в анализ проведенных замеров. На мой взгляд, прежде всего, надо проводить сравнение производительности в том, что написал orefkov в “Ответ #353” на и принимать решение – использовать или не использовать прямые запросы в, например, модуле проведения документов. А эксплуатацию организовать так, чтобы для монопольных (регламентных) работ можно было бы переключится на родную библиотеку DBEng32.
“Исходники сего чуда, будут доступны?”
Я пока не принял решения по данному вопросу.
vip Ув. hogik!
Ссылку на конкретный пост на форуме 1cpp.ru удобнее давать в таком виде
или для вашего случая
И тогда не надо листать ветку для поиска ответа #353.
hogik В дополнение к замерам из сообщения (24), привожу замеры при той же тестовой платформе, но в монопольном режиме. Первого замера (сразу после загрузки компьютера) — не делал. Но от перемены порядка запуска тестов – числа не меняются.
8.0.0.4 set DBEng32_NoShare=1
?? — не делал.
59
60
8.0.0.4 set DBEng32_NoShare=0
?? — не делал.
74
74
hogik Добавлен в описание раздел “ Что делает данная разработка?” и обновлена версия.
JohnyDeath Я так понимаю, что теперь разработка «DBEng32 (7.0.0.3, SEQ)» не нужна. Аналогично будет использовать эту разработку со следующими параметрами:
SET DBEng32_NoSEQ=0
SET DBEng32_NoShare=1
?
hogik (31)(JohnyDeath)
Да.
Ёпрст Забавная штука обнаружилась при сохранении большой конфы, если установлена
8.0.0.5 :
Это всё на голой 1с-ине 25 релиза (без опенконф и т.д)
При добавлении любого реквизита в шапку — болт, аналогично при удалении любых реквизитов шапки (или общих реквизитов, в общем всего, что с документами связано)
Ежели убираем патч — всё работает
🙂
Ёпрст +33 Соответственно реструктуризация мд-ника не выполняется 🙁
hogik (33)(Ёпрст)
🙂 Да. Очень «забавная штука».
Ошибка исправлена в версии 8.0.0.6.
Спасибо…
Ёпрст Очередной «подарок» при изменении кодовой страницы в Висте:
и соответственно вылет из пофигуратора
🙁
Pilokarpios Если взять типовую бухгалтерию и использовать её с этими прибамбасами, быстрее будет работать, или все равно нужно переписывать на «прямые» запросы?
hogik (37)
1) «быстрее будет работать,»(с) — Нет.
2) «или все равно нужно переписывать на «прямые» запросы?»(с) — Да.
3) «использовать её с этими прибамбасами,»(с) — 🙂
PaulS Давненько искал — СПАСИБО автору
yuraos Спасибо! Качнулс. Проверимс.
yuraos Спасибо! Качнулс. Проверимс.
Из каких соображений выложены три версии
библиотеки, а не последняя из них? :))))
Чем они отличаются между собой??
yuraos А как насчет лицензионного соглашения с нуралиевым ?
Ведь тут его драааа-аценйший файлик
переименовали и подменили другим! ;))))))
Спасибо! Качнулс. Проверимс.
yuraos Наверное также, как в случае с опенконфом… -))))
А как насчет лицензионного соглашения с нуралиевым ?
Ведь тут его драааа-аценйший файлик
переименовали и подменили другим! ;))))))
yuraos Клёво! Работает!!!
Жалко что 1CV-7.7 скоро «must die». |((((
Спасибо! Качнулс. Проверимс.
yuraos Еще раз спасибо!!!
Учел в своей версии известной обработки 1CQA —
Клёво! Работает!!!
Жалко что 1CV-7.7 скоро «must die». |((((
62chma Интересно попробывать. Подскажите где найти документацию/примеры по использованию данной библиотеки.
hogik (47)
Посмотрите сообщения # 18 и 29 в:
А потом ищите в:
black_monk отлично все помогло
подскажите, пожалуйста, эта разработка чем отличается от вашей ?
о каких прямых запросах в DBF идет речь ? о тех что в 1Cqlite ?
(1)(Свой)
Данная разработка включает в себя исправление ошибки “CodeBase –56”. Эта ошибка не связана с 1SQLite. Ошибка существует сама по себе. Просто проявляется она значительно чаще при использовании 1SQLite.
Кроме этого в данной разработке обеспечена возможность выполнения прямых запросов в монопольном режиме с помощью, например, “Microsoft OLE DB Provider for Visual FoxPro 9.0”.
Огромный респект )
Смогу тестировать со вторника
1. Вопрос — а такое исправление не может привести к некорректности данных
во время проведения (если использовать только родные средства 1С)
Т.е. как осуществляется блокировка таблиц во время внесения изменений?
2. И возможна ли блокировка на уровне записей, а не только таблиц?
3. Версия 1С — 27 релиз? Для других релизов (25, 26) подходит?
hogik, не могли бы вы привести текст фрагмент процедуры с запросом которые вы использовали, чтобы воспроизвести
(4)(kiruha)
Ответы по пунктам.
1) Нет.
2) Да.
3) В 19-ой и 25-ой версиях нет существенных отличий в DBEng32. Я отлаживаюсь в 19-ой версии. Проверял свои предыдущие разработки на 25-ой версии. Больше у меня нет информации по этому вопросу – жалоб от пользователей не поступало. Можете прислать мне библиотеку из своей версии – я проведу их сравнение.
(5)(Свой)
В сообщении #29 из
(6)
п.2 Т.е. возможен аналог «гибких блокировок» для ДБФ ?!!!
Планируется ли развивать это направление?
п.3 У меня тоже 25 версия
(8)(kiruha)
“возможен аналог «гибких блокировок» для ДБФ ?”
Для меня этот вопрос очень странен — после моего “Да” на “возможна ли блокировка на уровне записей?”. Возможно под “гибкими блокировками” мы понимаем разные вещи. Поясните, пожалуйста, свой вопрос.
“Планируется ли развивать это направление?”
В моём понимании этого термина – я ломаю голову над этим пару лет (в фоновом режиме). Но эта тема у меня связана (в голове) с другой разработкой – “DBEng32 для Advantage 8.1”.
(9) Извиняюсь — вопрос скорее был риторический.
Уж очень сладкой кажется возможность )
И думаю не только у меня.
Пока это единственная проблема которая мешает хорошо жить на ДБФ.
(10)(kiruha)
Мы действительно говорим о разных вещах. Это, на мой взгляд, задача общая. А DBFы или YYYы – какая разница. Но, на данный момент, важно тестировать “DBEng32 Share”. Жду от Вас информацию о результатах…
(Автор) Посмотри, плиз,
и след. посты с анализом.
Что скажешь?
Т.е. подозрение, что работа с данными затормозилась 🙁
(12)(artbear)
Посмотрел.
Если ИТЗ.ДобавитьИндекс() работает с информационное базой данных то:
1) Должно появиться замедление в монопольном режиме запуска 1Са при использовании версии 8.x.x.x.
2) Замедление может быть связано с тем, что выполняется чтение DBFов с использованием Begin/EndReadSequence(), а в версиях 8.x.x.x и 7.0.0.3 эти методы активизируются только внутри транзакции.
(13)
п1
На небольших базах, где пользователей до 5-10 человек — иногда
использовал обертку запроса 1С в транзакцию — время выполнения уменьшалось в разы
(но и вероятность нарваться на «ожидание захвата таблицы» у других пользователей тоже увеличивается в разы )
В монопольном режиме все тип топ.
Не может быть с этим связано?
п2 Правка DBEng32 может потенциально влиять на разделенный режим?
Или затрагивает только монопольный?
(14)(kiruha)
“Не может быть с этим связано?”
Если Вы о вопросе из (12), то в ИТЗ (говорят на форуме 1С++) вообще нет обращений к БД.
“Правка DBEng32 может потенциально влиять на разделенный режим?”
В моей задумке влияет только на проблему “CodeBase –56”. 🙂
Но “оборачивается” все вызовы DBEng32.dll в независимости от режима запуска 1С.
(16) Вы не поняли.
В ИТЗ (в том варианте который стал более медленным) во время сортировки : для каждого элемента строки ИТЗ
выполняется запрос к базе — вынимается наименование и потом происходит сортировка ИТЗ по ней.
Грубо говоря это тест на выполнение в цикле запросов к базе для получение наименований справочника (без ИТЗ)
Мое предположение — в транзакции (в том числе во время проведения) — все операции 1С существенно ускоряются
— соответственно отключение этого режима ведет к замедлению.
А второй вопрос был потому — если изменения никак не затрагивают разделенный режим —
то даже замедления — не так и важно.
(16-17)(kiruha)
“Вы не поняли”
Естественно – не понял. Для меня (в моём понимании) идёт жуткая терминологическая путаница. А если “вынимается наименование” из базы в момент сортировки, то конечно дело в “СУБДе” (моём изменении DBEng32).
“тест на выполнение в цикле запросов к базе для получение наименований справочника”
Если вынимается наименование запросом, то действительно, надо размышлять о включении транзакции.
“второй вопрос был потому”
Еще раз уточню. В “DBEng32 Share” таблицы всегда открываются в разделенном режиме. Не зависимо от монопольного или разделенного режима запуска сессии 1Са. Т.к. методы Begin/EndReadSequence() дают значительное ускорение именно в разделенном режиме открытия файлов, то при использовании “DBEng32 Share” с запуском 1С в монопольном режиме можно увидеть значительное падение производительности на запросах 1SQLite по сравнению со штатным движком. Т.е. охват запроса транзакцией становиться актуальным.
Странно на тесте Михаила, у меня в разд. режиме между
родным без транзакции:
Время выполнения запроса: 29542
Элементов в базе (тест): 100000
Итерация 1: 2676
Итерация 2: 2659
Итерация 3: 2672
и с dbeng32 8.0.0.2 с транзакцией:
Время выполнения запроса: 28680
Элементов в базе (тест): 100000
Итерация 1: 2684
Итерация 2: 2684
Итерация 3: 2669
время практически совпадает.
dbeng32 8.0.0.2 без транзакции:
Время выполнения запроса: 28868
Элементов в базе (тест): 100000
Итерация 1: 3537
Итерация 2: 3550
Итерация 3: 3553
Что интересно на 1С Запрос никоим боком не влияет, значит есть надежда на решение проблемы замедления в циклах, обращения к базе считывания реквизитов справочника через ссылку на объект !?
(19)(slavapil)
При написании теста имеет смысл учитывать следующую информацию:
1) Все мои разработки с названием “DBEng32…” увеличивают количество выполняемых машинных команд.
2) Эти разработки меняют алгоритм выполнения операций ввода/ввода с целью повышение надежности и скорости работы 1С. На первом месте – надежность!
3) На тестирование этих разработок для маленьких БД в локальном режиме оказывает сильное влияние системный и аппаратный кэш. Например, в тесте от Михаила чтение информации из БД (обращение к методам DBEng32) осуществляется только в первой итерации. А скорость выполнения итераций одинаково в рамках одного запуска теста.
4) Штатные запросы 1Са используют рабочие файлы. В моих разработках доступ к этим файлам не модифицируется (кроме DBEng32 Share). Т.е. значительная часть времени уходит на работу с рабочим файлом и оценить разницу времён, на которые влияют мои разработки — становится сложней.
5) Использовать 1SQLite следует с “DBEng32 SEQ”, а при использовании “OLE DB Provider for Visual FoxPro” – “DBEng32 Share”, т.к. в этой (Share) разработке выполняется модификация операций ввода/вывода, которая снижает скорость штатных методов доступа к данным при монопольном запуске 1Са. А эта модификация не требуется для 1SQLite.
+(20)
Для выяснения влияния системного и аппаратного кэша на выполнение операций ввода/вывода в 1С DBFной версии можно запустить тест на маленькой базе данных в локальном режиме. Тест выложен в “Ответ #351” по ссылке