чарівний каталог

1. Передумови створення інструменту
2. перші труднощі
3. Основні принципи роботи інструменту
4. Підводні камені, з якими ми зіткнулися
5. Що прискорити не вийшло
6. висновок

Наша взаимовыгодная связь https://banwar.org/

Мене звати Андрій Бурмістров. Я читаю курс по підвищенню продуктивності 1C команди gilev.ru - займаюся навчанням людей того, як прискорювати 1С і вирішувати проблеми продуктивності. І сьогодні я хочу поділитися з вами досвідом створення нашою командою інструменту з автоматичного пошуку проблем в коді (зокрема, в запитах), з можливістю аналізу способів вирішення цих проблем.

Передумови створення інструменту

Збір даних для аналізу оптимальності роботи системи вже давно автоматизований. Але аналіз цих даних та надання рекомендацій по ньому, як правило, завжди проводиться людиною. Причому, цей аналіз, звичайно, варто відчутних грошей, тому що ця робота досить-таки творча, а людей, які професійно займаються оптимізацією, не так багато. Замовник, природно, хотів би витрати на таку оптимізацію знизити. Звідси випливає наступне рішення - зробити виявлення неоптимального коду максимально автоматичним.

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

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

Хочеться все це якось спростити і зробити роботу по оптимізації системи набагато швидше і якісніше - з тим же ефектом, як у виробничій революції свого часу.

У підсумку ми вирішили автоматизувати аналіз запитів в системі.

Начебто, все зрозуміло - є код конфігурації і текст запиту. Беремо код, шукаємо там запити, виділяємо неоптимальні місця - нічого складного.

Але мало того, що потрібно знайти ці неоптимальні місця автоматично, а не вручну, як це зараз робиться в більшості випадків, потрібно ще й дати рекомендації, як це виправити.

Спочатку інструмент замислювався для того, щоб спростити життя програмістам і знизити до них вимоги щодо наявності серйозних знань в SQL - щоб вони могли побачити, яка у них проблема, і дізнатися порядок дій по її усуненню.

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

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

Тим більше, оцінити вартість розробки інструменту для такого аналізу не просто, це - як порахувати, скільки грошей коштує наукове відкриття. Хоча, якщо попотіти і витратити на це кілька сотень годин, то такий інструмент зробити можна.

перші труднощі

Однак як тільки ми взялися за справу, виявилося дуже багато підводних каменів.

Спочатку ми хотіли реалізувати аналіз за допомогою схеми запиту, яка вже є в 1С - хотіли підставляти в схему запиту текст, щоб вона його розбирала на блоки, і ми їх потім намагалися аналізувати. Ми спробували цей спосіб, і виявилося, що він практично неприйнятний. Він дуже сокирний, простий, примітивний, і зробити якийсь аналіз на підставі схеми запиту практично нереально. Тому ми вирішили будувати дерево запиту по тексту запиту самостійно, своїми силами.

Також у нас було побажання, щоб весь інструмент цілком був написаний на коді 1С. Але на 1С це працювало дуже повільно, тому зараз ми будуємо дерево запиту, використовуючи можливості Java. Треба відзначити, що якби наша людина, який писав код, не займався Java, ми б цей інструмент, напевно, так і не написали досі.

Ще одним підводним каменем для нас виявилася неоднозначність рекомендацій, які повинна видавати наша система. Наприклад, якщо є запит, який сканує дані - це можливо погано, а можливо і добре. Якщо це добре, то для кого це добре? Якщо у вас використовується невелика таблиця, або ви з неї вибираєте 90% даних, то якомусь одному користувачеві це буде добре, зате всім іншим буде погано, тому що, якщо запит в транзакції, то він блокує дані.

Або, припустимо, ми зробили автоматичний аналіз якогось запиту з безліччю неоптимальні місць - отримали список рекомендацій. Тут теж не все однозначно - є рекомендації тільки для окремих випадків, а є ті, які носять гарантований характер. Нам треба розуміти, які помилки в цьому запиті є більш, а які менш критичними, і ставити в цьому списку вище ті, які більш критичні.

Зараз ми виводимо рекомендації у вигляді дерева за типами, і для кожного типу даємо візуальне позначення ефективності іконками.

Основні принципи роботи інструменту

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

Проактивний підхід заснований на прогнозних алгоритмах. Це коли у нас є текст запиту, і ми аналізуємо цей текст, не виконуючи його. Наприклад, ми можемо проаналізувати програмний модуль на 20 000 рядків коду і знайти по тексту в ньому неоптимальні місця.

А реактивний підхід дозволяє нашому інструменту в своїх рекомендаціях враховувати ті явні фактори, які впливають на рішення оптимізатора запитів - наприклад, статистику рядків в таблиці, розподіл кількості рядків за значеннями колонки, наявність відповідних індексів. Все, що на нашу думку збирає оптимізатор запитів для прийняття рішення, повинні збирати і ми.

Коли ми зробили перший прототип інструменту, наші клієнти побажали бачити в ньому аналіз не просто окремих запитів, а всієї конфігурації цілком. Тому зараз ми вивантажуємо конфігурацію в текстові файли і намагаємося знайти в ній все неоптимальні запити. Поки що наш інструмент працює тільки із запитами, але розвивати його можна нескінченно.

На слайді показана модульна архітектура нашої системи. Все позначене квадратами - це самостійний окремий код або інформаційна база. У плані надійності ми не стали «класти всі яйця в одну корзину», і тим самим посилили відмовостійкість системи, оскільки одна з баз провокувала падіння платформи 1С, а модульний підхід дозволив мінімізувати вплив цих падінь на систему в цілому.

Аналіз всієї конфігурації для пошуку проблем в ній - завдання нетривіальне. Уявіть, що у вас є текстовий файл з 20 000 рядків програмного коду, і вам потрібно вибрати звідти запити. Як це зробити? Регулярки? Просто знайти запити за ключовими словами? Якщо ми хочемо в майбутньому навчити інструмент знаходити в коді запити в циклі і аналізувати їх, то тут регулярки нам вже не допоможуть.

В результаті, наш інструмент аналізує програмний код і робить з нього синтаксичну дерево - розбирає по шматках код в дерево значень.

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

Спочатку ми вирішили реалізувати наш інструмент цілком на 1С. Але уявіть собі текстовий модуль на 30 000 рядків, по якому треба побудувати синтаксичне дерево - на мові 1С навіть на потужному обладнанні це виконувалося дуже довго.

Тому ми реалізували сервіс, який перетворює програмний модуль в дерево за допомогою коду на Java. Це відразу дало прискорення в 14 разів як мінімум.

Тому, якщо раптом ви на 1С вирішуєте якісь завдання, не пов'язані безпосередньо з урахуванням, а пов'язані, наприклад, з обробкою великих обсягів текстових даних - подумайте про інших інструментах, не про 1С. Це дасть вам прискорення не те що в рази, а на порядки.

Розбір конфігурації - це дуже витратна операція.

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

Аналогічний спосіб ви можете використовувати при аналізі великих блоків даних, наприклад, при роботі з дуже складними звітами - перед аналізом ви можете зробити хеш цих даних і, якщо надходить запит на отримання даних з таким же хешем, ви можете брати готовий оброблений результат. Це дозволяє економити ресурси. Наприклад, якщо звіт формується одну годину, а через дві години користувач з тими ж налаштуваннями робить той же звіт, то, якщо протягом цього часу в системі нічого не змінювалося (не змінювалися ті дані, які впливають на звіт), тоді береться результат попереднього звіту - користувачеві не потрібно чекати ще одну годину.

Підводні камені, з якими ми зіткнулися

Ми зіткнулися з проблемою падінь 1С, які іноді були взагалі неочевидні.

З'ясували цікаву особливість. У конфігурації був код, який показаний на слайді - це функція, яка або повертає значення, або викликає виняток. І, чомусь, якщо при виклику цієї функції була висока вкладеність, то в останньому рядку, коли результат функції присвоюється змінної, виникало виняток. Причому, ця помилка була повторювана, відтворювалася не в 100% випадків.

Якщо у вас де-небудь використовується подібна конструкція, то від неї краще позбавлятися. Навіть якщо обернути її в «Спробу-Виняток», вона все одно призводить до падіння. Мабуть, є якась помилка платформи - колись відтворюється, колись немає.

Крім цього, ми зіткнулися з витоками пам'яті. Справа в тому, що, оскільки код з аналізу вийшов досить великим і складним, частково сформованим автоматично, ми не могли встежити, що є структура, всередині якої є масив, всередині якого є дерево значень, а десь в рядку дерева значень є посилання на сам масив або на саму структуру. І, коли процедура закінчувалася, пам'ять від цих вкладених структур не звільнялася. Для нейтралізації таких ситуацій ми написали код, який всі ці вкладені колекції перед виходом з процедури очищає.

Якщо ви теж пишете конструкції, де використовується велика кількість вкладених один в одного колекцій, у вас теж є високий ризик витоків пам'яті. Тим більше, якщо у вас вже є витоку пам'яті, перевірте, де у вас використовується подібне. Для підстраховки можна написати очищення, щоб колекції при виході з процедури завжди чистилися.

В результаті у нас вийшла модульна система, в якій частина даних обробляється в одному сервісі, на одному комп'ютері, частина - в іншому, частина - в третьому. Це було зроблено спеціально, щоб при падінні однієї частини інші працювали незалежно. Але при цьому нам доводилося передавати між сервісами велику кількість даних. Наприклад, запит в «ЗУП» може важити кілька десятків мегабайт, і його при аналізі конфігурації треба передавати між сервісами. Природно, це відбувалося довго.

• Спочатку ми велике дерево значень для передачі в сервіс серіалізовивалі за допомогою «ЗначеніеВСтрокуВнутр» - обсяг даних виходив великий.
• Після цього ми вирішили спочатку поміщати дерево значень в сховище значень, і потім вже для сховища значень робити «ЗначеніеВСтрокуВнутр» - обсяг даних став набагато менше, ніж перший.
• Є підозра, що якщо ми завантажимо дерево значень в XML, потім XML спакуємо в сховище значення, для якого зробимо «ЗначеніеВСтрокуВнутр» і цей результат будемо передавати, то обсяг даних буде ще менше.

Якщо у вас є різні сервіси, і ви займаєтеся обмінами, подивіться в сторону сховища значень. Чи не стане обсяг даних для передачі в цьому випадку менше? Нам це дало дуже сильний виграш. У нас були великі обсяги, і швидкість дуже впливала.

Також ми зіткнулися з тим, що довідники в системі виходили дуже великі. Уявіть собі «УПП» в розібраному вигляді - це програмні модулі, об'єкти метаданих з безліччю властивостей. У такому вигляді конфігурація на диску займає 90 Гб.

Спочатку цей довідник був якихось неосяжних розмірів, причому його індекси були набагато більше, ніж самі дані. Нам довелося перебудувати цю структуру. Ми зрозуміли, наприклад, що такі службові індекси, як «Найменування» і «Код» в нашій ситуації не актуальні, тому найменування ми скоротили до нуля, щоб платформа для нього індекс не створювала.

Ще одне цікаве спостереження - якщо у довідника текстовий тип коду, то обсяг індексу буде набагато більше, ніж у числового. Якщо код взагалі не потрібен (або не потрібен контроль унікальності в довіднику за кодом), то його можна взагалі прибрати. Це економить дуже багато місця. Особливо, якщо довідник у вас підлеглий.

Прибравши зайві індекси, ми заощадили сотні гігабайт, тому що у нас аналізуються дуже великі зміни - це «УПП», «ЗУП» та інші. Це дало нам дуже великий виграш.

Цікава ситуація вийшла з роботою інтерфейсу.

Нагадаю, ми зробили інструмент, який показує вам неоптимальні місця не просто в запиті, а в коді всієї конфігурації. Як видно на слайді, зліва відображається якийсь аналог дерева конфігурації, а праворуч - місце в коді. Але уявіть, що програмний модуль у вас займає, припустимо, 50 000 рядків, і вам при кліці з одного боку потрібно моментально і швидко відобразити дані з іншого боку, при цьому підсвітити, в якому рядку проблема. Спочатку це було зроблено типовим для 1С чином, т. Е. З сервера все дерево з даними передавалося на клієнт. Це було нестерпно довго. Навіть не п'ять і не десять секунд, а аж до хвилини. Швидкість була дуже низька. Наша помилка полягала в тому, що всі ці тисячі рядків дерева людина навряд чи взагалі відкриє - він подивиться лише обмежена кількість рядків дерева, а інші ніколи не відкриє. Це - «надлишковий» переданий обсяг. Після оптимізації дерево рекомендацій стало відкриватися практично миттєво.

Підсвічування для проблемних рядків запиту ми реалізували за допомогою HTML-документа, але, щоб швидко сформувати такий HTML-документ з програмного модуля, нам теж довелося постаратися.

Уявіть, що у вас є 50 000 рядків тексту, з якого вам потрібно зробити HTML-документ - для цього вам потрібно перебрати всі рядки в циклі, і на виході отримати HTML-документ. Найпростіший спосіб - це конкатенація рядків, і, якщо рядків щодо мало (припустимо, 1 500), то конкатенація працює прийнятно 3 000 строк - вже обробляються приблизно половину секунди, а якщо строк стає більше 5 000, то конкатенацію використовувати вже неоптимально.

В 8.3.10 з'явилася чудова можливість роботи з потоками. Справа в тому, що новий об'єкт «Потік даних» працює з пам'яттю трохи інакше, ніж рядки. І тому при роботі з великими обсягами даних (великими обсягами рядків), як в цьому випадку, він значно виграє.

На слайді ви можете побачити, яка виходить різниця. Коли 45 000 строк, конкатенацію можна не дочекатися кілька хвилин, а потоки працюють всього лише за 15 секунд. Це я до того, що напевно у кого-то 1С використовується не тільки для задач автоматизації обліку. Може бути, ви на 1С ще якісь цікаві завдання автоматизуєте. Є такий новий об'єкт - можете його використовувати, в деяких випадках він дає дуже відчутний ефект при роботі з рядками.

Що прискорити не вийшло

На жаль, деякі моменти в нашому інструменті прискорити не вийшло, навіть нам з нашим досвідом.

Наприклад, це звіт по проблемних місцях. Беремо конфігурацію, заганяємо її в інструмент, він її аналізує. У підсумку, можна або інтерактивно подивитися, які там проблеми, або сформувати звіт і потім його почитати, відправити поштою керівництву. Сам звіт формується десь 1% часу, а решта 99% часу платформа 1С просто зберігає цей звіт в XLS. Це відбувається довго і, на жаль, вплинути на це не можна. Якщо ви плануєте формувати і зберігати в Excel якісь звіти, де кілька тисяч рядків, будьте готові до того, що це буде довго.

На слайді показано приклад такого звіту по проблемних місцях. видно:

• об'єкт, в якому є якась проблема;
• модуль, який цю проблему містить;
• рядок в цьому модулі;
• сам проблемний текст запиту;
• і відображається рекомендація, яка дозволяє вирішити цю проблему.

Виконуєте рекомендацію, і проблема йде.

висновок

Для інтересу ми вирішили прогнати через інструмент кілька типових конфігурацій.

У типовій «1С: Бухгалтерія» у нас, наприклад, вийшло десь 2000 с гаком потенційно проблемних місць. Це говорить про те, що навіть якщо конфігурація типова - це не означає, що вона буде працювати швидко, ідеально і т.д. Її код все одно пишуть живі люди, і навіть в типових конфігураціях є потенційні можливості для оптимізації.

У підсумку, я хочу відзначити, що поки в області оптимізації занадто багато ручної праці. Але зараз спостерігається тренд, коли ця область автоматизується. Ми починаємо робити буквально перші кроки в цьому напрямку, створюючи інструменти для автоматизації аналізу неоптимальности в коді. І, можливо, найближчим часом у нас з'являться кілька інструментів, здатних знаходити такі проблеми автоматично. На мій погляд, саме за цим майбутнє.

****************

Дана стаття написана за підсумками доповіді ( відео ), Прочитаного на конференції INFOSTART EVENT 2017 COMMUNITY.

Запрошуємо вас на нову конференцію INFOSTART EVENT 2018 Education .