Довга запис в регістр відомостей через механізм автореєстрації

Всім привіт!

Зіткнувся я з однією цікавою завданням оптимізації, яка була успішна вирішена. Нижче хочу поділитися з вами досвідом. 🙂

Отже, конфігурація ЗУП 2.5, проблема – великий час проведення документа «Табель обліку робочого часу».

Приступаємо! Щоб зрозуміти в якому саме місці «гальмує», використовуємо старий добрий завмер продуктивності.

Що ж ми бачимо з даного виміру продуктивності? А бачимо ми, що перші два рядки в сумі складають 74% від загального часу, а це 535 секунд!

Давайте подивимося, що і куди записується.

Отже, перше місце:

І друге:

Проблема проявляється під час запису в неперіодична незалежний регістр відомостей «Графіки роботи за видами часу». Здавалося б все! Запис ми оптимізувати не можемо, але розрахунковий шляхом стало зрозуміло, що запис однієї
рядки займає близько однієї секунди! Не можна вибачити багато при відпочивати то залозі! Звернувшись до нашого експерта, Дмитру Козієнко, з цим питанням було прийнято рішення заглянути в SQL Server Profiler.

Ось що було знайдено:

Після запису основної таблиці регістра, відбувався запис в таблицю InfoRgChngR11473. Це таблиця реєстрації змін, яка використовується, якщо об’єкт входить хоч в один план обміну.

Тепер ми знаємо, що запис відбувається не тільки в основну таблицю регістра! Давайте дізнаємося точний час запису таблицю InfoRgChngR4547. Для цього в SQL Server Profiler необхідно отримати таблицю трасування за подією RPC Completed, далі зберігаємо її і отримуємо дані з трасування запитами. Для даної трасування я не став використовувати документ, в якому 250 рядків, тому що зібрати таку трасування досить проблематично, а взяв документ з трьома рядками табличній частині. Трасування зібрана і збережена, переходимо до запитів!

Запит перший:

Даним запитом я отримав загальне час запису. Тобто час на обробку обох таблиць. Звертаю вашу увагу, що час виводиться в мікросекундах.

Таким чином, чисте загальний час склало 2,26 секунди.

Йдемо далі, другим запитом вже отримуємо час запису в таблицю InfoRgChngR4547:

час склало 1,58 секунди, це 70% від загального часу !!!

Далі, заглянувши таблицю, стало зрозуміло, що вона зовсім не маленька:

У таблиці реєстрації на обмін 3155744 рядків. Взагалі в таблиці реєстрації не повинно бути стільки даних, вона повинна очищатися після кожного успішного обміну, але тут дала про себе знати специфіка обміну у даного клієнта.

Може труднощі виникають через «товстої» таблиці, давайте її очистимо і повторимо трасування !!!

Як видно, час на запис в таблицю реєстрації змін майже не змінилося. Очищення таблиці не допомогла!

Продовжуємо шукати вирішення проблеми.

Виключаємо наш регістр відомостей «Графіки роботи за видами часу» зі складу планів обміну та робимо завмер продуктивності.

тепер таблиця InfoRgChngR4547 не використовується, і час запису скоротилася приблизно на ті самі 70%! В рамках даного завдання питання вирішене, тому що записи регістру в обміні не беруть участь, а заповнюється відкладеним проведенням.

Але в цілях експерименту включаємо регістр відомостей «Графіки роботи за видами часу» до складу планів обміну, але вимикаємо автореєстрацію. Робимо завмер.

Як видно другий і третій вимір відрізняється незначно!

Підведемо підсумок: проблема виникає саме при автореєстрації, а конкретно коли платформа обробляє таблицю реєстрації змін в об’єкті для планів обміну. Взагалі досить дивно, що механізм платформи так повільно відпрацьовує. Було вирішено переконається в цьому. Для перевірки на тому ж самому залозі розгорнув демо базу такого ж релізу, включив РИБ, зробив завмер. І все підтвердилося, знову великий час запису! Заміряв на різних платформах на 8.2 і 8.3 результат однаковий.

Що стосується самої проблеми, то бачу її рішення тільки засобами 1С. Потрібно відійти від механізму автореєстрації, можливо зробити відкладену реєстрацію об’єкта.

Ссылка на основную публикацию