Аутор особља Тецхопедиа, 2. новембра 2016
Одлазак: Домаћин Ериц Каванагх разговара о перформансама апликације и како побољшати ефикасност с др. Робин Блоор-ом, Дез Бланцхфиелд-ом и Биллом Еллисом ИДЕРА-е.
Тренутно нисте пријављени. Пријавите се или пријавите да бисте видели видео.
Ериц Каванагх: Даме и господо, здраво и добродошли поново у Хот Тецхнологиес. Да заиста! Моје име је Ериц Каванагх, ја ћу вам бити домаћин за још један пренос веба данас у овој јако забавној, узбудљивој серији коју имамо као комплимент нашој серији Извештавања. Наслов је „Убрзање апликација: Бржи рад за крајње кориснике.“ Хајде људи, ко то не жели? Ако сам момак који помаже вашој апликацији да брже ради, мислим да сам тип који ми купује пиво у бару након посла. Морате бити прилично цоол ствар за шетњу и убрзавање било чије пријаве.
Постоји слајд о вашем заиста, погодите ме на Твиттеру @Ериц_Каванагх. Увек се трудим да се вратим уназад и увек ми твитне ако ме помињете, зато ме слободно напишите.
Цела сврха ове емисије је да се фокусира на различите аспекте пословне технологије и заиста помогне у дефинисању одређених дисциплина или одређених лица, ако хоћете. Много пута ће се добављачи дочекати одређених маркетиншких услова и разговарати о томе како раде ово или оно или нешто друго. Ова емисија заиста је осмишљена да помогне нашој публици да разуме шта софтверски алат треба да има да би био лидер у свом простору. Формат тога су два аналитичара. Свако иде прво, за разлику од просторија за обавештавање где продавач иде први. Свако од њих узима оно што мисли да је важно да знате о одређеној врсти технологије.
Данас говоримо о убрзању апликације. Чућемо се са Дез Бланцхфиелд и такође доктором Робин Блоор - данас смо по целом свету - а онда Билл Еллис бира из већег подручја Виргиније. Са тим, предаћу га првом нашем предавачу, Др. Блоор. Узгред смо подешавали хасхтаг #подцаст-а, зато слободно твитерајте. Однеси то.
Др Робин Блоор: У реду, хвала на уводу. Учинковитост апликације и нивои услуга - ово је врста области, током ове године сам урадила много посла у смислу да сам у ствари урадила грозан посао у праћењу перформанси и раду у једној на овај или онај начин, како испробати и израчунати те нивое. Мора се рећи да смо до раније имали неко доба, где су људи градили системе у силосе. У основи, количина посла коју они у ствари морају да ураде да би систем успешно функционисао ако је у силосу заправо и није превише тежак, јер постоји врло мало, врло мала количина променљивих које морате узети у обзир. Чим смо се правилно умрежили, интерактивна и услужна оријентација ушли су у једначину. Било је мало тешко. Перформансе могу бити једнодимензионалне. Ако само помислите на апликацију која више пута извршава одређени пут кода, ако то радите разумно, правовремено, осећа се као једнодимензионална ствар. Чим почнете да говорите о нивоима услуга, заправо говорите о више ствари које се такмиче за рачунар. То постаје мултидимензионално врло брзо. Ако почнете да говорите о пословним процесима, пословни процеси се могу повезивати из више апликација. Ако говорите о сервисно оријентисаној архитектури, тада одређена апликација може заправо приступити могућностима више апликација. Тада то постаје врло компликована ствар.
Погледао сам - одавно сам нацртао овај дијаграм. Овај дијаграм је стар најмање 20 година. У основи, ја то зовем Дијаграм свега јер је то начин да се сагледа све што постоји у ИТ окружењу. У питању су само четири дела: корисници, подаци, софтвер и хардвер. Наравно да се временом мењају, али заправо схватите када ово сагледате, постоји хијерархијска експлозија сваког од ових комада. Хардверски да, хардвер може бити сервер, али сервер се састоји од вероватно вишеструких ЦПУ-а, мрежне технологије и меморије, и ово, као што је грозно пуно контролера, као што се дешава. Ако ово стварно погледате, све се то распада на комаде. Ако заправо размишљате о покушају оркестрације свега тога, у вези са подацима који се мењају, перформансе софтвера се мењају, јер се мења хардвер, и тако даље, и тако даље, заправо гледате у невероватно тешку мулти-променљиву ситуацију. Ово је крива сложености. Наравно да је кривуља сложености за готово све, али видео сам да се то цртало изнова и изнова када говоримо о рачунарима. У основи, ако на једну осовину ставите чворове, а на другу осовину важне везе, на крају ћете добити криву сложености. Скоро да није важно који су чворови и везе и шта ће се догодити ако желите да прикажете раст гласноће у телефонској мрежи.
У ствари, када говорите о чворовима у рачунарском окружењу, говорите о појединачним стварима које брину једна о другој. Испада да је сложеност питање разнолике структуре и различитих ограничења којима се покушавате придржавати. Такође, бројеви. Кад се бројеви повећају, они полуде. Јуче сам имао занимљив разговор, разговарао сам с неким - не могу споменути ко је он, али нема везе - разговарали су о веб локацији која има 40.000 - то је четири нуле, 40.000 - примјерака база података на сајту. Размислите само о томе - 40.000 различитих база података. Наравно једино што смо имали - очито су имали много, много хиљада апликација. Говоримо о веома великој организацији, али не могу је именовати. Заправо гледате на то и заправо покушавате, на овај или онај начин, достићи нивое услуга који ће бити адекватни на свим странама за неке више корисника, са више различитих, ако желите, очекивања. То је сложена ситуација, и да све што стварно кажем је, то је сложено. Број се увек повећава. Ограничења су одређена пословним процесима и пословним циљевима. Приметићете да се очекивања мењају.
Сећам се чим су се појавили Гмаил, Иахоо маил и Хотмаил, сви ти поштански системи, људи су почели да очекују да ће њихови интерни поштански системи унутар организације заслужити ниво услуге ове огромне операције са огромним фармама сервера изван организација и почела је вршити притисак да се све такве ствари догоде. Уствари, споразуми на нивоу услуга су једна ствар, али очекивање је друга ствар и они се међусобно боре унутар организације, незгодна ствар. Ево само пословне перспективе. У неким системима оптимално време одзива је једна десетина секунде људског времена одзива. Десетина секунде је време које је потребно да вас кобра уједе. Ако стојите испред кобре и одлучи да вас угризе, прекасно је, јер нећете моћи да одговорите у једној десетини секунде. Десетина секунде отприлике је времена које је потребно да лопта остави руку бацача да дође до момка са палицом. У основи, како види да је лопта бачена, мора тачно да реагује. Људски одговор, занимљива ствар. Софтвер до софтвера очигледно може очекивати већа очекивања.
Тада наилазите на неке ситуације за које мислим да су оне тржишне ситуације, где је прво место где је пословна вредност. То је као да, ако желите да продате одређену деоницу на берзи, вероватно је мање, на пример, јер мислите да пропада и многи други људи мисле да иде доле, добијате најбољу цену ако прво дођете на тржиште. Има пуно ситуација, послуживање огласа и сличне ствари, врло слична ситуација. Добили сте овај покрет у смислу очекивања на нивоу услуге. Имате једну ствар која је врста стакленог плафона за одговор људи. Једном када је софтвер-софтвер, ако имате ову таваницу, не постоји најбољи ниво услуге. Брже од свих је најбоље.
У реду, ово је, мислим, последњи слајд који сам радила, али ово је само да вам пружим ширу слику сложености, након што заправо погледате потребе организације, услуга. Овде идете лево, овде имате системски менаџмент, који је скуп софтвера који служи за управљање услугама, који покушава да управља нивоом услуге. Изнад тога имате управљање пословним перформансама. Затим ако погледате овде доле, област аутоматизације сервиса, добили сте фрагментиране услуге које се развијају у стандардизоване услуге, ако вам је заиста стало да улажете у такве ствари, које еволуирају у интегрисане услуге, а које еволуирају у оптимизоване услуге . Углавном су људи радили само у доњем левом углу овог. Можда мало управљања услугама. Управљање пословним перформансама, веома ретко. Фрагментирано, готово све. Савршени свет би испунио ту мрежу. Инструментација - споменуо сам проблем подоптимизације. Можете да оптимизујете делове система и то није добро за цео систем. Ако срце учините оптималним, ваша крв може пребрзо циркулирати за остале органе. То је проблем са великим организацијама и нивоима услуга. Јасно је да се ништа неће постићи без софистицираних алата, јер су променљиве управо стигле - па има превише променљивих за покушај и оптимизацију.
Рекавши то, прећи ћу на Дез који ће причати о нечему другом у потпуности, надам се.
Дез Бланцхфиелд: Хвала, Робин. Као и др Робин Блоор, и ја сам провео превише година размишљајући о перформансама врло сложених система у веома великом обиму. Вероватно није иста скала као Робин, али перформансе су свакодневна тема и део је нашег ДНК да желимо перформансе, да извучемо најбоље из свега. У ствари, користио сам графику једне од мојих најдражих ствари на свету, тркачких кола Формуле И, где цела планета још неко време седи и гледа како се аутомобили врло брзо крећу у круговима. Сваки појединачни аспект, не постоји аспект Формуле И који се не односи конкретно на постизање перформанси. Многи људи се баве спортом, јер сматрају да је то губљење новца. Испоставило се да аутомобил који возимо сваког дана како би викендом оставили децу у фудбалу, а остале дане у школи, произлази из развоја и истраживања заснованог на перформансама. То је врста живота тркачких кола Формуле И. Свакодневна технологија, свакодневна наука, често потиче од нечега што је фокусирано искључиво на високе перформансе.
Реалност је, међутим, да је наш нови „увек на“ свету, који захтева 100 одсто продуженог времена - као што је Робин већ споменуо - са стварима попут увођења веб поште и других услуга које непрекидно схватамо, а сада очекујемо да наше предузеће и радно окружење. Реалност је да то што не ради увек значи да испуњавате договор о нивоу услуге. Сматрам да је то потреба за управљањем перформанси апликација и споразума о нивоу расположивости услуга претрпео је битан помак у последњој деценији. Не покушавамо се више бринути само о перформансама једног система. Када је свет био мало једноставнији, могли бисмо имати ситуацију да се један сервер са вишеструким сервисима може пратити уживо и то је релативно лако подржати. Могли бисмо - а ево и мог малог, због чега смо се бринули када сам, на пример, био системски администратор пре много година, - осврнули бисмо се око тога, да ли се услуга обично и реагује? Могу ли се на пример пријавити на терминал? Да ли се оперативни систем одазива и да ли могу да уносим команде? Да ли се апликације покрећу? Могу ли да видим процесе и меморију како раде ствари и И / О кроз мрежу и тако даље? У данима маинфраме-а могли сте чути касете како зип-зип-зип испадају из њих.
Да ли апликације реагирају и можемо ли се пријавити и радити нешто на њима? Да ли се корисници могу повезати с неким од тих сервера? Иде на. Они су прилично фундаментални, знате. Онда неколико смешних - да ли је служба за помоћ зелена? Јер ако не, онда све иде у реду, и ко ће добити крафне? Живот је у те дане био заиста једноставан. Чак и у оне дане, а затим говорим пре 20-30 година, сложеност је и даље била заиста велика. Могли бисмо, на релативно једноставан начин, управљати споразумима о нивоу услуге и водити рачуна о учинку. Не можемо то више учинити руком, као што је Робин алудирао. Изазов је превелик. Чињеница је времена када неколико добрих апликација, администратора, системске мреже и базе података, администратори могу надгледати и удовољавати СЛА-овима о перформансама. СЛА-ови су тако далеко отишли да сам се синоћ мучио кад сам састављао своје последње белешке и размишљао о години када сам последњи пут успео да погледам систем веома сложеног снопа, и смислим га, па чак и схватим шта је под хаубом, а ја долазим из дубоко техничке позадине. Не могу замислити како је то свакодневно суочавати се административно.
Шта се десило? Па, 1996. године апликације које се баве базама података трансформисане су помоћу интернетског процвата. Много нас је прошло кроз то. Чак и ако нисте били око бум-а на Интернету, лако можете само погледати око себе и схватити да у свакодневном животу сада за интернет можемо повезати све. Верујем да имамо тостер који очигледно долази са опцијом да се упалим на Ви-Фи, што је смешно, јер ми не треба мој тостер спојен на интернет. У 2000-има, посебно почетком 2000-их, морали смо се суочити са овим масивним растом сложености круга пружања услуга у дот-цом боуму. Затим још једна смешна неспретна искра у вебу 2.0, где су настали паметни телефони и сада су апликације биле у нашим рукама 24/7 и увек су биле у режиму рада.
Сада је 2016. година, суочени смо с још једном потресом у облику облака, великих података и мобилности. То су системи који су толико велики да их је често тешко разумети и објаснити обичним енглеским. Кад помислимо на чињеницу да неки од великих једнорога о којима говоримо имају на десетине стотина петабајта података. Ово је цео спрат простора на диску и складиште само за чување е-поште, слика и друштвених медија. Или у неким случајевима у транспортној и бродској логистици, све је у банкарству, тамо је ваш новац, или где је ваш пост или ваш, где је ствар коју сте купили на еБаиу. Следећи велики талас са којим ћемо се суочити је овај веома тежак изазов интернета.
Да ово није довољно лоше, управо ћемо изградити вештачку интелигенцију и когнитивно рачунање у готово свему. Ових дана разговарамо са Сири и Гоогле моторима. Знам да Амазон има своје. Баиду имају један од ових уређаја са којима можете да разговарате, претварају га у текст који иде у нормалан систем, база података поставља упит и враћа се и враћа процес назад. Размислите о сложености која иде у то. Реалност је да сложеност данашњег стандардног броја апликација далеко превазилази људске могућности. Када размислите о свему што се догоди када притиснете дугме на уређају са паметним телефоном или таблетом, то говорите, претвара то у текст, покреће то све до интернета у бацк-енд систем, прима се фронт-енд који, претвара га у упит, води упит путем снопа апликација, пролази кроз базу података, погађа диск, враћа се ван, а у средини је мрежа носача, постоји центар статуса локалне мреже. Сложеност је луда.
Ми то ефективно тврдимо као хипер-скале. Сложеност и брзина хиперсвелике је само наводњавање очију. Апликације и базе података постале су толико велике и толико сложене да је управљање перформансама у ствари наука сама по себи. Многи га називају ракетном науком. Имамо технологију на лицу места, имамо технологију ван локације, имамо низ могућности дата центра; физички и виртуелни. Имамо физичке и виртуелне сервере, имамо облак, имамо инфраструктуру као сервис и платформу као услугу и софтвер као услугу је ствар коју сада узимамо здраво за готово. Потоњи, софтвер као услуга, постао је застрашујући неко време пре неколико година, када су финансијски менаџери и делови организације схватили да могу да преузму своју кредитну картицу и само купе ствари и обиђу ЦИО и ефикасно смо то назвали „сенком ИТ ”и ЦИО-овци сада покушавају вратити ову леђа и борити се за контролу над њима.
У инфраструктури имамо софтверско дефинисано умрежавање, виртуализацију мрежних функција, испод тога што вероватно имамо, сада имамо микро сервисе и апликације активних сервиса. Када кликнете на УРЛ, на крају УРЛ-а се налази гомила пословне логике која описује шта му заправо треба да би га испоручили. То не мора нужно да има уграђену логику која га чека. Имамо традиционалне базе података на једној страни које су скалирање веома, веома велике. Имамо сличност Хадооп инфраструктуре и екосистема на другом спектру који су управо толико велики да, као што рекох, знате, људи сада говоре о стотинама петабајта података. Имамо мобилност сложености што се тиче уређаја који носе около, лаптопове и телефоне и таблете.
Имамо БИОД у неким затвореним срединама и све више сада, откад искусни људи из Ген И доносе своје уређаје. Само им допуштамо да разговарају са њима о веб сучељима. Или путем интернета или преко Ви-Фи-ја, у кафићу доле имамо бесплатан Ви-Фи јер они пију кафу. Или наш интерни Ви-Фи. Машина за машину је икада присутна. То није директно део интернета ствари, али је такође повезано. Интернет ствари је потпуно нова игра сложености која смета. Вештачка интелигенција и ако мислите да је оно с чиме се сада играмо, са свим Сири и осталим сродним уређајима с којима разговарамо, сачекајте док не дођете у ситуацију да видите нешто што се зове Олли, а то је 3-Д штампан аутобус који броји око шест људи и може се возити по граду, а ви му можете причати обичан енглески језик, и он ће вам одговорити. Ако погоди саобраћај, одлучиће скренути лево или десно од главног дела где постоји саобраћај. Док се скрене и забринете се зашто је скренула лево или десно с главне цесте, рећи ће вам: „Не брините, скренућу лево. Предстоји саобраћај и ја ћу га обилазити. "
Управљање перформансама свих система тамо и свим сложеностима, праћење куда иду ти подаци, да ли иду у базу података, све међусобно повезивање и све релевантне битове само је неумољиво. Реалност је да управљање перформансама и СЛА-овима данашњим брзинама и опсегом захтева алате и системе, а по дефаулту то више није нешто на чему бисте само помислили да би било лепо имати алат - то је предуслов; то је апсолутно неопходно. Ево мало као пример, листа дијаграма дизајна апликација на високом нивоу за ОпенСтацк, опен-соурце софтвер дефинисан облак. Ово је само велики део. Ово нису само сервери и базе података. Овде свако плаво мрље представља гомилу ствари. У неким случајевима датотеке и сервери или стотине база података или, наравно, не више од десетина хиљада малих комада апликација логика. То је мала верзија. Заиста је прилично мучно када почнете размишљати о сложености која долази у овоме. Данас ћу, чак и у само великом простору података, ставити неколико снимака само марки. Када размислите о свим комадима којима овде требамо управљати, не говоримо само о једној робној марки нужно, то су све марке у пејзажу великих података и врхунској марки, а не само о сваком малом или отвореном извору. Изгледате и мислите да је то прилично мучна карта.
Погледајмо пар вертикала. Узмимо, на пример, маркетинг. Ево сличног графикона, али из технолошких гомила које су доступне само у маркетиншкој технологији. Ово је граф из 2011. Ево верзије за 2016. годину Само размислите, ово је само број марки производа које можете покренути за технологију у погледу маркетиншке технологије. Не сложеност система унутра, не и различите апликације и веб, развој и мрежа и све остало. Само бренд. Ту је било пре, пет година, а ево и данас. Само ће се погоршати. Сада смо сада где је стварност, људи једноставно не могу да осигурају све споразуме о нивоу услуге. Не можемо да заронимо у довољно детаља, довољно брзо и у потребним размерама. Ево примера како сада изгледа конзола за надгледање. Ово је попут скоро двадесет необичних екрана залијепљених заједно претварајући се да су то један велики, пројицирани екран који надгледа сваки мали комад. Сада је овде занимљиво, нећу спомињати бренд, али ова платформа за праћење прати једну апликацију у окружењу логистике и отпреме. Само једна апликација. Ако мислите о томе о чему је Робин говорио где организације могу да имају 40.000 база података сада у производним окружењима. Можете ли само представити каква би могла изгледати 40.000 верзија ове колекције екрана која прате једну апликацију? То је врло храбар свет у којем живимо. Као што је Робин рекао и ја ћу апсолутно, 100% одјекнути да, без правих алата, без праве подршке и људи на столу помоћу тих алата, перформансе апликације су изгубљена игра за људе и то морају да раде алати и софтвер.
Са тим ћу пренијети нашим пријатељима у ИДЕРА.
Ериц Каванагх: У реду, Билл.
Билл Еллис: Хвала. Дијелим овдје свој екран. Ваљда може неко потврдити да можете видети мој екран?
Др Робин Блоор: Да.
Ериц Каванагх: Изгледа да је све у реду.
Билл Еллис: Хвала. Једину ствар на коју се осврнуо је, ја заиста не могу чекати да је то самовозећи аутомобил. Једна ствар о којој нисам чуо никога да прича је шта се дешава када пада снег? Питам се да ли су инжењери у Калифорнији схватили да у осталим деловима земље снежно пада.
Дез Бланцхфиелд: Свиђа ми се то, сетићу се тога.
Ериц Каванагх: Типично миљу на сат.
Билл Еллис: Овде смо да разговарамо о управљању перформансама апликација у сложеном окружењу. Једна ствар о којој волим да причам је да пуно људи говори о перформансама, природа реакције је, хеј више сервера, више ЦПУ-а, више меморије итд. Друга страна тог новчића је ефикасност обраде. Заиста, то су две стране исте кованице и погледаћемо их обе. Крајњи циљ је испуњавање споразума о нивоу услуга за пословне трансакције. Коначно, сва ова технологија постоји за посао. Разговарали смо о томе да имамо прву базу података о управљању перформансама у индустрији. Идеал тога је уклапање у идеалан калуп перформанси и управљање њиме од почетка животног циклуса апликација.
Теме се заиста своде на четири дела; један је процес управљања перформансама. Са свима смо разговарали и сви имају алате. Ако немају алате, имају скрипте или наредбе, али оно што им недостаје је контекст. Контекст је једноставно повезивање тачака преко снопа апликација. Ове апликације за - засноване су на прегледачу. Врло су чврсто спојени од нивоа до нивоа. Како су слојеви интерактивни, такође је од виталног значаја. Затим, говоримо о пословној трансакцији. Осигураћемо видљивост не само техничким људима, већ и власницима апликација и руководиоцима операција.
Имам неколико студија случаја да бих само поделио са вама како их купци користе. Ово је врло практичан део презентације. Погледајмо шта се обично дешава. Волим да дијаграм - то је било као невероватан колаж технологија. Број технологија у податковном центру тек је растао, одрастао и растао. У међувремену, крајњег корисника није брига за то и свестан тога. Они само желе да изврше трансакцију, да ли је доступна, да ли ће је брзо извршити. Оно што се обично дешава је да професионалци у ИТ-у нису свесни да су крајњи корисници чак имали проблема, док се не пријаве. То отпочиње дуготрајан, спор процес и често фрустрирајући. Оно што се догађа је да ће људи отворити своје алате и погледати подскуп својих скупова апликација. Помоћу тог подскупина постаје врло тешко одговорити на најједноставније питање. Да ли је уобичајено да имате проблем? Која је трансакција? Где је у пакету апликација уско грло? Проводећи све ово вријеме, гледајући слој по нивоу, не успијевајући одговорити на ова питања, на крају трошите пуно времена и енергије, пуно особља, средстава и енергије попут проналажења.
Да би се то решило, да би се обезбедио бољи начин, оно што Прецисион ради заправо је преузимање трансакције праћене крајњим корисником, биљежи метаподатке о томе, прати трансакцију кроз мрежу, на веб сервер, у ниво пословне логике и подржавамо .НЕТ и АБАП, ПеоплеЦоде и Е-Бусинесс Суите, у мултитиер апликацијама да ће на крају све трансакције бити у интеракцији са системом снимања. Било да се ради о претраживању инвентара, о урађеном времену извештавања, они увек комуницирају са базом података. База података постаје темељ пословног учинка. База података се заузврат ослања на складиште. Шта одговарају метаподатци о трансакцијама, ко, која трансакција, где се налази у апликацији и затим имамо дубоку видљивост на нивоу кода како бисмо вам показали шта се извршава. Те информације се непрестано прикупљају, убацују у базу података о управљању перформансама - која постаје јединствена листа музике како би сви видели шта се догађа. Постоје различити људи и организације којима је стало до тога шта се дешава: технички стручњаци, власници апликација, на крају и сам посао. Када се појави проблем, желите да будете у могућности да извучете информације о тој трансакцији.
Пре него што погледамо инвестицијску трансакцију, желим да вам покажем како се то може појавити различитим људима у организацији. На нивоу управљања, можда бисте желели да имате преглед више апликација. Можда бисте желели да знате о здрављу које се израчунава према усаглашености и доступности за СЛА. То здравље не значи да све функционише 100% савршено. У овом случају има места за који можете видети да је инвестицијска трансакција у статусу упозорења. Сада, мало дубље, можда у вашој делатности, желите да имате неке додатне детаље о појединачним трансакцијама, када крше СЛА-ове, броје трансакције итд. Оперативни тим ће желети да буде обавештен о томе путем обавештења неких врста. Уграђена су упозорења о перформансама. Ми заправо меримо перформансе у прегледачу крајњег корисника. Било да смо у могућности да откријемо Интернет Екплорер, Цхроме, Фирефок итд., Ово одговара на прво питање: да ли крајњи корисник има проблема?
Заронимо унутра и погледајмо шта још можемо да покажемо о томе. Људи који су заинтересовани за перформансе отворили би се Прецизно. Они би проценили трансакције. Они би погледали колону СЛА да идентификују трансакције које нису сагласне СЛА-и. Они ће моћи да виде крајње кориснике на које су утицали, као и шта је та трансакција урадила док је текла преко апликације. Начин на који дешифрујете ове хијероглифе, ово је претраживач, УРЛ, У је за УРЛ, то је улазна тачка у ЈВМ. Сада овај одређени ЈВМ упућује позив веб сервера другом ЈВМ-у који извршава СКЛ израз. Ово је очигледно проблем с базом података јер је ова СКЛ изјава одговорна за 72 посто времена одговора. Усредсређени смо на време. Време је валута перформанси. На тај начин крајњи корисници доживљавају да ли се ствари покрећу полако или не, и то је мерило потрошње ресурса. Веома је згодан; то је врста јединствене метрике која је најважнија за процену перформанси. Када се овај проблем преда ДБА, то није само проблем базе података, већ СКЛ изјава. Ово је контекст о коме сам говорио.
Сада наоружан тим информацијама, у стању сам да уђем и анализирам шта се догодило. Пре свега видим да је оса и време током дана. Извините, оса и је време одзива, к-ос је време током дана. Видим да постоји проблем са базом података, постоје два догађаја, вратите се том току, покупите ту СКЛ изјаву и пређите у стручни приказ, где Прецизан може да вам покаже шта се дешава, његове контроле, колико дуго тај код треба да уради извршити. У нивоу базе података то је план извршења. Приметићете да је Прецисион одабрао прави план извршења који је коришћен у време извршења, а разликује се од процењеног плана, који би био када је план дат, а не током извршења. Може или не мора одражавати да је база података заиста и била.
Овде је доле анализа времена одговора за СКЛ изјаву. Деведесет процената времена проведеног у складишту; десет процената коришћено је у ЦПУ-у. Могу да видим текст СКЛ изјаве као и извештај о налазима. Текст СКЛ израза заправо почиње да открива неке проблеме кодирања. То је изабрана звезда; који враћа све редове - извините, сви ступци из редова који су враћени. Враћамо додатне ступце које апликација може или не треба. Ти ступци троше простор и ресурсе за обраду. Ако покренете САП, једна од већих промена, јер је ХАНА база података ступац, јесте да у основи преписујемо САП да не бирате одабрану звезду, тако да могу у великој мери да смање потрошњу ресурса. То се у основи догађа много времена и код домаћих апликација, било да су то Јава, .НЕТ итд.
Тај екран вам показује ко, шта, када, где и зашто. Зашто долази, као што је СКЛ изјава и план извршења који вам омогућава да решавате проблеме. Будући да се Прецисион континуирано покреће, заправо можете мерити пре и после тога, на нивоу СКЛ изјава, на нивоу трансакције, тако да или можете мерити за себе, као и кроз власнике апликација и за управљање, да сте решили проблем . Та документација је заиста корисна. Постоји пуно сложености у овој апликацији. У ствари, многе апликације, са којима смо разговарали, покрећу бар део скупа апликација под ВМваре-ом. У овом случају, они гледају апликацију за корисничку службу, гледају време трансакције и повезују је са успоравањем је догађај виртуализације. Прецизно прате све догађаје виртуализације. Имамо додатак за вЦентер да то покупимо.
Такође смо у стању да откријемо свађу. Садржај је другачији од употребе. У ствари показује када можда бучни комшија утиче на ВМ госта, у контексту апликације клијентског сервера. Сада сам у прилици да пронађем и добијем информације и заправо могу да видим два ВМ-а која се у овом случају такмиче за ресурсе ЦПУ-а. Ово ми омогућава видљивост тако да могу да гледам заказивање. Могу да поставим гостујући ВМ на други физички сервер. На све ове врсте ствари на које бисте могли да одговорите, а затим поред тога, ја заправо могу да сагледам ефикасност кода да бих могао да користи мање ЦПУ-а. Мислим да имам прилично добар пример у овом излагању како је неко успео да смањи потрошњу процесора за наредне величине.
То је био ВМваре. Идемо у сам код, код апликације. Прецизно ће вам моћи показати шта се дешава унутар Јава, .НЕТ, АБАП кода, е-пословања, ПеоплеЦоде итд. Ово су улазне тачке у овом случају у ВебЛогиц. Овде је извештај о налазу који ми говори да то ЕЈБ требате погледати и рећи ће вам да се такође закључавају у овом систему. Још једном, детаљна процјена унутар нивоа пословне логике, да се покаже шта се дешава. У овом случају, посматрам одређене случајеве; Такође подржавам удруживање. Ако имате бројне ЈВМ-ове који раде, можете или погледати кластер у целини или погледати уска грла унутар појединог ЈВМ-а.
Кад уђете у закључавање, ја могу доћи у изузетке. Изузетак је мало другачији од проблема са перформансама. Изузеци се изводе врло брзо. Пошто постоји логичка грешка и једном када притиснете ту логичку грешку, она се завршава. Успели смо да ухватимо траг стака у тренутку када је изузетак, ово би могло уштедети пуно времена док пролазимо кроз покушај да схватимо шта се догађа, само имаш траг стака, управо тамо. Такође смо у могућности да снимимо пропуштање меморије. Решење такође укључује ниво базе података, могу ући, могу проценити инстанцу базе података. Још једном, и-ос је место на којем је време проведено, к-оса је време током дана. Постоји извештај о налазу који ми аутоматски аутоматски говори шта се дешава у систему и шта бих могао да погледам.
Једна од ствари у Прецизовом извештају о налазима, није само преглед дневника или стања чекања - он прегледава сва стања извршења, укључујући ЦПУ, као и враћање информација из складишта. Складиштење је веома важан део снопа апликација, посебно са појавом чврстог стања. Информације у том правцу могу бити од велике помоћи. За одређене јединице за складиштење можемо заправо пробушити и показати шта се дешава на нивоу појединачних уређаја. Та врста информација - још једном, то је дубока видљивост; широког је опсега - да вам пружи довољно информација како бисте имали више утицаја на себе као професионалац у погледу перформанси апликација, тако да можете да оптимизујете апликације све до краја да испуните те пословне трансакције.
Имам неколико студија случаја које бих хтео да поделим са вама. Кружимо прилично брзо; Надам се да идем у реду темпом. Када говоримо о складишту, сви током времена мењају хардвер. Постоји хардверска гаранција. Да ли је заиста испоручио оно што вам је продавач рекао? То можете проценити са Прецисион. Улазите, и шта се овде догодило, у основи су ставили нову јединицу за складиштење, али када су администратори складишта погледали само на нивоу складишне јединице, видели су много спорења и помислили да могу да постоје проблеми са овом новом јединицом за складиштење . Гледајући више из перспективе од краја до краја, тачно како би показао где би се то заиста догодило. Заправо су отишли из пропусне снаге од око 400 мег у секунди, где је складиште било одговорно за 38 одсто времена одзива, тако да је прилично велико. Са новом складишном јединицом ми смо уствари повећали пропусност на шест, седам стотина мега у секунди, што је у основи дупло, и ми смо у могућности да преполовимо допринос нивоа за складиштење времену трансакције на пола. Могу то заиста раније графички приказати, ово је период прекида, а затим касније.
Дакле, још једном, документација која доказује да је улагање у хардвер вредна и они су је испоручили онако како је одређени добављач очекивао. Постоји све, због сложености, броја ствари, могу се догодити све врсте ствари. У овом случају, они су уствари имали ситуацију када су сви на неки начин окривили ДБА, ДБА је био попут „Па, не тако брзо.“ Овдје заправо гледамо САП апликацију, мислим да је овакав сценариј прилично уобичајен . Оно што се догодило је да су развијали прилагођену трансакцију за корисника. Корисник је попут, „Ово је тако споро.“ АБАП кодер - то је програмски језик у САП-у - рекао је, „Ово је проблем са базом података.“ На крају су отворили Прецизно; одмерили су тог крајњег корисника 60 секунди, дакле добро током једног минута. Педесет три секунде је потрошено у задњем крају. Избушили су се на задњем крају и заправо су могли да открију СКЛ изјаву представљену силазним редоследом.
Ова врхунска СКЛ изјава која је одговорна за 25 одсто потрошње ресурса, њено просечно време извршења је две милисекунде. Не можете кривити базу података. Знате, хеј, не тако брзо момак. Питање је, зашто постоји толико погубљења? Па, вратили су га назад у АБАП, он је ушао, погледао у уметање петље, открио да позивају базу података на погрешном месту, у основи су извршили промену, тестирали промену и сада је ново време одзива пет секунди Мало полако, али могли би с тим да живе. Далеко боље од 60 секунди. Понекад, само проверавање, да ли је то код апликације, да ли је то база података, да ли је то складиштење? То су подручја у којима Прецисион има контекст трансакција све до краја, ту игра Прецисион. Ви заправо окончате те ствари.
Гледам време, изгледа да нам преостаје још мало времена да прођемо кроз још пар ових ствари. Прелазим кроз њих. Ова апликација је била у изради више од годину дана. Када су ушли у КА, видели су да су веб сервери 100% максирани и изгледало је као да апликација не може да ради под ВМваре-ом. Прво што су сви рекли било је: „Ставите то на физичко; не може да ради под ВМваре-ом. “Прецизно им је заправо понудило додатне начине да реше проблем. Гледали смо трансакције, видели смо позив веб сервера, долази као АСМКС у ИИС.НЕТ. Заправо је открио основни код. Јесте ли видели ово где кажем? Ово је 23 дана, 11 сати. Вау, како је то могуће? Па свако позивање траје 9, 4 секунде и ова се ствар позива 215 000 пута. За свако позивање користи 6 секунди ЦПУ-а. То је разлог, овај код је разлог зашто ова ствар никад не би могла да се прошири. У ствари, физички се није могао скалирати.
Оно што су урадили, јесу да су се вратили програмерима и они су рекли: „Може ли неко променити?“ Они су на неки начин имали конкурс и испробали различите предлоге и дошли су до предлога који је могао много да покрене. ефикасније. Нови је завршио једну тачку, нешто мање од две секунде, са две стотинке секунде у ЦПУ-у. Сада би то могло да се повећа и могло би да се покрене на ВМваре фарми. То смо могли у основи документовати и на нивоу кода и на нивоу трансакције. Ово је врста раније, а затим после. Сада када овде можете видети на графикону снопа који приказује веб, .НЕТ и базу података, сада комуницирате са базом података. Ово је профил који бисте очекивали да бисте видели за апликацију која ради нормалније.
У реду, бирам и бирам у смислу додатних ствари које могу да вам покажем. Многима се ово свиђа јер овај покрива многе продавнице. Ако не можете да упознате пословну лиценцу за посао и сви су попут: „Помозите нам.“ У овој продавници је била ситуација да је пословни СЛА по наруџбама примљен до 15 сати, испоручује се тог дана. Стварно је битно да они добију наруџбе, а магацин је веома заузет. Овај екран за наруџбу ЈД Едвардса замрзавао се и можете добити веома добру идеју да је ово правовремени систем управљања малопродајним залихама. Празне полице су неприхватљиве у малопродаји. Морам имати робу тамо да бих је могао продати. Оно што смо урадили је да смо заронили, у овом случају гледамо базу података СКЛ сервера. Изглед је исти без обзира да ли се ради о СКЛ, Орацле, ДБ2 или Сибасе.
Идентификовали смо селекцију из ПС_ПРОД и успели смо да ухватимо трајање, чињеницу да их толико извршавају. Тамноплава је одговарала кључу који је рекао да не чекају на неко стање чекања или неку евиденцију или чак складиштење - ову ствар веже ЦПУ. Пратили смо СКЛ изјаву до 34301, тако да сваки пут када се ово изврши, увећавамо бројила да бисмо је пратили. То значи да имамо детаљну историју и да јој могу приступити кликом на тај тастер мелодије. Ево картице историје. Овај екран овде приказује просечно трајање насупрот променама. Среда, четвртак, петак, просечно трајање било је око две десетине секунде. Врло мали број екрана се замрзава, они су у стању да се упознају са пословним споразумима о услугама уговора. Дођите 27. фебруара, нешто се мења и изненада је време извршења овде горе, а то је заправо довољно споро да проузрокује временске ограничења, што резултира замрзавањем екрана. Прецизно, чувањем детаљне историје, укључујући план извршења и опште промене индекса табеле ако се користи тај СКЛ. Били смо у могућности да установимо да се план приступа променио 27. фебруара. Од понедељка до петка лоше недеље. Дођите 5. марта, план приступа се поново променио. Ово је добра недеља. Ова ружичаста звезда говори нам о јачини ажуриране.
Овде можете видети да број редова у доњим табелама расте и то је типично за посао. Желите да вам столови расту. Ствар је у томе што су изјаве рашчлањене, долазе СКЛ изрази, оптимизатор мора одлучити шта треба радити и изабрати када је план извршења брз, изабрати други план извршења када је спор, узрокујући да се екран замрзне. На дубокој технолошкој основи, морам да знам шта је план извршења и Прецизан је забележио за мене заједно са датумом и печатом. Ово је брзо и ефикасно, ово је споро и неефикасно. Ово придруживање филтера једноставно користи много више ЦПУ-а за помирење за обављање ове посебне СКЛ изјаве. И даље имају исти крајњи ефекат, али овај у основи има спорији, мање ефикасан рецепт за постизање скупа резултата. Дакле, пролазимо кроз. Хеј, имамо времена за још пар?
Ериц Каванагх: Да, наставите.
Билл Еллис: Ок, прескочим унапред. Једну ствар коју желим да приметите, разговарали смо о хардверу, разговарали о САП-у, разговарали о .НЕТ-у, разговарали смо о ЈД Едвардс-у и окружењу Јава-СКЛ Сервер-а. Ово је САП, овде гледамо ПеоплеСофт. Прецизна матрица подршке је широка и дубока. Ако имате апликацију, више је него вероватно да можемо да је инструментирамо како бисмо обезбедили овај ниво видљивости. Једна од највећих промена која се тренутно дешава је мобилност. ПеоплеСофт је представио мобилност својим Флуид УИ. Флуид УИ користи систем различито. Ова апликација се развија. Флуид корисничко сучеље - оно што чини из перспективе управљања јесте да омогућава крајњим корисницима да користе свој телефон и увелике повећава продуктивност. Ако имате стотине или хиљаде или чак више запослених, ако можете повећати њихову продуктивност, за 1-2 процента, можете имати огроман утицај на платне листе и све остало. Оно што се догодило је да је та посебна продавница увела корисничко сучеље ПеоплеСофт Флуид. Сада, говорећи о сложености, ово је ПеоплеСофт стацк. Једна апликација, најмање шест технологија, бројни крајњи корисници. Како да започнете?
Још једном ће Прецизна бити у могућности да прати ове трансакције. Оно што вам овде приказујемо је сложени бар графикон који приказује клијента, веб сервер, Јава, Тукедо базу података, ПеоплеСофт стацк. Зелене мапе на Ј2ЕЕ, што је некако феноменалан начин да се каже ВебЛогиц. Ово је пресек. Крајњи корисници почињу са корисничким сучељем Флуид и време одзива траје отприлике једну и по, две секунде, па све до око девет, десет секунди. Оно што овај екран не приказује је број људи који "не реагују". Заправо се заслон замрзава у апликацији. Погледајмо неке од видљивости које компанија Прецисион може да пружи овом купцу.
Пре свега, када погледам трансакције ПеоплеСофт, они у основи могу видети да смо видели ову врсту ствари широм света. Све трансакције су утицале, као и све локације. Када случајно погледате ово, заправо можете видети локације широм света. Од азијско-пацифичког, па све до Европе као и северне Америке. Проблем са перформансама није био лоциран на одређеној трансакцији или одређеној географској локацији, већ је системски широк. То је на неки начин рећи да је промена или начин на који је Флуид УИ имао утицаја на глобални начин. Овде можете видети са становишта скалабилности, људи покушавају да обављају исту врсту активности, али време одзива у основи је само деградирано и деградирано. Можете да видите да ствари нису у скали. Ствари иду јако, јако лоше. Овде, кад погледам број осе и истодобне везе, видите нешто што је веома интересантно у погледу броја приступа и веза. Овде смо скалирали само до око 5.000, а ви гледате на то, то је више од 100 истодобних веза. То се ради након; ово је пре. Дакле, моја стварна потражња за системом, ако би се та ствар могла проширити, је у распону од 300 000. У стара времена, са класичним корисничким сучељем, имате 30 истодобних веза.
Ово што вам говори је да Флуид УИ користи најмање 10к броја истовремених веза. Почињемо да повлачимо оно што се дешава под корицама са ПеоплеСофтом тако да можете почети да видите утицај на веб сервере, чињеницу да СЛА почињу да се крше. Нећу улазити у све, али оно што се на крају догађа је да се они у основи ослањају на размену порука. Они у основи вежбају ВебЛогиц и изазивају редове чекања унутар Тукеда. Заправо је постојало питање о овисности о вишемјесечном ступњу који се појавио с корисничким сучељем Флуид, али Прецисион је могао показати да се помоћу гомиле различитих ствари можемо фокусирати на оно што је проблем. Испада да је и у самој бази података постојао проблем. Заправо постоји датотека дневника порука и због свих истодобних корисника та датотека дневника се закључала. У основи су се морале прилагодити ствари у сваком нивоу слоја апликација. Разговарајте о сложености, ево заправо Тукедо слој који вам приказује редове чекања и можете видети перформансе које деградирају и унутар овог нивоа. Могао сам да видим процесе; Могао сам да видим домене и сервере. У Тукеду, како би људи то користили, обично оно што радите је да отворите додатне редове, домене и сервере, баш као и у супермаркету за ублажавање загушења, да минимизирате време чекања. Последња и последња опција, Прецисион приказује много информација.
Као што сам већ напоменуо, свака значајна трансакција у интеракцији је са системом записа. Видљивост у бази је најважнија. Прецисион приказује шта се дешава у бази података, у оквиру ВебЛогиц-а, у Јави, .НЕТ-у, у претраживачу, али место које Прецисион заиста истиче је у нивоу базе података. То се догађа као слабост наших конкурената. Дозволите ми да вам покажем један од начина како би Прецисион могао да вам помогне да прођете кроз ово. Нећу трошити време на троугао оптимизације база података, али ми у основи гледамо на промене типа ниског трошка, ниског ризика, широко распрострањених, високо ризичних, високо-коштаних врста. Заправо ћу накнадно цвркутати овај слајд ако људи желе да пробају и погледају га. Мислим да је то прилично велики водич за проблеме са подешавањем. Ево стручног мишљења Прецизног за Орацле. На врху извештаја о налазу, 60% утицај има ова одређена СКЛ изјава. Ако отворите овај екран активности, то ће се показати тамо. Могу да погледам ову селективну изјаву, постоји један план извршења. Свако извршење траје секунду - 48.000 погубљења. То доноси још 48.000 сати погубљења.
Тамноплава је поново ЦПУ. Ова ствар је везана за ЦПУ, а не за стање чекања, а не за дневник. Наглашавам да зато што неки од наших конкурената гледају само на стање чекања и евидентирање догађаја, али генерално гледано, ЦПУ је најпрометније стање извршења и нуди највише откупа. Улазећи у овај стручни поглед - и крећем врло брзо - оно што сам учинио је да погледам таблицу, 100 000 редова, 37 000 блокова. Радимо пуну табелу, а ипак имамо шест индекса о овој ствари. Шта се дешава овде? Па, кад погледам где је клаузула, ово где та клаузула ради јесте то да заправо претвара ступац у велика слова и говори где је једнака великој слици, пронађите променљиву. Оно што се догађа је сваки пут када се ова ствар изврши, Орацле мора претворити ову колону у велика слова. Уместо да то учините готово педесет хиљада пута, много је ефикасније изградити тај индекс у великом тексту индекса који се заснива на функцијама и доступан је не само у одељењу компаније Орацле, већ и стандардној подјели. Када то учините, оно што можете онда је да верификујете извршни план издавањем тог новог индекс корисничког писма великих слова, то је била само једна врста моје ствари.
Затим, из мерења пре и после, гледате време извршења у једној секунди, обједињује до 9 сати 54 минута, са истом тачном СКЛ изјавом, али имајући тај индекс уграђен у велика слова за 58.000 извршења, одговор време пада на суб-милисекунде, агрегирајући се заједно, долази до седам секунди. У основи сам сачувао десет сати ЦПУ-а на свом серверу. Ово је огромно. Јер ако ми није потребно за освежавање сервера, моћи ћу да живим на том серверу. Заправо смањим употребу сервера за 20 посто и заправо можете видјети прије и послије. То је врста видљивости коју Прецисион може да пружи. Постоје и неке додатне ствари на које бисмо могли гледати, зашто имате све ове индексе ако се не користе? Они могу наставити са тим. Постоји архитектура, и ја ћу је закључити, јер смо стигли до врха сата. Ја сам прави верник у ово решење и желимо да будете прави верник. У компанији ИДЕРА верујемо да пробни рад чини купца, тако да ако сте заинтересовани, можемо да извршимо процене на вашој веб локацији.
Са тим, ја ћу проследити светионик.
Ериц Каванагх: Да, ово је био један огроман детаљ који сте тамо показали. Заиста је фасцинантно. Мислим да сам вам раније споменуо да - а знам и у неким другим веб емисијама које смо радили са ИДЕРА-ом, то сам споменуо - заправо пратим Прецизно од пре него што га је ИДЕРА преузела, мислим, све до 2008. године, мислим, или 2009. године. Тада ме је фасцинирала. Занима ме колико посла треба да останемо изнад нових издања апликација. Споменули сте да је САП ХАНА, за коју мислим да је била прилично импресивна да се заправо можете укопати у ХАНА архитектуру и тамо направити неке проблеме. Колико људи имате? Колики је напор са ваше стране и колико се тога може учинити помало динамично, што значи када се алат активира, почнете да се крећете и видите различите ствари? Колико се тога може динамички, некако, утврдити помоћу алата, тако да можете помоћи људима у решавању сложених окружења?
Билл Еллис: Тамо сте поставили пуно питања.
Ериц Каванагх: Знам, извини.
Билл Еллис: Дао сам пуно детаља, јер за ове апликације, гледајући шифру, ђаво је у детаљима. Морате имати тај ниво детаља да бисте заиста могли нешто да примените. Без делотворних метрика, једноставно знате о симптомима. Ви заправо не решавате проблеме. ИДЕРА се бави решавањем проблема. Велики изазов је остати у току са новим издањима и осталим стварима. Питање шта је потребно за то, заиста је за управљање производима. Немам пуно видљивости у тиму који нас у основи прати о стварима. Што се тиче ХАНА, то је заправо нови додатак линији производа ИДЕРА; то је врло узбудљиво. Једна од ствари са ХАНОМ је - допустите ми да разговарам о задатку на секунду. У задатку би САП продавнице радиле да копирају базу података у сврху извештавања. Тада бисте морали да се људи помире са оним што је заправо тренутно. Имали бисте те различите базе података и оне би биле изван синхронизације на различитим нивоима. Постоји само пуно времена и труда, плус хардвера, софтвера и људи који све то одржавају.
Идеја ХАНА-е да има високо паралелну базу података у меморији како би у основи избегла потребу за дуплираним базама података. Имамо једну базу података, један извор истине, она се увек ажурира, на тај начин избегавате потребу да се све то помири. Важност перформанси базе података ХАНА расте - рећи ћу 10к или бар вредније од зброја свих осталих база података, хардвера и ресурса које можете купити. Будући да ће ХАНА моћи да управља, сада је та компонента тренутно у бета тестирању, то ће ускоро постати ГА. То је прилично узбудљиво за ИДЕРА и за нас у основи да подржимо САП платформу. Нисам сигуран које друге дијелове вашег питања сам промијенио, али …
Ериц Каванагх: Не, тамо су све добре ствари. Одбацио сам читаву гомилу одједном, тако ми је жао због тога. Заиста сам фасциниран, стварно, мислим да ово није баш једноставна апликација, зар не? Копате дубоко у ове алате и разумете како они међусобно делују и да бисте схватили ствар, причу морате саставити заједно у својој глави. Морате комбиновати делове информација да бисте разумели шта се заправо догађа и шта вам прави проблеме, тако да можете ући тамо и решити те проблеме.
Један учесник се пита, колико је тешко имплементирати Прецисион? Друга особа се запитала ко су људи - очигледно ДБА - али ко су неке друге улоге у организацији које би користиле овај алат?
Билл Еллис: Прецизно је мало сложеније распоредити. Морате имати неко знање о апликативном окружењу, у смислу, знате, ова апликација ради на овој бази података, треба јој или - средњим нивоима веб сервера итд. Мислим да с обзиром на сложеност неких од ових апликација, заправо је релативно лако. Ако могу да учврстим веб сервер у вашу базу података, то могу радити од краја до краја. Примјећујете да нисам рекао ништа о инструментирању крајњег корисника и зато што оно што радимо је у ствари укључујемо динамички, тако да не морате мијењати свој код или било шта друго. ЈаваСцрипт улази у оквир странице апликације. Без обзира на то где се корисник налази у свету, када приступе УРЛ-у са ваше апликације и спусте ту страницу, долази са инструментом Прецисион. То нам омогућава да одаберемо ИД корисника, њихову ИП адресу, такође и време бајтова првог бајта за свако време извршења скрипте компоненти странице у прегледачу крајњег корисника.
У погледу трансакција, не морате да пресликавате трансакције јер су чврсто повезане. Ова УРЛ адреса постаје улазна тачка за ЈВМ и затим се позива на ову поруку, што резултира тиме да је ЈВЦ ухваћен из базе података. Ми смо у могућности ухватити те природне тачке повезивања и затим вам их представити на том екрану трансакција који сам вам показао где смо такође израчунали колико времена, односно проценат времена које сте провели у сваком појединачном кораку. Све се то врши аутоматски. Генерално гледано, издвајамо још 90 минута - да у основи инсталирамо Прецисион језгру и онда почнемо са имплементацијом апликације. У зависности од знања о апликацији, можда ће нам требати додатне сесије да би се комплетна апликација оперисала. Многи људи користе само компоненту базе података Прецисион. То је у реду. У основи ово можете разбити, поделити на компоненте за које сматрате да вашој веб локацији треба. Дефинитивно верујемо да контекст опремања читавог скупа апликација инструментиран, тако да можете видети да зависност од нивоа до нивоа заправо повећава вредност надгледања појединог нивоа. Ако било ко жели да додатно истражује инструмент за слагање својих апликација, посетите нашу веб локацију - претпостављам да је то најлакши начин да затражите додатне информације, па ћемо мало више о томе расправљати.
Ериц Каванагх: Допустите да вам поставим једно или два брза питања. Претпостављам да током времена прикупљате и стварате спремиште, како за појединачне клијенте, тако и за корпоративни ентитет у целини, интеракција између различитих апликација и различитих база података. Другим речима, претпостављам да сам планирао моделирање сценарија. Је ли то случај? Да ли заиста одржавате неку врсту складишта уобичајених сценарија тако да можете давати предлоге крајњим корисницима када се неке ствари покрену? Попут ове верзије Е-Бусинесс Суите, ове верзије ове базе података итд. - да ли радите много тога?
Билл Еллис: Па, такве информације су уграђене у извјештај о налазима. Извештај о налазу каже која су уска грла у перформансама и заснован је на времену извршења. Део тог извештаја о налазима је сазнање више и шта даље радити. Информације или искуство купаца и тако даље су у основи укључене у ту библиотеку препорука.
Ериц Каванагх: У реду, звучи добро. Па, људи, фантастична презентација данас. Билл, волео сам колико детаља имаш унутра. Само сам мислио да су то заиста фантастичне, мршаве, детаљне информације, које показују како се све ово ради. У одређеном тренутку то је готово као црна магија, али стварно, није. То је врло специфична технологија коју момци саставите да бисте разумели веома, веома сложено окружење и усрећили људе јер нико не воли када се апликације покрећу споро.
Па, људи, ми ћемо архивирати ову веб емисију. Можете скочити на мрежи на Тецхопедиа или инсидеаналисис.цом и вов, хвала на вашем времену, ми ћемо вас контактирати следећи пут. Чувај се, збогом.
