Трэнд сучаснага часу - рост інфармацыйных патокаў ўнутры кампаніі, ён дасягаецца за кошт шматлікіх фактараў: рост колькасці карыстальнікаў, рост колькасці аўтаматызаваных бізнес-працэсаў, рост колькасці бізнес адзінак (філіялы, гандлёвыя пляцоўкі, дадатковыя офісы, склады). Неабходна бесперапынна мець доступ да неабходнай інфармацыі, ад гэтага залежыць аптымальнасць таго ці іншага рашэння, прыбытковасць кампаніі. Арганізаваць бесперапынны доступ не заўсёды атрымліваецца. Звязана гэта можа быць са збоямі ў ПА і абсталяванні, з рознымі нагрузкамі (рэгламентныя мерапрыемствы, напрыклад, у сістэме 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

Цікавыя артыкулы: