Тренд сучасного часу - зростання інформаційних потоків всередині компанії, він досягається за рахунок багатьох факторів: зростання кількості користувачів, зростання числа автоматизованих бізнес-процесів, зростання кількості бізнес одиниць (філії, торгові майданчики, додаткові офіси, склади). Необхідно безперервно мати доступ до необхідної інформації, від цього залежить оптимальність того чи іншого рішення, прибутковість компанії. Організувати безперервний доступ не завжди виходить. Пов'язано це може бути зі збоями в ПО і обладнанні, з різними навантаженнями (регламентні заходи, наприклад, в системі 1С 8.x це може бути закриття місяця, розрахунок собівартості, розрахунок заробітної плати; передсвяткові розпродажі, акції та інше). Як же розібратися в причинах проблем продуктивності та максимально оперативно їх вирішити?

Для цього за допомогою різних інструментів збирають інформацію про показники продуктивності інформаційної системи (в нашому випадку ми використовуємо моніторинг продуктивності PerfExpert , Що має тісну інтеграцію з такими інформаційними системами як 1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3) і аналізують з пошуком «вузьких» місць в продуктивності. З огляду на, що інформація збирається у великій кількості з різних джерел (лічильники продуктивності Windows, MS SQL Server, процеси навантаження SQL Server, важкі і неоптимальні запити SQL, навантаження сесії користувачів), її необхідно групувати і ранжувати за ступінь важливості.

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

Наведу лише один приклад: один з наших вельмишановних клієнтів скаржився на зависання інформаційної системи при відкритті вікна документа «Видаткова накладна», ми як завжди, провели аналіз коду засобами вбудованого відладчика - не знайшли ніяких проблем, проводили синтетичне тестування - гальмування практично ніколи не відбувалося, поки не розробили обробку, яка з рівним періодом відкривало вікно документа і зберігала тривалості цих відкриттів. З першого погляду «криміналу» не було, менше 2% відкриттів відкривалися неприйнятно довго. Але як тільки ми створили діаграму в Excel на основі даних ми помітили цікаву закономірність.

Рис.1. Тривалості відкриттів форми документа «Видаткова накладна»

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

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

Наприклад, користувач скаржиться на тривалість виконання звіту X. Зрозуміло спочатку хочеться проаналізувати код ІС, на якому написаний звіт. Але ми в цій ситуації рекомендуємо спочатку подивитися на дані моніторингу продуктивності і визначити, чи не було нестачі ресурсів сервера (як правило сервера БД) в момент виконання звіту. Якщо нестача ресурсів була, то ми далі рекомендуємо замість аналізу коду реалізації звіту проаналізувати на причину нестачі ресурсів, а саме, які команди / запити SQL споживали ресурси. У більшості випадків ці запити SQL не належать безпосередньо до звіту X, а будуть лише сторонніми операціями (запити по екранним формам, інтерфейсні процедури, оперативні звіти). Їх і треба оптимізувати.

Для пошуку подібних запитів SQL ми використовуємо форму для трасування запитів моніторингу продуктивності PerfExpert .

Рис.2. Статистика по важким запитам SQL в розрізі модулів і рядків коду 1С

Як показано на малюнку 2, на перший рядок коду програми доводиться 13,19% загального навантаження CPU на сервер БД MS SQL, на другий рядок - 9,42%. Таким чином, якщо для швидкого виконання користувальницької операції не вистачало ресурсів CPU, то доцільно оптимізувати 2 перші рядки - сумарно вони дають майже 23% загального навантаження CPU. Аналогічно ситуація і з диском / пам'яттю і аналіз необхідно проводити аналогічно.

Сподіваюся даний матюкав буде корисний Вам у вашій роботі і розумінню важливості роботи і аналізу статистичної інформації. Детально про використовуваному нами інструменті моніторингу інформаційної системи PERFEXPERT ви можете дізнатися за адресою http://www.softpoint.ru/perfexpert-administrirovanie-serverov і про які надають нами послуги http://www.softpoint.ru/vse-it-uslugi-dly-biznesa

Цікаві статті: