Autorius „Techopedia“ darbuotojai, 2016 m. Lapkričio 2 d
„Takeaway“: Priimančiasis Erikas Kavanaghas aptaria programos veikimą ir kaip padidinti efektyvumą su dr. Robinu Blooru, Dezu Blanchfieldu ir IDERA Billu Ellisu.
Šiuo metu nesate prisijungęs. Jei norite pamatyti vaizdo įrašą, prisijunkite arba prisiregistruokite.
Ericas Kavanaghas: Ponios ir ponai, sveiki ir dar kartą pasveikinkite „Hot Technologies“. Taip išties! Mano vardas Ericas Kavanaghas, aš būsiu jūsų viešnagė dar vienai internetinei transliacijai šioje tikrai įdomioje, įdomioje serijoje, kurią gavome kaip komplimentą mūsų „Briefing Room“ serijai. Pavadinimas yra „Programos pagreitis: greitesnis našumas galutiniams vartotojams“. Eik, žmonės, kas to nenori? Jei aš esu tas vaikinas, kuris padeda jūsų programai veikti greičiau, aš galvoju, kad esu tas vaikinas, kuris po darbo bare gauna man alaus. Įvažiuoti ir pagreitinti bet kurio asmens prašymą turi būti gana šaunus dalykas.
Yra jūsų skaidrių apie jus tikrai, paspauskite mane į Twitter @Eric_Kavanagh. Visada stengiuosi sekti ir visuomet persirašau, jei jūs minite mane, todėl nedvejodami paminėkite mane.
Visas šio pasirodymo tikslas yra sutelkti dėmesį į įvairius įmonės technologijos aspektus ir tikrai padėti apibrėžti tam tikras disciplinas ar veidus, jei to norėsite. Daugybę kartų pardavėjai rinksis tam tikras rinkodaros sąlygas ir kalbės apie tai, kaip jie daro tą ar tą ar kitą dalyką. Šis pasirodymas iš tikrųjų buvo skirtas padėti mūsų auditorijai suprasti, ko reikia programinės įrangos įrankiui, norint būti savo erdvės lyderiu. Tai yra du analitikai. Kiekvienas eina pirmas, skirtingai nei informacinis kambarys, kuriame pardavėjas eina pirmas. Kiekvienas iš jų pasirenka tai, kas, jų manymu, svarbu žinoti apie tam tikros rūšies technologijas.
Šiandien mes kalbame apie taikymo spartinimą. Mes išgirsime iš Dezo Blanchfieldo ir gydytojo Robino Blooro - mes šiandien esame visame pasaulyje - ir tada Bill Ellis skambina iš didesnės Virdžinijos srities. Turėdamas tai perduosiu pirmajam mūsų pranešėjui dr. Bloor. Mes, beje, tvitrėme žymą apie #podcast, todėl drąsiai tweet. Pašalink.
Dr Robin Bloor: Gerai, gerai, ačiū už įvadą. Programų našumas ir aptarnavimo lygiai - tai savotiška sritis, per daugelį metų šioje srityje nuveikiau daug, ta prasme, kad iš tikrųjų nuveikiau nepaprastai daug darbo, stebėdamas našumą ir dirbdamas viename. būdas išbandyti ir apskaičiuoti tuos lygius. Reikia pasakyti, kad iki tol - anksčiau, kai buvo ši era, žmonės statė silosuose sistemas. Iš esmės darbas, kurį jie iš tikrųjų turi atlikti, kad sistema veiktų pakankamai gerai, jei ji buvo siloso srityje, iš tikrųjų nebuvo per sunkus, nes yra labai mažai, labai mažai kintamųjų, į kuriuos reikėjo atsižvelgti. Kai tik mes tinkamai sujungėme tinklą, interaktyvumas ir orientacija į paslaugas pateko į lygtį. Tai pasidarė šiek tiek sunku. Spektaklis gali būti vienmatis. Jei jūs tiesiog galvojate apie programą, kuri pakartotinai vykdo tam tikrą kodo kelią, tai darydami pagrįstai ir laiku, jaučiatės kaip vienmatis dalykas. Kai tik pradedate kalbėti apie paslaugų lygius, jūs iš tikrųjų kalbate apie kelis dalykus, konkuruojančius dėl kompiuterio išteklių. Jis labai greitai tampa daugialypis. Jei pradedate kalbėti apie verslo procesus, verslo procesus galima sujungti iš kelių programų. Jei kalbate apie į paslaugas orientuotą architektūrą, tada tam tikra programa iš tikrųjų gali pasiekti kelių programų galimybes. Tada tai tampa labai sudėtingu dalyku.
Pažiūrėjau - seniai piešiau šią schemą. Ši schema yra bent 20 metų. Iš esmės aš tai vadinu Viskas diagrama, nes tai būdas pažvelgti į viską, kas egzistuoja IT aplinkoje. Tai iš tikrųjų tik keturi elementai: vartotojai, duomenys, programinė ir techninė įranga. Žinoma, laikui bėgant jie keičiasi, bet jūs iš tikrųjų suprantate, kai pažvelgiate į tai, kad kiekviename iš šių kūrinių yra hierarchinis sprogimas. Techninė įranga taip, aparatinė įranga gali būti serveris, tačiau serverį sudaro galbūt keli procesoriai, tinklo technologija ir atmintis, ir tai, be abejo, labai daug valdiklių. Jei iš tikrųjų tai pažvelgiate, viskas suskaidoma į dalis. Jei iš tikrųjų galvojate apie tai, kad bandote suorganizuoti visa tai, atsižvelgiant į duomenis, kurie keičiasi, keičiasi programinės įrangos našumas, nes keičiasi aparatinė įranga ir panašiai ir panašiai, jūs iš tikrųjų žiūrite į neįtikėtinai sunkią įvairialypę situaciją. Tai yra sudėtingumo kreivė. Be abejo, tai yra beveik visko sudėtingumo kreivė, bet aš ne kartą mačiau, kaip tai piešia, kalbėdama apie kompiuterius. Iš esmės, jei įdėsite mazgus ant vienos ašies, o svarbius ryšius - ant kitos ašies, sudarysite sudėtingumo kreivę. Beveik nesvarbu, kokie mazgai ir jungtys yra, ir tai darys, jei norite parodyti telefono tinklo apimties augimą.
Tiesą sakant, kai kalbate apie mazgus kompiuterio aplinkoje, jūs kalbate apie atskirus dalykus, kurie rūpi vienas kitam. Pasirodo, sudėtingumas yra įvairovės struktūros ir įvairių suvaržymų, kuriems bandai paklusti, klausimas. Taip pat ir skaičiai. Kai skaičiai didėja, jie klysta. Vakar buvo įdomus pokalbis, aš kalbėjau su kažkuo - negaliu paminėti, kas jis buvo, bet tai visiškai nesvarbu - jie kalbėjo apie svetainę, kurioje buvo 40 000 - tai yra keturi nuliai, 40 000 - duomenų bazių egzemplioriai. svetainėje. Tik pagalvok apie tai - 40 000 skirtingų duomenų bazių. Žinoma, vienintelis dalykas, kurį turėjome - jie, be abejo, turėjo daug, daugybę tūkstančių paraiškų. Mes kalbame apie labai didelę organizaciją, bet aš to negaliu įvardinti. Jūs iš tikrųjų žiūrite į tai ir iš tikrųjų bandote vienaip ar kitaip gauti paslaugų, kurios bus tinkamos visiems vartotojams, lygius su keliais skirtingais, jei norite, lūkesčiais. Tai sudėtinga situacija, ir aš tik sakau, kad tai sudėtinga medžiaga. Skaičiai visada didėja. Apribojimus lemia verslo procesai ir verslo tikslai. Jūs būsite pastebėję, kad lūkesčiai keičiasi.
Prisimenu, kai tik atsirado „Gmail“, „Yahoo“ ir „Hotmail“, visos tos pašto sistemos, žmonės pradėjo tikėtis, kad organizacijos vidaus pašto sistemos bus vertos šių didžiulių operacijų paslaugų lygio su didžiuliais serverių ūkiais už jos ribų organizacijai ir buvo pradėta daryti spaudimą, kad viskas įvyktų. Tiesą sakant, paslaugų lygio susitarimai yra vienas dalykas, tačiau lūkesčiai yra kitas dalykas ir jie kovoja vieni su kitais organizacijos viduje, nepatogus dalykas. Čia tik verslo perspektyva. Kai kuriose sistemose optimalus reagavimo laikas yra viena dešimtoji žmogaus reakcijos laiko sekundės. Vieną dešimtąją sekundės dalį reikia laiko, kai kobra jus įkando. Jei stovi priešais kobrą ir ji nusprendžia tave įkąsti, jau yra per vėlu, tai įvyks, nes tu negali atsakyti per vieną sekundės dešimtąją dalį. Viena dešimtoji sekundės dalis yra susijusi su laiku, per kurį kamuolys palieka krūvelės ranką ir pasiekia vyruką su šikšnosparniu. Iš esmės, pamatęs mestą kamuolį, jis turi atsakyti tiksliai tuo metu. Žmogaus reakcija, savotiškai įdomus dalykas. Programinė įranga gali neabejotinai kelti didesnius lūkesčius.
Tuomet patenki į kai kurias situacijas, kurios, manau, yra tos rinkos situacijos, kai buvimas pirmas yra ten, kur yra verslo vertė. Tai panašu į tai, jei norite parduoti tam tikrą vertybinių popierių biržoje turbūt mažiau, pavyzdžiui, todėl, kad, jūsų manymu, mažėja ir daug kitų žmonių mano, kad mažėja, jūs gaunate geriausią kainą, jei pateksite į rinką pirmiausia. Yra daugybė situacijų, skelbimų pateikimas ir panašūs dalykai, labai panaši situacija. Šis judėjimas jūsų laukia atsižvelgiant į paslaugų lygio lūkesčius. Jūs turite vieną dalyką, tai yra tam tikras stiklo lubas, skirtas žmogaus reakcijai. Jei tai yra programinė įranga, jei nėra tokios viršutinės situacijos, tada nėra geriausio aptarnavimo lygio. Greičiau nei visi kiti yra geriausi.
Gerai, kad, manau, tai yra paskutinė skaidrė, kurią aš padariau, bet tai tik tam, kad pateiktumėte puikų sudėtingumo vaizdą, kai iš tikrųjų atsižvelgsite į organizacijos reikalavimus, paslaugą. Eidami aukštyn kairiąja puse, jūs turite sistemos valdymą, tai yra programinės įrangos, kuri naudojama paslaugų valdymui, rinkinys, kuris bando valdyti paslaugų lygį. Be to, jūs turite verslo veiklos valdymą. Jei pažvelgtumėte į apačią, paslaugų valdymo automatizavimo sritį, gautumėte suskaidytas paslaugas, kurios virsta standartizuotomis paslaugomis, jei iš tikrųjų norite investuoti į tokį dalyką, kuris virsta integruotomis paslaugomis, kurios virsta optimizuotomis paslaugomis. . Dažniausiai tai, ką žmonės padarė, yra tik apatiniame kairiajame šio kampo kampe. Gal šiek tiek paslaugų valdymo. Verslo veiklos valdymas, labai retas atvejis. Suskaidytas, beveik visas. Tobulas pasaulis užpildytų tą tinklelį. Instrumentuotė - paminėjau sub-optimizavimo problemą. Galite optimizuoti sistemos dalis, ir tai nėra gerai visai sistemai. Jei padarysite širdį optimalų, jūsų kraujas gali cirkuliuoti per greitai likusiems jūsų organams. Tai yra didelių organizacijų ir paslaugų lygių problema. Aišku, nieko nebus pasiekta be modernių įrankių, nes kintamieji ką tik įsisavinti - kintamųjų yra per daug, kad juos būtų galima optimizuoti.
Tai pasakęs, aš perduosiu Dezui, kuris, tikiuosi, pakalbės apie ką nors kitą.
Dez Blanchfield: Ačiū, Robinai . Kaip ir daktaras Robinas Blooras, aš per daug metų praleidau galvodamas apie labai sudėtingų sistemų veikimą labai dideliu mastu. Tikriausiai ne visai tokios pačios apimties kaip Robinas, tačiau spektaklis yra kasdienė tema ir mūsų DNR dalis - norėti pasirodymo, kuo geriau išnaudoti viską. Tiesą sakant, aš panaudojau vieno iš mano mėgstamiausių dalykų pasaulyje, „Formulės I“ automobilių lenktynių, grafiką, kuriame visa planeta kurį laiką sėdi ir stebi, kaip automobiliai labai greitai sukasi ratu. Kiekvienas „Formulės I“ aspektas nėra susijęs su spektaklio pasiekimu. Daugelis žmonių sportuoja, nes mano, kad tai yra pinigų švaistymas. Pasirodo, kad automobilis, kuriuo mes važinėjame kiekvieną dieną, kad savaitgaliais nustumtų vaikus į futbolą, o kitas dienas - į mokyklą, yra gautas remiantis rezultatais pagrįstu tobulinimu ir tyrimais. Tai yra toks „Formulės I“ automobilių lenktynių gyvenimas. Kasdieninės technologijos, kasdienis mokslas dažnai kyla iš to, kas mėgstama tik dėl aukšto našumo.
Tačiau realybė yra tokia, kad mūsų naujasis „visada įjungtas“ pasaulis, kuriam reikalingas 100 procentų veikimo laikas - kaip jau minėjo Robinas anksčiau - su tokiais dalykais kaip internetinio pašto ir kitų paslaugų, kurias mes laikome savaime suprantamu dalyku, nepertraukiamoje erdvėje, įgyvendinimas, ir mes dabar tikimės, kad mūsų įmonė ir darbo aplinka. Realybė yra tai, kad buvimas ne visada reiškia, kad įvykdote savo paslaugų lygio susitarimą. Aš manau, kad tai yra poreikis valdyti programų našumą ir pasiekiamumo paslaugų lygio susitarimus pastarąjį dešimtmetį įvyko esminis pokytis. Mes nebesistengiame tik nerimauti dėl vienos sistemos veikimo. Kai pasaulis buvo šiek tiek paprastesnis, galime susidurti su situacija, kai vieną serverį, kuriame teikiamos kelios paslaugos, galima stebėti tiesiogiai ir tai buvo gana paprasta palaikyti. Galėtume - ir štai mano maža, dalykai, dėl kurių mes, pavyzdžiui, prieš daugelį metų, būdami sistemos administratoriais, jaudinomės, apsižvalgytume, ar paslauga paprastai yra atsakinga? Ar galiu prisijungti, pavyzdžiui, prie terminalo? Ar operacinė sistema reaguoja ir ar galiu įvesti komandas? Ar programos veikia ir veikia? Ar galiu pamatyti procesus ir atmintį atliekant veiksmus ir I / O tinkle ir pan.? Didžiųjų kompiuterių dienomis galėjai girdėti, kaip juostos užtrauktuku užtraukiamos, o popierius iš jų iškrenta.
Ar programos reaguoja ir ar galime prisijungti ir daryti su jomis susijusius veiksmus? Ar vartotojai gali prisijungti prie kai kurių serverių? Tęsiasi. Jie yra gana pagrindiniai, žinote. Tada kelios juokingos - ar pagalbos tarnyba yra žalia? Nes jei ne, tada viskas klostosi gerai, o kas gaus spurgas? Tais laikais gyvenimas buvo tikrai paprastas. Net ir tais laikais, ir tada aš kalbu su 20–30 metų, sudėtingumas vis dar buvo tikrai didelis. Galėtume gana paprastai valdyti paslaugų lygio susitarimus ir nuolat stebėti veiklą. Mes to nebegalime padaryti ranka, kaip užsiminė Robinas. Iššūkis per didelis. Faktas yra laikas, kai kelios geros programos, administratoriai, sistemos tinklas ir duomenų bazė, administratoriai gali stebėti ir patenkinti našumo SLA. Dabar SLA nebėra tiek, kad aš kovojau praėjusią naktį, kai buvau sudėjęs savo paskutinius užrašus, kad net pagalvočiau apie metus, kai paskutinį kartą man pavyko pažvelgti į labai sudėtingą kamino sistemą, įprasminti ją ir net suvokti, kas buvo vyksta po gaubtu, o aš kilęs iš giliai techninės aplinkos. Aš neįsivaizduoju, kaip tai kasdien susidurti su administracine tvarka.
Kas nutiko? Na, o 1996-aisiais duomenų bazės valdomos programos buvo pakeistos interneto bumu. Daugelis iš mūsų tai išgyvenome. Net jei jums nebuvo interneto bumo, galite lengvai tiesiog apsižvalgyti ir suvokti, kad kasdieniame gyvenime viską prikabiname prie interneto. Manau, kad turime skrudintuvą, kuris, matyt, yra su galimybe prisijungti prie „Wi-Fi“, o tai yra juokinga, nes man nereikia mano skrudintuvo, prijungto prie interneto. 2000-aisiais, ypač 2000-ųjų pradžioje, mes turėjome įveikti šį didžiulį sudėtingumo augimą, teikdami „dot-com“ bumo paslaugas. Tada atsirado dar viena juokinga nepatogi kibirkštis „web 2.0“, kur atsirado išmanieji telefonai ir dabar programos buvo mūsų rankose visą parą ir visą laiką.
Dabar yra 2016 metai, mes susiduriame su dar vienu debesų, didelių duomenų ir mobilumo pavidalu. Tai yra sistemos, kurių dydis yra toks didelis, kad jas dažnai sunku suprasti ir išdėstyti paprasta anglų kalba. Kai mes galvojame apie tai, kad kai kurie dideli vienaragiai, apie kuriuos mes kalbame, turi dešimtis šimtų petabaidų duomenų. Tai yra visas disko aukštas ir saugykla, skirta laikyti tik jūsų el. Paštą, vaizdus ir socialinę terpę. Arba kai kuriais atvejais transporto ir gabenimo logistikoje viskas vyksta bankininkystėje, ten, kur yra jūsų pinigai, ar yra jūsų paštas, arba jūsų, kur yra dalykas, kurį nusipirkote „eBay“. Kita didžiulė banga, su kuria susidursime, yra šis labai sunkus daiktų interneto iššūkis.
Jei tai nebuvo pakankamai blogai, dirbtinį intelektą ir kognityvinį skaičiavimą ruošiamės pritaikyti beveik viskam. Šiomis dienomis kalbamės su „Siri“ ir „Google“ varikliais. Aš žinau, kad „Amazon“ turi savo. „Baidu“ turi vieną iš šių įrenginių, su kuriais galite kalbėti, jie konvertuoja jį į tekstą, kuris patenka į įprastą sistemą, duomenų bazė sukuria užklausą ir grįžta atgal. Pagalvokite apie sudėtingumą, kuris patenka į tai. Realybė yra tokia, kad šiandieninio standartinio programų paketo sudėtingumas yra daug didesnis nei žmogaus galimybės. Kai galvojate apie viską, kas nutinka, kai paspaudžiate mygtuką savo išmaniojo telefono įrenginyje ar planšetiniame kompiuteryje, jūs kalbate su juo, konvertuojate jį į tekstą, paleidžiate visą internetą į foninę sistemą, „front-end“ gauna kad paverčia ją užklausa, vykdo užklausą per programų rinkinį, eina per duomenų bazę, peržiūri diską, išeina atgal, o viduryje yra nešiklio tinklas, yra vietinio tinklo būsenos centras. Sudėtingumas yra beprotiškas.
Mes iš tikrųjų tvirtiname, kad tai yra hiperskalė. Hiperskalės sudėtingumas ir greitis yra tik akių laistymas. Taikomosios programos ir duomenų bazės tapo tokios didelės ir tokios sudėtingos, kad efektyvumo valdymas iš tikrųjų yra savaime suprantamas dalykas. Daugelis tai vadina raketų mokslu. Mes turime vietoje esančią technologiją, mes turime už jos ribų esančią technologiją, turime daugybę duomenų centro parinkčių; fizinis ir virtualus. Mes turime fizinius ir virtualius serverius, debesis, infrastruktūrą, kaip paslaugą, ir platformą, kaip paslaugą, o programinę įrangą, kaip paslaugą, dabar laikome savaime suprantamu dalyku. Pastaroji, programinė įranga, kaip paslauga, prieš kelerius metus tapo gąsdinanti, kai CFO ir organizacijos dalys suprato, kad gali pasiimti kreditinę kortelę ir tiesiog nusipirkti daiktus patys, apeiti CIO, ir mes tai efektyviai vadinome „šešėliu“. IT “ir CIO dabar bando panaikinti šią problemą ir sugriauti kontrolę.
Infrastruktūroje mes turime programinės įrangos apibrėžtą tinklą, tinklo funkcijų virtualizavimą, žemiau to, ko gero, jau turime, dabar turime mikro paslaugas ir aktyvių paslaugų programas. Kai spustelite URL, to URL gale yra daugybė verslo logikos, apibūdinančios, ko reikia, kad ją iš tikrųjų pateiktų. Tai nebūtinai turi iš anksto sukonstruotos logikos. Vienoje pusėje yra tradicinės duomenų bazės, kurių mastelis yra labai didelis. Mums labai patinka „Hadoop“ infrastruktūra ir kito spektro ekosistemos, kurios yra tiesiog tokios didelės, kad, kaip jau sakiau, žinote, dabar žmonės kalba apie šimtus petabitų duomenų. Dėl mobiliųjų įrenginių, nešiojamųjų kompiuterių, telefonų ir planšetinių kompiuterių, mobilumas yra sudėtingas.
Mes turime BYOD kai kuriose uždarose vietose ir vis labiau dabar, nes „Gen Y“ patyrę žmonės atsineša savo prietaisus. Mes tiesiog leidome jiems kalbėti su jais apie interneto sąsajas. Arba internetu, arba per „Wi-Fi“, mes turime nemokamą belaidį internetą kavinėje apačioje, nes jie geria kavą. Arba mūsų vidinis „Wi-Fi“. Dabar mašina yra mašina. Tai nėra tiesiogiai daiktų interneto dalis, bet ji taip pat susijusi. Daiktų internetas yra visiškai naujas sudėtingumo žaidimas, kuris protu nesuvokiamas. Dirbtinis intelektas ir jei manote, kad tai, ką mes žaidžiame dabar, su visais „Siri“ ir kitais susijusiais prietaisais, su kuriais mes kalbamės, yra sudėtinga, palaukite, kol pamatysite situaciją, kai pamatysite kažką, vadinamą Olli, kuris yra 3D atspausdintas autobusas, kuriame važinėja maždaug šeši žmonės ir kuris gali važiuoti pats po miestą, o jūs galite kalbėti paprasčiausiai angliškai ir jis susikalbės. Jei jis pateks į eismą, jis nuspręs pasukti į kairę arba dešinę nuo pagrindinės zonos, kurioje yra eismas. Kai pasisuksite ir susijaudinę, kodėl pasukote į kairę ar dešinę nuo pagrindinio kelio, jis jums pasakys: „Nesijaudinkite, aš ruošiuosi pasukti į kairę. Ateina eismas ir aš eisiu aplink jį “.
Tvarkyti visų ten esančių sistemų našumą ir sudėtingumą, sekti, kur eina šie duomenys, ar jie patenka į duomenų bazę, ar visi sujungimai ir visi atitinkami bitai yra tiesiog protas. Realybė yra tokia, kad norint valdyti našumą ir SLA šiuolaikiniu greičiu ir mastu, reikia įrankių ir sistemų, o pagal nutylėjimą tai jau nėra kažkas, kur, jūsų manymu, būtų malonu turėti įrankį - tai būtina sąlyga; tai tiesiog būtina. Tai yra tik nedidelis pavyzdys, kuriame pateiktas aukšto lygio programų projektavimo schemų sąrašas, skirtas OpenStack, atvirojo kodo programinės įrangos apibrėžtam debesiui. Tai tik didelis gabalas. Tai ne tik serveriai ir duomenų bazė. Čia kiekviena maža mėlyna dėmelė žymi daiktų grupes. Kai kuriais atvejais veikia failai ir serveriai ar šimtai duomenų bazių arba, žinoma, ne daugiau kaip dešimtys tūkstančių mažų programų logikos vienetų. Tai maža versija. Kai tikrai pradedate galvoti apie sudėtingumą, kuris kyla iš to, tai visiškai nesupranta. Šiandien net didelėje duomenų erdvėje tiesiog įdėsiu keletą prekės ženklų ekrano kopijų. Kai galvojate apie visus dalykus, kuriuos turime čia valdyti, mes kalbame ne tik apie vieną prekės ženklą - tai visi prekės ženklai, esantys dideliame duomenų peizaže ir svarbiausias prekės ženklas, ne tik kiekvienas mažas ar atviras šaltinis. Jūs žiūrite ir manote, kad tai gana nesąmoninga diagrama.
Pažvelkime tik į porą vertikalių. Paimkime, pavyzdžiui, rinkodarą. Čia yra panaši diagrama, tačiau iš technologinių krūvių, kurias galima rasti tik rinkodaros technologijose. Tai yra 2011 m. Štai 2016 metų versija. Tik pagalvok, tai tik prekių ženklų skaičius produktų, kuriuos gali naudoti technologijoms, atsižvelgiant į rinkodaros technologijas. Ne ten esančių sistemų sudėtingumas, ne skirtinga programa ir žiniatinklis, plėtra ir tinklas bei visos kitos. Tiesiog prekės ženklas. Yra anksčiau, prieš penkerius metus ir štai šiandien. Tai tik blogės. Dabar esame ten, kur yra tikrovė, žmonės tiesiog negali užtikrinti visų paslaugų lygio susitarimų. Negalime pasinerti į pakankamai detales, pakankamai greitai ir tokiu mastu, kokio reikia. Štai pavyzdys, kaip dabar atrodo stebėjimo pultas. Tai yra tarsi beveik dvidešimt keistų ekranų, suklijuotų apsimetant, kad jie yra vienas puikus, didelis, projektuojamas ekranas, stebintis kiekvieną mažą detalę. Dabar čia įdomu, neminėsiu prekės ženklo, tačiau ši stebėjimo platforma stebi vieną taikymą logistikos ir gabenimo aplinkoje. Tik viena programa. Jei pamąstytumėte apie tai, apie ką kalbėjo Robinas, kai organizacijos gamybos aplinkoje dabar gali turėti 40 000 duomenų bazių. Ar galite tiesiog įsivaizduoti, kokios galėtų būti 40 000 šios ekranų kolekcijos, stebinčios vieną programą, versijų? Tai labai drąsus pasaulis, kuriame gyvename. Kaip sakė Robinas ir aš visiškai, 100 proc. Pakartosiu, kad be tinkamų įrankių, be tinkamos atramos ir liaudies ant stalo naudojant šias priemones programos vykdymas yra prarastas žaidimas žmonėms ir tai turi padaryti įrankiai ir programinė įranga.
Su tuo aš perduosiu mūsų draugams IDERA.
Ericas Kavanaghas: Gerai, Bill.
Billas Ellisas: Ačiū. Dalinuosi mano ekranu čia. Manau, kas nors gali patvirtinti, kad matai mano ekraną?
Dr Robin Bloor: Taip.
Ericas Kavanaghas: Atrodo, viskas gerai.
Billas Ellisas: Ačiū. Vienintelis dalykas, kurį jis paminėjo, aš tikrai negaliu laukti, kad tai buvo pats važiuojantis automobilis. Vienas dalykas, apie kurį negirdėjau, kad kažkas kalbėtų, yra tai, kas nutinka, kai sninga? Man įdomu, ar Kalifornijos inžinieriai suprato, kad kitose šalies vietose sninga.
Dezas Blanchfieldas: Man tai patinka, aš prisiminsiu tą.
Erikas Kavanaghas: Įprasta mylia per valandą.
Billas Ellisas: Mes čia norime kalbėti apie programų našumo valdymą sudėtingoje aplinkoje. Vienas dalykas, apie kurį man patinka kalbėti, yra tai, kad daug žmonių, kalbėdami apie našumą, yra tokios reakcijos pobūdis: daugiau serverių, daugiau procesorių, daugiau atminties ir tt. Kita tos monetos pusė yra apdorojimo efektyvumas. Tikrai tai yra dvi tos pačios monetos pusės ir pažiūrėsime į jas abi. Pagrindinis tikslas yra įvykdyti paslaugų lygio susitarimus dėl verslo operacijų. Galiausiai visa ši technologija egzistuoja verslui. Kalbėjome apie tai, kad turėtume pirmą pramonėje veiklos valdymo duomenų bazę. Idealiausia yra tilpti į idealų atlikimo modelį ir valdyti jį nuo programos gyvavimo ciklo pradžios.
Temos iš tikrųjų susideda iš keturių dalių; vienas yra veiklos valdymo procesas. Mes kalbėjomės su visais, ir visi turi įrankius. Jei jie neturi įrankių, jie turi scenarijus ar komandas, tačiau jiems trūksta konteksto. Kontekstas yra tiesiog taškų sujungimas per programų krūvas. Šios - skirtos naršyklėms. Jie yra labai sandariai sujungti iš pakopos į pakopą. Taip pat labai svarbu, kaip pakopos sąveikauja. Tada mes kalbame apie verslo sandorį. Mes suteiksime matomumą ne tik techniniams žmonėms, bet ir programų savininkams bei operacijų valdytojams.
Turiu keletą pavyzdžių, norėčiau tiesiog pasidalyti su jumis, kaip klientai juos panaudojo. Tai labai praktiška pranešimo dalis čia. Pažvelkime į tai, kas paprastai atsitinka. Man patinka schema - tai buvo tiesiog neįtikėtinas technologijų koliažas. Technologijų skaičius duomenų centre tiesiog augo ir augo, ir augo. Tuo tarpu galutiniam vartotojui tai nerūpi ir jis to nepastebi. Jie tiesiog nori vykdyti operaciją, jei ji bus prieinama, greitai ją įvykdyti. Paprastai nutinka taip, kad IT specialistai nežino, kad galutiniams vartotojams kilo problema, kol jie patys nepraneša. Tai pradeda daug laiko reikalaujantį, lėtą procesą ir dažnai varginantį. Kas atsitiks, žmonės atidarys savo įrankius ir pažiūrės į jų programų rinkinio pogrupį. Turint tą pogrupį, tampa labai sunku atsakyti į paprasčiausią klausimą. Ar jums įprasta susidurti su problema? Koks tai sandoris? Kur taikymo kampe yra trūkumų? Praleidę visą šį laiką, ieškodami pakopos ir negalėdami atsakyti į šiuos klausimus, jūs sugaištate daug laiko ir energijos, daug personalo, lėšų ir energijos.
Norėdami išspręsti šią problemą, siekdami pateikti geresnį būdą, ką „Precise“ iš tikrųjų imasi galutinio vartotojo stebėjimo operacija, fiksuoja jos metaduomenis, seka operaciją per tinklą, į interneto serverį, verslo logikos pakopą ir mes palaikome .NET ir ABAP bei PeopleCode ir E-Business Suite daugiapakopėse programose, kurios galiausiai visos operacijos sąveikauja su įrašų sistema. Nesvarbu, ar tai atsargų peržiūra, ar ataskaitinis laikas dirbtas, jie visada sąveikauja su duomenų baze. Duomenų bazė tampa verslo rezultatų pagrindu. Savo ruožtu duomenų bazė remiasi saugojimu. Kokius atsakymus pateikia operacijų metaduomenys, kas, kokia operacija, kur yra programų paketas, tada mes matome gilų kodo lygio lygį, kad parodytume, kas vykdoma. Ši informacija nuolat kaupiama, kaupiama spektaklio valdymo duomenų bazėje. Tai tampa vienu muzikos lapu, kad visi galėtų pamatyti, kas vyksta. Yra skirtingi žmonės ir organizacijos, kuriems rūpi, kas vyksta: technikos ekspertai, programų savininkai, galų gale, pats verslas. Atsiradus problemai, jūs norite gauti informaciją apie tą operaciją.
Prieš pradėdami nagrinėti investavimo operaciją, noriu jums parodyti, kaip tai gali pasirodyti skirtingiems organizacijos žmonėms. Valdymo pakopoje galite turėti kelių programų apžvalgą. Galbūt norėsite žinoti apie sveikatą, kurią apskaičiuoja atitikimas SLA ir prieinamumas. Ši sveikata nereiškia, kad viskas šimtu procentų veikia nepriekaištingai. Šiuo atveju nėra vietos, matote, kad investuojanti operacija yra įspėjančiojoje būsenoje. Dabar truputį giliau, galbūt, verslo srityje norėtumėte gauti papildomos informacijos apie atskirus sandorius, kai jie pažeidžia SLA, operacijų skaičių ir tt. Operacijų komanda norės apie tai būti informuota perspėjant kai kuriuos asmenis. rūšiuoti. Mes turime integruotus įspėjimus apie našumą. Mes iš tikrųjų įvertiname našumą galutinio vartotojo naršyklėje. Nesvarbu, ar tai „Internet Explorer“, „Chrome“, „Firefox“ ir kt., Kuriuos mes galime aptikti, tai atsakys į pirmąjį klausimą: ar galutinis vartotojas turi problemų?
Pasinerkime ir pažiūrėkime, ką dar galime parodyti. Žmonės, kurie domisi spektakliu, atvertų „Precise“. Jie įvertino operacijas. Jie pažiūrėjo į SLA stulpelį, kad nustatytų operacijas, kurios neatitiko SLA. Jie galės pamatyti galutinius vartotojus, kuriems padaryta įtaka, ir tai, ką ši operacija padarė, kai ji vyko visoje programoje. Šių hieroglifų iššifravimo būdas yra naršyklė, URL, U yra URL, tai yra įėjimo į JVM taškas. Dabar šis JVM verčia interneto serverį antrajam JVM, kuris tada vykdo SQL. Aišku, tai yra duomenų bazės problema, nes šis SQL teiginys buvo atsakingas už 72 procentus atsakymo laiko. Mes orientuojamės į laiką. Laikas yra įvykdymo valiuta. Tai, kaip galutiniai vartotojai patiria, ar viskas vyksta lėtai, ar ne, ir tai yra išteklių suvartojimo matas. Tai labai patogu; tai yra vieninga metrika, kuri yra svarbiausia vertinant našumą. Kai ši problema perduodama DBA, tai nėra tik duomenų bazės problema, tai yra šis SQL teiginys. Tai yra kontekstas, apie kurį aš kalbėjau.
Dabar apsiginklavęs šia informacija gebu įeiti ir išanalizuoti, kas nutiko. Pirmiausia matau, kad y ašis yra laikas per dieną. Atsiprašau, y ašis yra reakcijos laikas, x ašis yra laikas per dieną. Matau, kad yra duomenų bazės problema, yra du atvejai, grįžkite į tą srautą, pasiimkite tą SQL teiginį ir eikite į ekspertų vaizdą, kur „Precise“ gali parodyti, kas vyksta, jo valdiklius, kiek laiko užtrunka šis kodas. vykdyti. Duomenų bazės pakopoje tai vykdymo planas. Atkreipkite dėmesį, kad Tikslus atrinko realų vykdymo planą, kuris buvo naudojamas vykdymo metu, kuris skiriasi nuo numatomo plano, kuris būtų tada, kai planas buvo duotas, o ne vykdymo metu. Tai gali atspindėti arba neatspindėti, kad duomenų bazė iš tikrųjų tai padarė.
Dabar čia yra SQL sakinio reakcijos laiko analizė. Devyniasdešimt procentų laiko, praleisto sandėlyje; dešimt procentų buvo panaudota procesoriuje. Aš galiu pamatyti SQL teiginio tekstą ir išvadų ataskaitą. SQL teiginio tekstas iš tikrųjų pradeda atskleisti kai kurias kodavimo problemas. Tai yra žvaigždutė; kuris grąžina visas eiles - atleisk, visus stulpelius iš eilučių, kurios buvo grąžintos. Grįžtame prie papildomų stulpelių, kurių gali prireikti programai. Tie stulpeliai sunaudoja erdvę ir resursus apdoroti. Jei paleidžiate SAP, vienas didžiausių pakeitimų, nes HANA duomenų bazė yra stulpelinė, yra tas, kad iš esmės perrašydami SAP nepasirinksite pažymėtos žvaigždės, kad jie galėtų žymiai sumažinti išteklių sunaudojimą. Iš esmės tai nutinka daug laiko ir namuose auginamose programose, pavyzdžiui, „Java“, .NET ir kt.
Tame ekrane parodoma kas, ką, kada, kur ir kodėl. Kodėl taip yra, pavyzdžiui, SQL sakinys ir vykdymo planas, leidžiantis išspręsti problemas. Kadangi „Precise“ veikia nuolat, iš tikrųjų galite išmatuoti prieš ir po SQL sakinio, operacijų lygiu, taigi galite įvertinti ir patys, ir per programų savininkus, ir valdydami, kad išsprendėte problemą. . Ta dokumentacija tikrai naudinga. Šis programų paketas yra labai sudėtingas. Iš daugelio programų iš tikrųjų visi, su kuriais mes kalbėjome, palaiko bent dalį programų krūvos naudodami „VMware“. Tokiu atveju jie žiūri į klientų aptarnavimo programą, peržiūri operacijos laiką ir susieja jį su sulėtėjimu yra virtualizacijos įvykis. Tiksliai seka visus virtualizacijos įvykius. Mes turime „vCenter“ papildinį, kad galėtume jį pasirinkti.
Mes taip pat galime nustatyti ginčus. Tvirtinimas skiriasi nuo panaudojimo. Faktiškai parodoma, kada galbūt triukšmingas kaimynas daro įtaką jūsų svečiam VM, atsižvelgiant į kliento serverio programą. Dabar aš galiu išsiaiškinti ir gauti informaciją bei iš tikrųjų galiu pamatyti du virtualiuosius aparatus, kurie šiuo atveju konkuruoja dėl procesoriaus išteklių. Tai leidžia man turėti matomumą, kad galėčiau žiūrėti į tvarkaraščių sudarymą. Galiu įkelti svečių VM į kitą fizinį serverį. Visus šiuos dalykus, į kuriuos galite reaguoti, ir aš, be to, iš tikrųjų galiu pažvelgti į kodo efektyvumą, kad galbūt jis naudotų mažiau procesoriaus. Manau, kad šiame pristatyme turiu gana gerą pavyzdį, kaip kažkas sugebėjo sumažinti procesoriaus sunaudojimą pagal dydį.
Tai buvo „VMware“. Įeikime į patį kodą, programos kodą. Tiksliai galėsite parodyti, kas vyksta „Java“, .NET, ABAP kode, el. Versle, „PeopleCode“ ir kt. Tai yra įėjimo taškai į „WebLogic“. Čia yra išvadų ataskaita, kuri man sako, kad jums reikia atkreipti dėmesį į šiuos EJB, ir pasakys man, kad šioje sistemoje taip pat įvyko užraktas. Dar kartą atkreipkite dėmesį į verslo logikos pakopą, kad parodytumėte, kas vyksta. Šiuo atveju aš žvelgiu į konkrečius atvejus; Aš taip pat palaikau grupavimą. Jei dirbate daug JVM, galite pažvelgti į visą grupę arba į atskiro JVM trūkumus.
Kai įsitraukiate į užrakinimą, galiu patekti į išimtis. Išimtis yra šiek tiek kitokia nei spektaklio problema. Paprastai išimtys vykdomos labai greitai. Nes ten yra logikos klaida ir kai jūs paspausite tą logikos klaidą, ji pasibaigs. Mums pavyko užfiksuoti kamino pėdsaką, esant svarbiausiam išimtinumui, tai galėtų sutaupyti daug laiko, nes bandoma išsiaiškinti, kas vyksta, jūs tiesiog turite kamino pėdsaką čia pat. Taip pat galime fiksuoti atminties nutekėjimą. Sprendimas taip pat apima duomenų bazės pakopą, galiu patekti, galiu įvertinti duomenų bazės egzempliorių. Vėlgi, y ašis yra vieta, kur buvo praleistas laikas, x ašis - laikas per dieną. Čia yra išvadų ataskaita, kuri man tiesiog automatiškai nurodo, kas vyksta sistemoje ir ką aš galiu pažiūrėti.
Vienas iš dalykų, susijusių su tikslių išvadų ataskaita, tai ne tik žurnalai ar laukimo būsena, bet ir visos vykdymo būsenos, įskaitant centrinį procesorių, taip pat informacijos grąžinimas iš saugyklos. Saugojimas yra labai svarbi aplikacijos kamino dalis, ypač atsiradus kietojo kūno būsenai. Turėti tokią informaciją gali būti labai naudinga. Tam tikrus saugojimo įrenginius mes galime iš tikrųjų išsiaiškinti ir parodyti, kas vyksta atskiro įrenginio lygiu. Tokio tipo informacija - dar kartą, tai gilus matomumas; tai plati taikymo sritis - suteikti jums tik tiek informacijos, kad turėtumėte daugiau svertų, kad galėtumėte pritraukti kaip programų atlikimo profesionalus, kad galėtumėte optimizuoti savo programas, kad galėtumėte patenkinti tuos verslo sandorius.
Turiu porą atvejų tyrimų, kuriais norėjau pasidalinti su jumis. Mes plaukiame gana greitai; Tikiuosi, einu tinkamu tempu. Kalbant apie saugojimą, visi laikui bėgant keičia techninę įrangą. Yra aparatinės įrangos garantija. Ar tai tikrai pristatė tai, ką pardavėjas jums pasakė? Galite tai įvertinti naudodamiesi tikslia. Jūs atėjote, o kas nutiko, jie iš esmės įdėjo naują saugyklą, bet kai saugyklos administratoriai pažvelgė tik į saugyklos vienetų lygį, jie pamatė daug ginčų ir manė, kad gali kilti problemų dėl šio naujojo saugojimo įrenginio. . Žvelgiant daugiau iš vienos pusės į kitą, tiksliai siekiant parodyti, kur tai iš tikrųjų įvyktų. Jie iš tikrųjų praėjo iš maždaug 400 megių per sekundę pralaidumo, kur saugykla buvo atsakinga už 38 procentus atsako laiko, taigi ji yra gana didelė. Su naujuoju saugojimo bloku mes padidinome pralaidumą iki šešių, septynių šimtų megių per sekundę, taigi iš esmės dvigubai, ir mes galime perpus sumažinti sandėliavimo pakopos indėlį į operacijos laiką. Aš iš tikrųjų galiu tai parodyti anksčiau, tai yra perėjimo laikotarpis, o paskui.
Taigi dar kartą pateikėme dokumentus, įrodančius, kad investicijos į aparatinę įrangą buvo verti, ir jie pristatyti taip, kaip tikėjosi tas pardavėjas. Dėl dalykų sudėtingumo, daugybės dalykų gali būti visokių. Šiuo atveju jie iš tikrųjų turėjo tokią situaciją, kai visi tarsi kaltino DBA, DBA buvo tarsi „Na, ne taip greitai“. Čia iš tikrųjų žiūrime į SAP programą, manau, kad tokio tipo scenarijai yra gana įprasti. . Kas nutiko, jie kūrė pasirinktinę operaciją vartotojui. Vartotojas yra toks: „Tai taip lėtai“. ABAP koduotojas, tai yra SAP programavimo kalba, pasakė: „Tai yra duomenų bazės problema.“ Jie baigė atidaryti tikslius; jie tą galutinį vartotoją išmatavo per 60 sekundžių, taigi, daugiau nei per minutę. Penkiasdešimt trys sekundės buvo praleistos gale. Jie gilinosi į galinį galą ir iš tikrųjų sugebėjo atskleisti SQL teiginį mažėjimo tvarka.
Šis populiariausias SQL teiginys, kuris sunaudoja 25 procentus išteklių sunaudojimo, jo vidutinis vykdymo laikas yra dvi milisekundės. Jūs negalite kaltinti duomenų bazės. Žinai, ei, ne taip greitai, vaikinas. Kyla klausimas, kodėl vykdoma tiek daug mirties bausmių? Na, jie sugrąžino jį į ABAP, jis įėjo, pasižiūrėjo į kilpos lizdą, sužinojo, kad skambina duomenų bazei netinkamoje vietoje, iš esmės jie padarė pakeitimą, išbandė pakeitimą ir dabar yra naujas atsakymo laikas. penkias sekundes. Šiek tiek lėtai, bet jie galėjo su tuo gyventi. Geriau nei 60 sekundžių. Kartais tai yra tiesiog fermentacija, ar tai yra programos kodas, ar tai yra duomenų bazė, ar ji yra saugykla? Tai yra sritys, kuriose „Precise“, atsižvelgiant į galutinių operacijų kontekstą, yra svarbi „Precise“ žaidimui. Tu iš esmės tuos dalykus nutrauki.
Aš žiūriu į laiką, atrodo, kad dar turime šiek tiek laiko pereiti dar porą iš šių. Aš transliuoju juos. Ši programa buvo kuriama daugiau nei metus. Eidami į QA, jie matė, kad interneto serveriai buvo išnaudoti 100 procentų ir atrodė, kad programa negalėjo veikti pagal VMware. Pirmas dalykas, kurį visi pasakė, buvo: „Įdėk tai į fizinę; jis negali būti paleistas naudojant „VMware“. “Tikslus jiems iš tikrųjų pasiūlė papildomų būdų problemai išspręsti. Pažiūrėjome į operacijas, pamatėme skambutį į interneto serverį, jis IIS.NET yra ASMX. Tai iš tikrųjų atskleidė pagrindinį kodą. Matai tai, kur aš nukreipiu? Tai yra 23 dienos, 11 valandos. Oho, kaip tai įmanoma? Na, kiekvienas kvietimas užtrunka 9, 4 sekundės, o šis dalykas iškviečiamas 215 000 kartų. Kiekvienam iškvietimui reikia 6 sekundžių procesoriaus. Tai yra priežastis, šis kodas yra priežastis, kodėl šis dalykas niekada negalėjo būti išplėstas. Tiesą sakant, ji negalėjo masto fiziškai.
Ką jie padarė, ar jie grįžo pas savo kūrėjus ir paklausė: „Ar kas nors gali pakeisti?“ Jie tarsi rengė konkursą, išbandydami įvairius pasiūlymus ir pateikdami pasiūlymą, kuris galėjo daug paleisti. efektyviau. Naujasis baigė vieną tašką, kiek mažiau nei per dvi sekundes, su dviem šimtosiomis sekundės dalimis CPU. Dabar tai galėtų būti išplėsta ir ji galėtų veikti „VMware“ ūkyje. Iš esmės sugebėjome tai dokumentuoti ir kodo, ir operacijos lygiu. Tai yra prieš tai, paskui. Dabar, kai čia galite pamatyti kamino juostos diagramą, rodančią internetą, .NET ir duomenų bazę, dabar jūs sąveikaujate su duomenų baze. Tai yra profilis, kurį galite tikėtis pamatyti paprastai veikiančiai programai.
Gerai, kad renkuosi ir renkuosi pagal papildomus dalykus, kuriuos galiu tau parodyti. Daugeliui žmonių tai patinka, nes tai žavi daugybę parduotuvių. Jei negalite susitikti su verslo SLA, o visi panašūs į: „Padėkite mums“. Šioje parduotuvėje buvo situacija, kai verslo SLA užsakymai gauti iki 15 val., Ji išsiunčiama tą dieną. Labai svarbu, kad jie gautų užsakymus, o sandėlis yra labai užimtas. Šis „JD Edwards“ pardavimo užsakymo ekranas buvo užšaldytas ir jūs galite susidaryti labai gerą mintį, kad tai „just-in-time“ mažmeninės prekybos atsargų valdymo sistema. Tuščios lentynos mažmeninėje prekyboje nepriimtinos. Turėjau ten turėti prekių, kad galėtum jas parduoti. Ką mes padarėme, pasinerėme, šiuo atveju žiūrime į SQL serverio duomenų bazę. Išvaizda yra tokia pati, nesvarbu, ar tai „SQL“, „Oracle“, „DB2“ ar „Sybase“.
Mes nustatėme pasirinkimą iš „PS_PROD“ ir galime užfiksuoti trukmę, faktą, kad jie tiek daug vykdo. Tamsiai mėlyna spalva atitiko raktą, kuris teigė, kad jie nelaukia tam tikros laukimo būsenos ar kai kurių duomenų registravimo ar net saugojimo - šį dalyką įpareigoja procesorius. Mes stebėjome SQL teiginį 34301, todėl kiekvieną kartą, kai tai vykdoma, mes padidiname savo skaitiklius, kad galėtume jį sekti. Tai reiškia, kad turime išsamią istoriją ir aš galiu prie jos prieiti spustelėjęs tą melodijos mygtuką. Čia yra istorijos skirtukas. Šiame ekrane rodoma vidutinė trukmė, palyginti su pokyčiais. Trečiadienį, ketvirtadienį, penktadienį vidutinė trukmė buvo maždaug dvi dešimtosios sekundės. Labai nedaug ekrano užšąla, jie gali patenkinti verslo SLA. Ateina vasario 27 d., Kažkas pasikeičia ir staiga įvykdymo laikas pasibaigė, ir tai iš tikrųjų yra pakankamai lėtas, kad būtų sukeltas laikas, dėl kurio ekranas užšąla. Tikslus, išlaikant išsamią istoriją, įskaitant vykdymo planą ir bendruosius lentelės rodyklių pakeitimus, jei naudojamas tas SQL. Galėjome išsiaiškinti, kad prieigos planas pasikeitė vasario 27 d. Nuo pirmadienio iki penktadienio bloga savaitė. Ateikite kovo 5 d., Prieigos planas vėl pasikeitė. Tai gera savaitė. Ši rožinė žvaigždė praneša mums apie atnaujintą garsumą.
Čia galite pamatyti eilučių skaičių pagrindinėse lentelėse. Tai būdinga verslui. Norite, kad jūsų stalai augtų. Reikalas tas, kad teiginiai yra analizuojami, pateikiami SQL teiginiai, optimizatorius turi nuspręsti, ką daryti, ir pasirinkti, kai vykdymo planas yra greitas, pasirinkti kitą vykdymo planą, kai jis lėtas, sukeldamas ekrano užšalimą. Remdamasis giluminėmis technologijomis, aš turiu žinoti, kas yra vykdymo planas, ir „Precise“ užfiksuoja jį man su data ir laiko antspaudu. Tai buvo greitas ir efektyvus, tai buvo lėtas ir neefektyvus. Šis prisijungimas prie filtro tiesiog naudoja daug daugiau centrinio procesoriaus, kad būtų galima suderinti ir atlikti šį konkretų SQL teiginį. Jie vis dar turi tą patį galutinį efektą, tačiau šis iš esmės turi lėtesnį, mažiau efektyvų receptą rezultatų rinkiniui pateikti. Taigi, mes pereiname. Ei, mes turime laiko dar porai?
Erikas Kavanaghas: Taip, eik.
Billas Ellisas: Gerai, aš pereisiu į priekį. Vienas dalykas, į kurį noriu atkreipti dėmesį, mes kalbėjome apie aparatūrą, apie SAP, apie .NET, apie JD Edwards ir „Java-SQL Server“ aplinką. Tai yra SAP, čia mes žiūrime į „PeopleSoft“. Tiksli atraminė matrica yra plati ir gili. Jei turite programą, daugiau nei tikėtina, mes galime ją pritaikyti, kad būtų užtikrintas toks matomumas. Vienas didžiausių pokyčių, vykstančių šiuo metu, yra mobilumas. „PeopleSoft“ pristatė mobilumą naudodama savo „Fluid UI“. „Fluid UI“ sistema naudoja sistemą labai skirtingai. Ši programa tobulėja. „Fluid UI“ - tai, ką ji daro iš valdymo perspektyvos, suteikia galimybę galutiniams vartotojams naudotis savo telefonu ir tai labai padidina produktyvumą. Jei turite šimtus ar tūkstančius ar net daugiau darbuotojų, jei padidinsite jų produktyvumą 1–2 procentais, tai gali turėti didžiulį poveikį darbo užmokesčiui ir visai kitai. Kas nutiko, ši konkreti parduotuvė išstūmė „PeopleSoft Fluid UI“. Dabar, kalbant apie sudėtingumą, tai yra „PeopleSoft“ rietuvė. Viena programa, mažiausiai šešios technologijos, daugybė galutinių vartotojų. Kaip tai pradėti?
Dar kartą „Precise“ galės sekti šias operacijas. Tai, ką mes jums parodome, yra sudedama juostinė schema, rodanti klientą, žiniatinklio serverį, „Java“, „Tuxedo“ duomenų bazę, „PeopleSoft“ programų kaminą. Žali žemėlapiai į J2EE, kuris yra tarsi įmantrus būdas pasakyti „WebLogic“. Tai yra perversmas. Galutiniai vartotojai pradeda naudoti „Fluid UI“, o reakcijos laikas trunka nuo pusantros, dviejų sekundžių iki maždaug devynių, dešimties sekundžių. Tai, ko šis ekranas nerodo, yra skaičius žmonių, kurie „nereaguoja“. Jie iš tikrųjų ekraną užšaldo taikydami. Pažvelkime į matomumą, kurį „Precise“ sugeba suteikti šiam klientui.
Visų pirma, kai aš žvelgiu į „PeopleSoft“ operacijas, jie iš esmės gali pamatyti, kad tokio tipo dalykus matėme visur. Įtakos turėjo visos operacijos, taip pat visos vietos. Beje, pažvelgę į tai iš tikrųjų galite pamatyti vietas visame pasaulyje. Nuo Azijos Ramiojo vandenyno iki Europos ir Šiaurės Amerikos. Našumo problema nebuvo susijusi su konkrečia operacija ar konkrečia geografine vieta, ji yra plati visos sistemos mastu. Tai savotiškas būdas pasakyti, kad „Fluid UI“ pakeitimas ar būdas turėjo visuotinį poveikį. Čia galite pamatyti mastelio keitimo aspektą, žmonės bando atlikti tokio pat pobūdžio veiklą, tačiau reakcijos laikas iš esmės tik blogėja ir blogėja. Galite pastebėti, kad viskas nesvyruoja. Viskas klostosi labai, labai blogai. Kai aš žvelgiu į ašių skaičių ir tuo pačiu metu vykstančius ryšius, pamatai tai, kas labai įdomu atsižvelgiant į prieigos skaičių ir jungtis. Čia mes padidiname tik iki maždaug 5000 ir jūs žiūrite maždaug, tai viršija 100 vienu metu veikiančių jungčių. Tai daroma po; tai yra anksčiau. Taigi koks mano tikrasis sistemos poreikis, jei šis dalykas galėtų būti išplėstas, yra 300 000 diapazono. Senosiomis dienomis naudodamiesi klasikine vartotojo sąsaja, jūs žiūrėjote į 30 lygiagrečių jungčių.
Dabar tai jums sako, kad „Fluid“ vartotojo sąsaja naudoja mažiausiai 10 kartų lygiagrečių jungčių skaičių. Mes pradedame traukti tai, kas vyksta po dangteliais su „PeopleSoft“, kad galėtumėte pamatyti, kokį poveikį interneto serveriams daro tai, kad SLA pradeda pažeidinėti. Nesigilinsiu į viską, bet viskas atsitiks taip, kad jie iš esmės pasikliauja pranešimais. Jie iš esmės naudojasi „WebLogic“ ir sukelia eilę per „Tuxedo“. Iš tikrųjų buvo daugialypės priklausomybės problema, kuri pasirodė su „Fluid UI“, tačiau „Precise“ sugebėjo parodyti, kad daugybe skirtingų dalykų galima susitelkti ties problema. Pasirodo, problema buvo ir pačioje duomenų bazėje. Iš tikrųjų yra pranešimų žurnalo failas ir dėl visų kartu esančių vartotojų šis žurnalo failas buvo užrakinamas. Iš esmės tai turėjo būti sureguliuota kiekvienoje taikymo pakopos pakopoje. Kalbėkite apie sudėtingumą, čia iš tikrųjų yra „Tuxedo“ pakopa, rodanti eilę, ir jūs taip pat galite pamatyti, kad našumas žemėja ir šioje pakopoje. Galėjau pamatyti procesus; Aš galėjau pamatyti domenus ir serverius. „Tuxedo“ žmonėms, kad tuo naudotumėtės, paprastai atidarote papildomas eiles, domenus ir serverius, kaip ir prekybos centre, kad sumažintumėte spūstis ir sumažintumėte eilės laiką. Paskutinis ir paskutinis variantas „Tikslus“ rodo daug informacijos.
Kaip jau minėjau anksčiau, kiekviena reikšminga operacija sąveikauja su įrašų sistema. Duomenų bazės matomumas yra labai svarbus. „Precise“ parodo, kas vyksta duomenų bazėje, „WebLogic“, „Java“, .NET, naršyklėje, tačiau vieta, kur „Precise“ išties yra puiki, yra duomenų bazės pakopoje. Tai atsitiko dėl mūsų konkurentų silpnybės. Leiskite parodyti jums vieną iš būdų, kaip „Precise“ galėtų jums padėti tai padaryti. Neketinu skirti laiko duomenų bazių optimizavimo trikampiui, tačiau iš esmės žiūrime į pigių, mažai rizikingų, į plataus masto, didelės rizikos, brangių tipų pakeitimus. Aš iš tikrųjų tweet šią skaidrę vėliau, jei žmonės nori pabandyti ir pažvelgti į tai. Manau, kad tai gana didelis derinimo problemų vadovas. Štai „Precise for Oracle“ ekspertų nuomonė. Rezultatų ataskaitoje teigiama, kad 60 proc. Įtakos turi būtent šis SQL teiginys. Jei atidarysite šį veiklos ekraną, jis jame rodomas. Aš galiu pažiūrėti į šį pasirinktą teiginį, ten yra vienas vykdymo planas. Kiekviena egzekucija trunka sekundę - 48 000 egzekucijų. Tai sudaro dar 48 000 egzekucijų valandų.
Dar kartą tamsiai mėlyna yra procesorius. Šis dalykas yra susijęs su procesoriumi, o ne laukimo būsena, o ne žurnalas. Pabrėžiu, kad kai kurie mūsų konkurentai žiūri tik į laukimo būsenas ir registravimo įvykius, tačiau paprastai kalbant, CPU yra pati aktyviausia vykdymo būsena ir siūlo didžiausią atpirkimą. Įsigilindamas į šį eksperto požiūrį - ir aš einu labai greitai - ką aš padariau, aš žiūrėjau į lentelę, 100 000 eilučių, 37 000 blokų. Mes darome visą lentelę, tačiau turime šešis šio dalyko indeksus. Kas čia vyksta? Na, kai aš žiūriu, kur yra sakinys, tai, ką daro ta išlyga, iš tikrųjų konvertuoja stulpelį į didžiąsias raides ir sako, kur jis lygus didžiosioms raidėms, rask kintamąjį. Kas nutinka, kiekvieną kartą įvykdžius šį veiksmą, „Oracle“ turi konvertuoti šią stulpelį didžiosiomis raidėmis. Užuot tai padarius beveik penkiasdešimt tūkstančių kartų, daug efektyviau yra sukurti tą rodyklę didžiosiomis funkcijomis pagrįsto rodyklės raidėmis ir ją galima rasti ne tik „Oracle“ įmonės padalinyje, bet ir standartiniame skyriuje. Kai tai padarysite, tada galite patikrinti, ar vykdymo planas išduoda tas naujas rodyklės vartotojo nuolatines didžiąsias raides - tai buvo tiesiog mano dalykas.
Tada, prieš atlikdami matavimus prieš ir po, jūs žiūrite į vienos sekundės vykdymo laiką, kaupiantį iki 9 valandų 54 minučių su tuo pačiu tiksliu SQL sakiniu, tačiau turint tą rodyklę įmontuota didžiosiomis raidėmis 58 000 įvykdymams, atsakymas laikas sumažėja iki submisekundžių, kartu sudėjus, tai užtrunka iki septynių sekundžių. Iš esmės išsaugojau dešimt valandų procesoriaus savo serveryje. Tai yra didžiulė. Nes jei man nereikia atnaujinti serverio, aš galiu gyventi tame serveryje. Aš iš tikrųjų sumažinu serverio naudojimą 20 procentų ir jūs iš tikrųjų galite pamatyti prieš ir po. Tai yra matomumo tipas, kurį gali suteikti tikslus. Taip pat yra keletas papildomų dalykų, į kuriuos galime atkreipti dėmesį, kodėl jūs turite visus šiuos indeksus, jei jie nenaudojami? Jie gali to imtis. Yra architektūra, ir aš ją apvyniosiu, nes mes pasiekėme valandos viršūnę. Aš esu tikras tikintis šiuo sprendimu ir norime, kad būtumėte tikras tikintysis. „IDERA“ tikime, kad bandymas priverčia klientą, todėl, jei jus domina, galime įvertinti jūsų svetainę.
Su tuo aš perduosiu švyturėlį atgal.
Erikas Kavanaghas: Taip, tai buvo didžiulė detalė, kurią jūs ten parodėte. Tai tikrai gana žavu. Manau, kad galbūt jau anksčiau esu jums minėjęs, kad - ir aš žinau, kad kai kuriose kitose internetinėse transliacijose, kurias mes darėme su IDERA, - aš iš tikrųjų stebėjau „Precise“ nuo to laiko, kol ją įsigijo IDERA, Aš galvoju, kad iki pat 2008 m. ar 2009 m. mane tai sužavėjo. Man įdomu sužinoti, kiek daug darbo reikia likti naudojant naujas programas. Jūs paminėjote SAP HANA, kuri, mano manymu, buvo gana įspūdinga, kad jūs iš tikrųjų galite įsigilinti į HANA architektūrą ir ten pašalinti triktis. Kiek žmonių turite? Kiek tai jūsų pastangų ir kiek to galima padaryti šiek tiek dinamiškai, tai reiškia, kai įrankis bus paleistas, jūs pradedate ropoti ir pamatyti įvairius dalykus? Kiek to gali būti dinamiškai, rūšies, patikrinta naudojant įrankį, kad galėtumėte padėti žmonėms pašalinti sudėtingas aplinkas?
Billas Ellisas: Jūs ten uždavėte labai daug klausimų.
Erikas Kavanaghas: Aš žinau, atsiprašau.
Billas Ellisas: Aš pateikiau labai daug detalių, nes šioms programoms, žiūrint į kodą, velnias yra detalėse. Jūs turite turėti tokio lygio detalę, kad tikrai galėtumėte turėti tai, ko galima imtis. Nesinaudodami metrika, jūs tiesiog žinote apie simptomus. Jūs iš tikrųjų neišsprendžiate problemų. IDERA siekia išspręsti problemas. Likti naujiems leidiniams ir kitiems dalykams yra didelis iššūkis. Klausimas, ko reikia norint tai padaryti, iš tikrųjų skirtas produkto valdymui. Aš nelabai gerai matau komandą, kuri mus nuolat atnaujina. Kalbant apie HANA, tai iš tikrųjų yra naujas IDERA produktų linijos priedas; tai labai jaudina. Vienas iš dalykų, susijusių su HANA, yra - leisk man sekundę kalbėti apie užduotį. Vykdydami šią užduotį SAP parduotuvės darytų tai, kad jos atkartotų duomenų bazę ataskaitų teikimo tikslais. Tuomet turėtumėte žmones susitaikyti su tuo, kas iš tikrųjų. Turėtumėte šias skirtingas duomenų bazes ir skirtinguose lygmenyse jos nebebūtų sinchronizuojamos. Reikia tik daug laiko ir pastangų, be to, techninė įranga, programinė įranga ir žmonės turi visa tai prižiūrėti.
HANA idėja turėti labai lygiagrečią duomenų bazę atmintyje, kad iš esmės būtų išvengta dubliavimo duomenų bazių poreikio. Mes turime vieną duomenų bazę, vieną tiesos šaltinį, ji visada yra atnaujinta, tokiu būdu jūs išvengsite viso to suderinimo būtinybės. HANA duomenų bazės našumo svarba didėja - sakysiu, 10 kartų ar bent jau vertingesnė už visų tų duomenų bazių, aparatūros ir išteklių sumą, kurią galima nusipirkti. Galėdamas valdyti HANA, dabar šis komponentas iš tikrųjų išbandomas beta versijoje, tai netrukus taps GA. Taigi tai yra labai įdomu IDERA ir mums iš esmės palaikyti SAP platformą. Nesu tikras, kokias kitas jūsų klausimo dalis aš sutrumpinau, bet -
Ericas Kavanaghas: Ne, čia viskas gerai. Aš įmečiau į tave visą krūvą iškart, dėl to gaila. Mane tiesiog žavi, aš tai turiu galvoje, kad tai nėra labai paprastas pritaikymas, tiesa? Jūs gilinatės į šias priemones ir suprantate, kaip jie sąveikauja tarpusavyje ir, kaip jums suprantama, turite kartu sugalvoti istoriją. Turite derinti daugybę informacijos, kad suprastumėte, kas iš tikrųjų vyksta ir kas kelia jums problemų, kad galėtumėte ten patekti ir išspręsti šias problemas.
Vienas dalyvis klausia, kaip sunku įgyvendinti „Precise“? Kitas asmuo paklausė, kas yra žmonės - akivaizdu, kad DBA - bet kurie kiti organizacijos vaidmenys, kurie naudotųsi šia priemone?
Billas Ellisas: Tikslų įdiegti yra šiek tiek sudėtingiau. Jūs turite turėti tam tikrų žinių apie taikymo aplinką, kalbant apie tai, kad jūs žinote, kad ši programa veikia šioje duomenų bazėje, jai reikia arba - vidutinės pakopos interneto serverių ir pan., Manau, atsižvelgiant į kai kurių šių programų sudėtingumą, tai iš tikrųjų gana lengva. Jei galiu pritaikyti interneto serverį prie jūsų duomenų bazės, aš galiu tai padaryti nuo galo iki galo. Pastebėjote, kad aš nieko nesakiau apie kliento įrankio naudojimą galutiniam vartotojui, nes mes tai darome iš tikrųjų dinamiškai, taigi jums nereikia keisti savo kodo ar dar ko nors. „JavaScript“ patenka į programos puslapio rėmelį. Nesvarbu, kur yra pasaulio vartotojas, pasiekęs URL iš jūsų programos ir nuleidęs tą puslapį, jis aprūpintas tikslia. Tai leidžia mums pasirinkti vartotojo ID, jų IP adresą, taip pat kiekvieno puslapio komponento scenarijaus pirmo baito pateikimo laiką galutinio vartotojo naršyklėje.
Kalbant apie operacijas, jums nereikia planuoti operacijų, nes jos yra glaudžiai susijusios. Šis URL tampa įėjimo tašku į JVM ir tada iškviečia šį pranešimą, todėl JVC sugaunamas iš duomenų bazės. Mes iš esmės galime surasti tuos natūralius ryšio taškus ir pateikti juos jums tame operacijų ekrane, kurį aš jums parodžiau, kur mes taip pat apskaičiavome, kiek laiko, ar procentą laiko, praleistą kiekviename atskirame žingsnyje. Visa tai daroma automatiškai. Apskritai, mes skiriame 90 minučių tam, kad padarytume - kad iš esmės įdiegtume „Precise“ branduolį ir tada pradedame įgyvendinti programą. Atsižvelgiant į žinias apie programą, mums gali prireikti papildomų sesijų, kad gautume visą programą. Daugelis žmonių naudoja tik „Precise“ duomenų bazės komponentą. Tai gerai. Iš esmės galite tai sugriauti, suskaidyti į komponentus, kurie jums atrodo reikalingi jūsų svetainei. Mes neabejotinai tikime, kad visos aplikacijų krūvos prietaisai yra tokie, kad jūs galite pamatyti, kad priklausomybė nuo pakopos iki pakopos iš tikrųjų padidina atskiros pakopos stebėjimo vertę. Jei kas nori išsamiau ištirti, kaip pritaikyti savo programų paketą, apsilankykite mūsų tinklalapyje - manau, kad tai lengviausias būdas paprašyti papildomos informacijos, ir mes apie tai aptarsime šiek tiek toliau.
Erikas Kavanaghas: Leiskite man užduoti jums vieną ar du greitus klausimus. Spėju, kad laikui bėgant jūs kaupiate ir kaupiate saugyklą, skirtą tiek individualiems klientams, tiek ir bendrai kaip visos įmonės sąveikai tarp įvairių programų ir įvairių duomenų bazių. Kitaip tariant, scenarijų modeliavimas, manau, yra tas, į ką aš užsimenu. Ar taip yra? Ar iš tikrųjų turite tam tikrą įprastų scenarijų saugyklą, kad galėtumėte pateikti pasiūlymus galutiniams vartotojams, kai tam tikri dalykai bus naudojami? Kaip ši „E-Business Suite“ versija, ši duomenų bazės versija ir kt. - ar jūs daug ką darote?
Billas Ellisas: Na, tokio tipo informacija yra įtraukta į išvadų ataskaitą. Išvadų ataskaita sako, kas yra veiklos kliūtys, ir ji pagrįsta vykdymo laiku. Dalis išvadų ataskaitos yra sužinokite daugiau ir ką jūs darote toliau. Informacija ir klientų patirtis ir tt iš esmės yra įtraukta į tą rekomendacijų biblioteką.
Ericas Kavanaghas: Gerai, kad skamba gerai. Na, žmonės, fantastinis pristatymas šiandien. Bilai, man patiko, kiek daug detalių tu turėjai. Aš tiesiog maniau, kad tai išties fantastiška, šiurkšti, išsami informacija, rodanti, kaip visa ši medžiaga daroma. Tam tikru momentu tai beveik panašu į juodąją magiją, bet tikrai taip nėra. Tai labai specifinė technologija, kurią jūs, vaikinai, įdėjote, kad suprastumėte labai, labai sudėtingą aplinką ir padarytumėte žmones laimingus, nes niekam nepatinka, kai programos veikia lėtai.
Na, žmonės, mes šią interneto transliaciją archyvuosime. Galite apsilankyti svetainėje Techopedia arba insideanalysis.com ir wow, ačiū už jūsų laiką, mes su jumis susisieksime kitą kartą. Rūpinkis, atsisveikink.
