De personalul Techopedia, 2 noiembrie 2016
Take away : Gazda Eric Kavanagh discută performanța aplicației și modul de îmbunătățire a eficienței cu Dr. Robin Bloor, Dez Blanchfield și IDERA Bill Ellis.
În prezent nu sunteți autentificat. Vă rugăm să vă conectați sau să vă înregistrați pentru a vedea videoclipul.
Eric Kavanagh: Doamnelor și domnilor, salut și bineveniți din nou la Hot Technologies. Da, întradevăr! Numele meu este Eric Kavanagh, voi fi gazda dvs. pentru o altă transmisiune web astăzi în această serie cu adevărat distractivă, interesantă, pe care am primit-o ca compliment la seria noastră Briefing Room. Titlul este „Acelerarea aplicațiilor: performanță mai rapidă pentru utilizatorii finali”. Hai oameni care nu vor asta? Dacă sunt tipul de acolo care vă ajută aplicația să funcționeze mai repede, mă gândesc că tipul obține beri cumpărate pentru mine la bar după muncă. Trebuie să fie un lucru destul de fain pentru a intra în viteză și pentru a grăbi aplicația oricui.
Există un diapozitiv despre al tău, accesează-mă pe Twitter @Eric_Kavanagh. Încerc mereu să urmăresc înapoi și re-tweet mereu dacă mă menționați, așa că nu ezitați să mă menționați.
Scopul întregului spectacol este să vă concentrați pe diferite aspecte ale tehnologiei întreprinderii și să ajutați într-adevăr să definiți anumite discipline sau anumite fețe, dacă doriți. De multe ori vânzătorii vor prelua anumite condiții de marketing și vorbește despre cum fac acest lucru sau acela sau alt lucru. Acest spectacol a fost conceput cu adevărat pentru a ajuta publicul nostru să înțeleagă ce trebuie să aibă un instrument software pentru a fi lider în spațiul său. Formatul acestuia fiind doi analiști. Fiecare merge mai întâi, spre deosebire de Briefing Room, unde vânzătorul merge mai întâi. Fiecare își asumă ceea ce cred că este important să știți despre un anumit tip de tehnologie.
Astăzi vorbim despre accelerarea aplicațiilor. Vom auzi de la Dez Blanchfield și de asemenea doctorul Robin Bloor - suntem peste tot în lume astăzi - și apoi Bill Ellis apelează din zona mai mare a Virginiei. Cu asta, o voi înmâna primului nostru prezentator, Dr. Bloor. Am tweeted hashtag-ul #podcast, apropo, așa că nu ezitați să faceți un tweet. Ia-o de aici.
Dr. Robin Bloor: Bine, mulțumesc pentru această introducere. Performanța aplicației și nivelurile serviciilor - acesta este un fel de zonă, am lucrat foarte mult în acest domeniu de-a lungul anilor, în sensul că am depus de fapt o muncă groaznică în monitorizarea performanței și în pregătirea într-una într-un fel sau altul, cum să încercați și să calculați aceste niveluri. Trebuie spus că până acum - obișnuiam să avem această epocă, cu ceva timp în urmă, în care oamenii construiau sisteme în silozuri. Practic, cantitatea de muncă pe care trebuie să o facă pentru a face un sistem să funcționeze destul de bine dacă a fost într-un silo nu a fost de fapt prea greu, deoarece trebuie să luați în considerare o cantitate foarte mică, foarte mică de variabile. De îndată ce am ajuns în rețea corect, interacțiunea și orientarea serviciului au intrat în ecuație. A fost un pic dificil. Performanța poate fi unidimensională. Dacă vă gândiți doar la o aplicație care execută o anumită cale de cod în mod repetat, o faceți în mod rezonabil, în timp util, se simte ca un lucru unidimensional. De îndată ce începi să vorbești despre nivelurile serviciilor, vorbești de fapt despre mai multe lucruri care concurează pentru resurse de calculator. Devine multi-dimensional foarte repede. Dacă începeți să vorbiți despre procesele de afaceri, procesele de afaceri pot fi filate împreună din mai multe aplicații. Dacă vorbești despre arhitectură orientată către servicii, atunci o anumită aplicație poate accesa de fapt capabilitățile mai multor aplicații. Apoi devine un lucru foarte complicat.
M-am uitat - cu mult timp în urmă, am desenat această diagramă. Această diagramă are cel puțin 20 de ani. Practic, îl numesc Diagrama tuturor, deoarece este o modalitate de a privi tot ceea ce există în mediul IT. Este într-adevăr doar patru piese: utilizatori, date, software și hardware. Bineînțeles că se schimbă în timp, dar vă dați seama efectiv când priviți acest lucru că există o explozie ierarhică a fiecăreia dintre aceste piese. Un hardware da, un hardware poate fi un server, dar un server constă din mai multe procesoare, tehnologie de rețea și memorie, iar acesta este un fel de multe controloare, așa cum se întâmplă. Dacă te uiți la acest lucru, totul se descompune în bucăți. Dacă de fapt te gândești să încerci să orchestrezi toate acestea, în ceea ce privește datele care se schimbă, performanța software-ului se schimbă, deoarece hardware-ul se schimbă și așa mai departe, te uiți la o situație multi-variabilă extrem de dificilă. Aceasta este curba complexității. Desigur, este curba de complexitate pentru aproape toate, dar am văzut că este atras din când în când vorbind despre computere. Practic, dacă puneți noduri pe o axă și conexiunile importante pe cealaltă axă, ajungeți la o curbă de complexitate. Aproape nu contează care sunt nodurile și conexiunile și asta va face dacă doriți o reprezentare a creșterii volumului în rețeaua de telefonie.
De fapt, atunci când vorbești despre noduri în mediul computerului, vorbești despre lucruri individuale care le pasă unul de celălalt. Complexitatea, se dovedește a fi, o chestiune de structură a varietății și diferitele constrângeri pe care încercați să le ascultați. De asemenea, numerele. Când numerele cresc, înnebunesc. Ieri am avut o discuție interesantă, vorbeam cu cineva - nu pot menționa cine a fost, dar nu prea contează - vorbeau despre un site care avea 40.000 - adică patru zero, 40.000 - cazuri de baze de date în site. Gândiți-vă doar la asta - 40.000 de baze de date diferite. Desigur, singurul lucru pe care l-am avut - au avut, evident, multe, multe mii de aplicații. Vorbim despre o organizație foarte mare, dar nu o pot numi. Vă uitați efectiv la asta și încercați de fapt, într-un fel sau altul, să obțineți niveluri de servicii care vor fi adecvate la nivel de bord pentru unii utilizatori multipli, cu așteptări diferite, dacă doriți. Este o situație complexă și tot ceea ce spun cu adevărat este că chestiile astea sunt complexe. Numerele cresc mereu. Limitările sunt determinate de procesele și obiectivele de afaceri. Vei fi observat schimbarea așteptărilor.
Îmi amintesc de îndată ce Gmail, și e-mailul Yahoo și Hotmail, toate acele sisteme de poștă au apărut, oamenii au început să aibă o așteptare a sistemelor lor de poștă internă din cadrul organizației, ar merita nivelurile de servicii ale acestor operațiuni uriașe cu vaste ferme de servere în afara organizația și a început să fie presată pentru ca toate aceste lucruri să se întâmple. De fapt, acordurile la nivel de serviciu sunt un lucru, dar așteptările sunt un alt lucru și se luptă reciproc în cadrul unei organizații, un lucru incomod. Iată doar o perspectivă de afaceri. În unele sisteme, timpul optim de răspuns este de o zecime de secundă a timpului de răspuns uman. O zecime de secundă este momentul în care este nevoie de o cobră pentru a vă mușca. Dacă stai în fața unui cobra și decide să te muște, este prea târziu, se întâmplă pentru că nu poți să răspunzi la o zecime de secundă. O zecime de secundă este aproximativ timpul necesar pentru ca mingea să părăsească mâna ulciorului pentru a ajunge la tipul cu liliacul. Practic, cum vede mingea aruncată, trebuie să răspundă exact la acel moment. Răspunsul uman, un lucru interesant. Software-la-software, poate avea, evident, o așteptare mai mare.
Apoi intri în anumite situații care cred că sunt acele situații de piață, în care a fi primul este locul valorii de business. Acest lucru este ca și în cazul în care doriți să vindeți un anumit stoc pe piața bursieră este probabil mai mic, de exemplu, deoarece credeți că va scădea și o mulțime de alte persoane cred că va scădea, veți obține cel mai bun preț dacă ajungeți mai întâi pe piață. Există o mulțime de situații, difuzarea de reclame și lucruri de genul acesta, situații foarte similare. Aveți această mișcare în termeni de așteptare la nivel de serviciu. Ai un lucru care este un fel de plafon de sticlă pentru răspunsul uman. Odată ce este software-la-software, dacă ai această situație de tavan, atunci nu există cel mai bun nivel de servicii. Mai repede decât toată lumea este cel mai bun.
Bine, acesta este, cred, ultima diapozitivă pe care am făcut-o, dar aceasta este doar pentru a vă oferi o imagine mai mare a complexității, odată ce vă uitați efectiv la cerințele unei organizații, serviciul. Aveți, mergând pe partea stângă aici, aveți un sistem de management, care este un set de software care servește la gestionarea serviciilor, care încearcă să gestioneze un nivel de serviciu. Mai presus de asta, ai gestionare a performanței în afaceri. Apoi, dacă priviți în jos aici, zona de automatizare a managementului serviciilor, aveți servicii fragmentate care evoluează spre servicii standardizate, dacă de fapt vă pasă să investiți în acest tip de lucruri, care evoluează spre servicii integrate, care evoluează spre servicii optimizate . În mare parte, ceea ce au făcut oamenii este doar în colțul din stânga jos al acestui lucru. Poate un pic de management al serviciilor. Managementul performanței în afaceri, foarte rar. Fragmentat, aproape toate. O lume perfectă ar umple această grilă. Instrumentare - am menționat o problemă de sub-optimizare. Puteți optimiza părțile unui sistem și nu este bine pentru întregul sistem. Dacă faceți inima optimă, sângele dvs. poate circula prea repede pentru restul organelor. Aceasta este o problemă cu organizații mari și niveluri de servicii. În mod clar nu se va realiza nimic fără instrumente sofisticate, deoarece variabilele tocmai au obținut - bine, există prea multe variabile pentru a încerca și a optimiza.
Acestea fiind spuse, voi transmite lui Dez care va vorbi despre altceva în întregime, sperăm.
Dez Blanchfield: Mulțumesc, Robin. La fel ca Dr. Robin Bloor, am stat prea mulți ani gândindu-mă la performanța sistemelor foarte complexe la scară foarte mare. Probabil nu este aceeași scară ca Robin, dar performanța este un subiect zilnic și face parte din ADN-ul nostru să ne dorim performanță, să obținem cele mai bune rezultate din toate. De fapt, am folosit o grafică a unuia dintre lucrurile mele preferate din lume, cursele de mașini cu Formula I, unde întreaga planetă stă nemișcată o vreme și urmărește mașinile care se deplasează în cercuri foarte repede. Fiecare aspect, nu există niciun aspect al Formulei I care să nu fie în mod special despre obținerea performanței. Mulți oameni poo-poo sportul, deoarece consideră că este o pierdere de bani. Se dovedește că mașina pe care o conducem în fiecare zi pentru a arunca copiii la fotbal în weekend și la școală celelalte zile, este derivată din dezvoltarea și cercetarea bazată pe performanță. Este un fel de viață al curselor de mașini de Formula I. Tehnologia de zi cu zi, știința de zi cu zi, vine adesea din aprecierea a ceva ce a fost concentrat pur și simplu pe performanțe ridicate.
Realitatea, însă, este că noua noastră lume „mereu în permanență”, care necesită uptime de 100 la sută - așa cum a menționat Robin mai devreme - cu lucruri precum introducerea de e-mail și alte servicii pe care le asumăm în spațiu continuu, iar acum ne așteptăm ca în mediul nostru de afaceri și de muncă. Realitatea este că a fi sus nu înseamnă întotdeauna că îți îndeplinești acordul la nivel de serviciu. Am această afirmație asupra necesității de a gestiona performanța aplicației și acordurile la nivel de serviciu disponibile au suferit o schimbare fundamentală în ultimul deceniu. Nu mai încercăm să ne facem griji pentru performanța unui singur sistem. Când lumea era ceva mai simplă, am putea avea o situație în care un singur server care rulează mai multe servicii poate fi monitorizat în direct și a fost relativ simplu de acceptat. Am putea - și iată puținul meu, de lucrurile de care ne îngrijoram când eram administrator de sistem, de exemplu, în urmă cu mulți ani - ar fi să privim în jur, serviciul este de obicei susținut și răspunde? De exemplu, mă pot conecta la un terminal? Sistemul de operare răspunde și pot tasta comenzi? Aplicațiile sunt în funcțiune? Pot vedea procese și memorie în a face lucruri și I / O în rețea și așa mai departe? În zilele de masă, puteți auzi benzile care ieșeau din fermoar și cu hârtie care cad din ele.
Aplicațiile răspund și putem să ne conectăm și să facem lucruri pe ele? Utilizatorii se pot conecta la unele dintre aceste servere? Merge pe. Sunt destul de fundamentale, știi. Apoi câteva amuzante - asistența este verde? Pentru că, dacă nu, atunci totul merge bine, și cine va primi gogoșile? Viața era într-adevăr simplă în acele zile. Chiar și în acele zile, și apoi vorbesc cu 20-30 de ani în urmă, complexitatea era încă foarte mare. Am putea, într-o manieră relativ simplă, să gestionăm acorduri la nivel de serviciu și să fim cu ochii pe performanță. Nu o mai putem face cu mâna, așa cum a făcut aluzie Robin. Provocarea este prea mare. Faptul este momentul în care câteva aplicații bune, admin-uri, rețeaua de sistem și baza de date, administratorii pot monitoriza și îndeplini SLA-urile de performanță. SLA-urile sunt de departe acum, încât m-am luptat noaptea trecută când mi-am pus notele finale pentru a mă gândi chiar la anul în care am reușit să mă uit la un sistem dintr-o stivă foarte complexă și să înțeleg și chiar să înțeleg ce a fost mergând sub capotă și vin dintr-un fond profund tehnic. Nu-mi pot imagina cum este să te confrunți acum cu o zi administrativă.
Ce s-a întâmplat? Ei bine, în 1996, aplicațiile bazate pe baze de date au fost transformate odată cu boomul de internet. Mulți dintre noi am trecut prin asta. Chiar dacă nu ai fost în preajma boom-ului internetului, poți pur și simplu să privești în jur și să realizezi că în viața de zi cu zi, acum conectăm totul la internet. Cred că avem un prăjitor de pâine care aparent vine cu opțiunea de a accesa Wi-Fi, ceea ce este ridicol, pentru că nu am nevoie de toasterul meu conectat la internet. În anii 2000, în special la începutul anilor 2000, a trebuit să ne ocupăm de această creștere masivă a complexității rotunde care să ofere performanță serviciilor în boom dot-com. Apoi, o altă scânteie ridicolă în Web 2.0, unde smartphone-urile au apărut și acum aplicațiile erau în mâinile noastre 24 de ore și 7 și erau mereu pe modul.
Este 2016 acum, ne confruntăm cu un alt vagon sub formă de cloud și date mari și mobilitate. Acestea sunt sisteme atât de mari încât de multe ori sunt dificil de înțeles și de introdus în engleză simplă. Când ne gândim la faptul că unele dintre unicornii mari despre care vorbim au zeci de sute de petabyte de date. Acesta este întregul etaj al spațiului de disc și al stocării doar pentru a reține e-mailul, imaginile și social media. Sau, în unele cazuri, în logistica transporturilor și transporturilor, totul este în domeniul bancar, este locul în care se află banii dvs., sau unde se află postul dvs. sau dvs., unde se află lucrul pe care l-ați cumpărat pe eBay. Următorul val mare cu care ne vom confrunta este această provocare foarte grea a internetului lucrurilor.
Dacă acest lucru nu a fost suficient de rău, suntem pe cale să construim inteligența artificială și calculul cognitiv în aproape toate. Discutăm zilnic cu motoarele Siri și Google. Știu că Amazon are unul singur. Baidu au unul dintre aceste dispozitive dacă ai putea vorbi, îl convertesc în text care intră într-un sistem normal, baza de date face o interogare și revine și inversează procesul. Gândiți-vă la complexitatea care intră în asta. Realitatea este că complexitatea stivei de aplicații standard de astăzi este cu mult peste capacitățile umane. Când vă gândiți la tot ceea ce se întâmplă când apăsați un buton pe dispozitivul smartphone sau pe tabletă, vorbiți cu acesta, convertiți acest lucru în text, trece pe internet până la un sistem back-end, un front-end recepționează asta, o convertește într-o interogare, rulează interogarea printr-o stivă de aplicații, trece printr-o bază de date, accesează discuri, revine, iar în mijloc există o rețea de transportatori, există un centru de stare a rețelei locale. Complexitatea este înnebunită.
Afirmăm în mod eficient acest lucru ca hiperscale. Complexitatea și viteza hiperscalei sunt doar udarea ochilor. Aplicațiile și bazele de date au devenit atât de mari și atât de complexe, încât gestionarea performanței este de fapt o știință în sine. Mulți se referă la aceasta ca la o știință a rachetelor. Avem tehnologie la fața locului, avem tehnologie în afara locului, avem o serie de opțiuni pentru centrele de date; fizice și virtuale. Avem servere fizice și virtuale, avem cloud, avem infrastructură ca serviciu și platformă, servicii și software ca serviciu este un lucru pe care acum îl asumăm. Acesta din urmă, software-ul ca serviciu, a devenit înfricoșător pentru o perioadă în urmă cu câțiva ani, când CFO-urile și anumite părți ale organizației și-au dat seama că își pot ridica cardul de credit și pot cumpăra singur lucrurile și merg în jurul CIO și, în mod eficient, am numit această „umbră IT ”și CIOs încearcă acum să respingă acest control și să combată controlul.
În infrastructură avem o rețea definită de software, virtualizarea funcțiilor de rețea, mai jos de care, probabil, am terminat, acum avem servicii micro și aplicații de servicii active. Când faceți clic pe o adresă URL, există o grămadă de logici de afaceri care se află la sfârșitul acelei URL care descrie ce are nevoie pentru a o livra efectiv. Nu are neapărat logica preconstruită care o așteaptă. Avem baze de date tradiționale pe o parte, care sunt foarte mari, foarte mari. Avem aprecieri despre infrastructura și ecosistemele Hadoop din celălalt spectru care sunt atât de mari încât, așa cum am spus, știți, oamenii vorbesc acum despre sute de petabyte de date. Avem mobilitate complexă în ceea ce privește dispozitivele care transportă, laptopuri și telefoane și tablete.
Avem BYOD în unele medii închise și din ce în ce mai mult acum, de când oamenii cu experiență Gen Y își aduc propriile dispozitive. Le-am lăsat să le vorbească despre interfețele web. Fie pe internet, fie prin Wi-Fi, avem la dispoziție o conexiune Wi-Fi gratuită la cafeneaua de jos, deoarece beau cafea. Sau Wi-Fi-ul nostru intern. Mașina-mașină este prezentă mereu acum. Aceasta nu face parte direct din internetul lucrurilor, dar este legată și de acestea. Internetul lucrurilor este un joc cu totul nou, cu o complexitate care ne minte. Inteligența artificială și dacă credeți că ceea ce jucăm acum, cu toate Siri și alte dispozitive conexe cu care vorbim este complex, așteptați să ajungeți într-o situație în care vedeți ceva numit Olli, care este un 3-D autobuz tipărit, care ia aproximativ șase persoane și poate conduce singur în jurul orașului și puteți vorbi engleza simplă, și vă va vorbi înapoi. Dacă se lovește de trafic, se va decide să se întoarcă la stânga sau la dreapta zonei principale unde există trafic. Pe măsură ce se întoarce și vă îngrijorați de ce este întoarsă la stânga sau la dreapta de pe drumul principal, vă va spune: „Nu vă faceți griji, sunt pe punctul de a face stânga. Există trafic înainte și o să mă învârt. ”
Gestionarea performanțelor tuturor sistemelor de acolo și toată complexitatea, urmărirea în care se află aceste date, indiferent dacă intră în baza de date, toate interconectările și toate bițiile relevante este doar o problemă minunată. Realitatea este că gestionarea performanței și SLA-urilor la viteza și scara actuală necesită instrumente și sisteme, iar implicit acest lucru nu mai este ceva în care credeți că ar fi frumos să aveți o unealtă - este o condiție prealabilă; este absolut necesar. Iată ceva doar ca un mic exemplu, o listă cu diagrame de proiectare la aplicații la nivel înalt pentru OpenStack, cloud definit de software open-source. Aceasta este doar o bucată mare. Aceasta nu este doar servere și baze de date. Acesta este locul în care fiecare mic albastru reprezintă pâlcuri de lucruri. În unele cazuri, fișiere și servere sau sute de baze de date sau, desigur, nu mai mult de zeci de mii de bucăți mici de logică de aplicații. Aceasta este o versiune mică. Este cu adevărat destul de minunat când începi să te gândești la complexitatea care apare în acest sens. Astăzi, chiar și în spațiul mare de date, voi pune doar câteva capturi de ecran doar ale mărcilor. Când vă gândiți la toate piesele pe care trebuie să le gestionăm aici, nu vorbim neapărat despre o singură marcă, toate acestea sunt marci din peisajul de date mari și marca de top, nu doar la toate mărunțelele sau la sursele deschise. Arătați și credeți că este un grafic destul de minunat.
Haideți să aruncăm o privire la câteva verticale. Să luăm de exemplu marketingul. Iată un grafic similar, dar din stivele tehnologice disponibile doar în tehnologia de marketing. Acesta este graficul din 2011. Iată varianta 2016. Gândiți-vă, acesta este doar numărul de mărci de produse pe care le puteți folosi pentru tehnologie în ceea ce privește tehnologia de marketing. Nu complexitatea sistemelor din interior, nu diferitele aplicații și web și dezvoltare și rețea și toate celelalte. Doar marca. Există înainte, acum cinci ani și aici este astăzi. O să se înrăutățească. Suntem în acest moment în care este realitatea, oamenii pur și simplu nu pot asigura toate acordurile la nivel de serviciu. Nu ne putem scufunda în detalii, suficient de repede și la scara necesară. Iată un exemplu despre cum arată o consolă de monitorizare acum. Aceasta este ca aproape douăzeci de ecrane lipite împreună, pretinzând a fi un mare, ecran proiectat de mare monitorizare a fiecărei piese. Acum este interesant aici, nu voi menționa marca, dar această platformă de monitorizare monitorizează o singură aplicație într-un mediu logistic și de transport. Doar o aplicație. Dacă vă gândiți despre ce vorbea Robin unde organizațiile pot avea 40.000 de baze de date acum în medii de producție. Puteți vizualiza cum ar putea fi 40.000 de versiuni ale acestei colecții de ecrane care monitorizează o aplicație? Este o lume foarte curajoasă în care trăim. Așa cum a spus Robin și cu siguranță, vom face un ecou de 100 la sută că, fără instrumentele potrivite, fără suportul și poporul potrivit pe masă folosind aceste instrumente, performanța aplicației este un joc pierdut pentru oameni și trebuie să fie realizat de instrumente și software.
Cu asta voi transmite prietenilor noștri din IDERA.
Eric Kavanagh: Bine, Bill.
Bill Ellis: Mulțumesc. Împărtășind ecranul meu aici. Cred că poate cineva să confirme că îmi puteți vedea ecranul?
Dr. Robin Bloor: Da.
Eric Kavanagh: Arată bine.
Bill Ellis: Mulțumesc. Singurul lucru la care s-a referit a fost că, de-abia așteptam, a fost mașina care se auto-conduce. Singurul lucru despre care nu auzisem nimeni să vorbească este, ce se întâmplă când ninge? Mă întreb dacă inginerii din California și-au dat seama că în alte părți ale țării ninge destul de mult.
Dez Blanchfield: Îmi place asta, o să-mi amintesc de asta.
Eric Kavanagh: Un tipic de o milă pe oră.
Bill Ellis: Suntem aici pentru a vorbi despre managementul performanței aplicațiilor într-un mediu complex. Un lucru despre care îmi place să vorbesc este că mulți oameni, când vorbesc despre performanță, natura reacției este, mai mult servere, mai mult procesor, mai multă memorie etc. Cealaltă parte a monedei respective este eficiența procesării. Într-adevăr, sunt două părți ale aceleiași monede și vom arunca o privire asupra amândurora. Scopul final este respectarea acordurilor la nivel de serviciu pentru tranzacțiile de afaceri. În cele din urmă, toată această tehnologie există pentru afacere. Am vorbit despre existența unei baze de date de gestionare a performanței primului sector industrial. Idealul este să vă încadrați în matrița ideală de performanță și să o gestionați de la începutul ciclului de viață al aplicațiilor.
Subiectele se ridică într-adevăr la patru piese; unul este procesul de gestionare a performanței. Am vorbit cu toată lumea și fiecare are instrumente. Dacă nu au instrumente, au scripturi sau comenzi, dar ceea ce le lipsește este contextul. Contextul este pur și simplu conectarea punctelor pe stivele aplicației. Aceste aplicații pentru - sunt bazate pe browser. Ele sunt foarte strâns cuplate de la nivel la nivel. Cum interacționează nivelurile este, de asemenea, vital. Apoi, vorbim despre tranzacția de afaceri. Vom oferi vizibilitatea nu doar oamenilor tehnici, ci și proprietarilor de aplicații și managerilor de operațiuni.
Am câteva studii de caz pentru a împărtăși doar felul în care clienții le-au folosit. Aceasta este o porțiune foarte practică a prezentării aici. Să aruncăm o privire la ce se întâmplă de obicei. Îmi place să diagramez - a fost la fel ca un colaj incredibil de tehnologii. Numărul de tehnologii din centrul de date tocmai a crescut, a crescut și a crescut. Între timp, un utilizator final nu-i pasă și este ignorat. Ei doresc doar să exercite tranzacția, să fie disponibili, să o completeze rapid. Ceea ce se întâmplă de obicei este că profesioniștii din IT nu știu că utilizatorii finali chiar au avut o problemă, până când se auto-raportează. Asta începe un proces care consumă timp, lent și de multe ori frustrant. Ceea ce se întâmplă este că oamenii își vor deschide instrumentele și se uită la un subset al stivei lor de aplicații. Cu acel subset, devine foarte dificil să răspunzi la cea mai simplă întrebare. Este obișnuit să aveți problema? Ce tranzacție este? Unde se află blocul de aplicații? Petrecând tot acest timp, căutând nivel după nivel, nu reușind să răspund la aceste întrebări, ajungeți să cheltuiți mult timp și energie, mult personal, fonduri și energie.
Pentru a rezolva acest lucru, pentru a oferi o modalitate mai bună, ceea ce face Precise este de fapt să efectueze tranzacția de utilizator final, captează metadate despre aceasta, urmărește tranzacția prin rețea, pe serverul web, în nivelul logicii de afaceri și sprijinim .NET și ABAP și PeopleCode și E-Business Suite, în aplicații multitier care, în final, toate tranzacțiile vor interacționa cu sistemul de înregistrare. Indiferent dacă este vorba despre o căutare de inventar, timp de raportare lucrat, ei interacționează întotdeauna cu baza de date. Baza de date devine fundamentul performanței afacerii. Baza de date, la rândul său, se bazează pe stocare. Ce răspunde metadatele despre tranzacții, cine, ce tranzacție, unde se află în stiva aplicației și apoi avem vizibilitate profundă la nivel de cod pentru a vă arăta ce se execută. Aceste informații sunt captate continuu, introduse în baza de date de management de performanță - care devine o singură fișă de muzică pentru toată lumea să vadă ce se întâmplă. Există diferite persoane și organizații care le pasă de ceea ce se întâmplă: experții tehnici, proprietarii de aplicații, în cele din urmă afacerea în sine. Când apare o problemă, doriți să puteți extrage informații despre acea tranzacție.
Înainte de a ne uita la tranzacția de investiții, vreau să vă arăt cum ar putea să apară asta pentru diferite persoane din organizație. La un nivel de management, s-ar putea să doriți să aveți o imagine de ansamblu a mai multor aplicații. S-ar putea să doriți să aflați despre starea de sănătate calculată conform conformității și disponibilității SLA. Că sănătatea nu înseamnă că totul funcționează perfect la sută. Există loc în acest caz, puteți vedea tranzacția de investiții este în starea de avertizare. Acum, puțin mai adânc, poate în linia de afaceri, doriți să aveți câteva detalii suplimentare despre tranzacțiile individuale, atunci când încalcă SLA-urile, numărul tranzacțiilor etc. Echipa de operațiuni va dori să fie înștiințată despre asta printr-o alertă a unora fel. Avem alerte de performanță încorporate. Mărim efectiv performanța în browserul utilizatorului final. Fie că este vorba de Internet Explorer, Chrome, Firefox etc., putem detecta, aceasta răspunde la prima întrebare: are o problemă pentru utilizatorul final?
Hai să ne scufundăm și să vedem ce altceva putem arăta despre asta. Persoanele interesate de performanță ar deschide Precis. Ar evalua tranzacțiile. S-ar uita la coloana SLA pentru a identifica tranzacțiile care nu respectă SLA. Vor putea vedea utilizatorii finali care au fost afectați, precum și ce a făcut acea tranzacție în timp ce a trecut prin aplicație. Modul în care descifrați aceste hieroglife sunt: acesta este browserul, URL-ul, U este pentru URL, acesta este punctul de intrare în JVM. Acum, acest JVM particular face un apel web la cel de-al doilea JVM care apoi execută instrucțiunea SQL. Aceasta este în mod clar o problemă a bazei de date, deoarece această declarație SQL a fost responsabilă pentru 72 la sută din timpul de răspuns. Suntem concentrați pe timp. Timpul este moneda performanței. Este modul în care utilizatorii finali experimentează dacă lucrurile rulează lent sau nu, și este o măsură a consumului de resurse. Este foarte la îndemână; este un fel de o singură măsură care este cea mai importantă pentru evaluarea performanței. Când această problemă este transmisă DBA, nu este doar o problemă a bazei de date, ci este această declarație SQL. Acesta este contextul despre care vorbeam.
Acum înarmat cu aceste informații, pot să intru în analiză ce s-a întâmplat. Pot vedea în primul rând, axa y este timpul de-a lungul zilei. Scuzați-mă, axa y este timpul de răspuns, axa x este timpul de-a lungul zilei. Pot vedea că există o problemă a bazei de date, există două apariții, reveniți la fluxul respectiv, ridicați acea instrucțiune SQL și accesați vizualizarea de expert, unde Preciza este în măsură să vă arate ce se întâmplă, controalele sale, cât timp durează acel cod a executa. În nivelul bazei de date, este planul de execuție. Veți observa că Precise a ales planul real de execuție care a fost utilizat la momentul de execuție, care se distinge de planul estimat, care ar fi atunci când a fost dat planul și nu în timpul execuției. Poate sau nu să reflecte faptul că baza de date a fost efectiv.
Acum aici, este o analiză a timpului de răspuns pentru instrucțiunea SQL. Nouăzeci la sută din timpul petrecut în depozitare; zece la sută au fost utilizate în procesor. Pot vedea textul declarației SQL, precum și raportul constatărilor. Textul instrucțiunii SQL începe de fapt să dezvăluie unele probleme de codare. Este stea selectă; care returnează toate rândurile - scuzați-mă, toate coloanele din rândurile care au fost returnate. Revenim coloane suplimentare de care poate sau nu are nevoie aplicația. Aceste coloane consumă spațiu și resurse pentru procesare. Dacă executați SAP, una dintre marile modificări, deoarece baza de date HANA este columnară, este că, practic, rescrierea SAP pentru a nu alege steaua selectată, astfel încât acestea pot reduce mult consumul de resurse. Acesta este practic ceva care se întâmplă foarte mult timp și în aplicațiile casnice, fie Java, .NET etc.
Acest ecran vă arată cine, ce, când, unde și de ce. De ce ajunge, ca instrucțiunea SQL și planul de execuție care vă permite să rezolvați probleme. Deoarece Precise rulează continuu, puteți măsura efectiv înainte și după, la nivelul instrucțiunii SQL, la nivel de tranzacție, deci fie puteți măsura atât pentru dvs., cât și prin intermediul proprietarilor de aplicații și pentru management, că ați rezolvat problema . Documentația este foarte utilă. În această stivă de aplicații există o mulțime de complexități. Dintre multe aplicații, de fapt, toată lumea cu care am vorbit, rulează cel puțin o porție de stivă de aplicații sub VMware. În acest caz, aceștia se uită la aplicația de servicii pentru clienți, se uită la timpul de tranzacție și o corelează cu încetinirea este un eveniment de virtualizare. Urmărirea precisă a tuturor evenimentelor de virtualizare. Avem un plug-in la vCenter pentru a ridica asta.
De asemenea, putem detecta conținutul. Menținerea este diferită de utilizarea. Arătând de fapt când poate un vecin zgomotos afectează VM-ul oaspete, în contextul aplicației serverului client. Acum, sunt capabil să perfecționez și să obțin informații și pot vedea efectiv cele două VM-uri care se ocupă, în acest caz, pentru resursele procesorului. Acest lucru îmi permite să am vizibilitate, astfel încât să mă uit la programare. Pot pune un VM invitat pe un server fizic diferit. Toate aceste tipuri de lucruri pe care le-ați putea răspunde și apoi, în plus, mă pot uita efectiv la eficiența codului pentru a putea să-l folosească mai puțin procesor. Cred că am un exemplu destul de bun în această prezentare a modului în care cineva a fost capabil să reducă consumul procesorului prin comenzi de mărime.
Acesta a fost VMware. Haideți să intrăm în codul în sine, codul aplicației. Precis va putea să vă arate ce se întâmplă în Java, .NET, codul ABAP, E-Business, PeopleCode, etc. Acestea sunt punctele de intrare în, în acest caz, în WebLogic. Aici este un raport privind rezultatele care îmi spune că este vorba despre aceste EJB pe care trebuie să le analizați și care îmi va spune că aveți și blocarea în acest sistem. Încă o dată, efectuați drumul în interiorul nivelului de logică de afaceri, pentru a arăta ce se întâmplă. În acest caz, mă uit la anumite cazuri; De asemenea, sprijin clustering. Dacă aveți numeroase JVM-uri rulate, puteți să priviți clusterul în ansamblu sau să priviți blocaje în JVM-ul individual.
Pe măsură ce intri în blocare, pot intra în excepții. Excepția este puțin diferită de o problemă de performanță. De obicei, excepțiile se execută foarte repede. Deoarece există o eroare logică și după ce ați lovit acea eroare logică, aceasta se termină. Am reușit să surprindem o urmă de stivă la prima excepție, acest lucru ar putea economisi mult timp, deoarece trece prin încercarea de a descoperi ce se întâmplă, ai doar urmă de stivă, chiar acolo. De asemenea, putem capta scurgeri de memorie. Soluția include și nivelul bazei de date, pot intra, pot evalua instanța bazei de date. Încă o dată, axa y este locul în care a fost petrecut timpul, axa x este timpul de-a lungul zilei. Există un raport al constatărilor care îmi spune automat ce se întâmplă în sistem și la ce aș putea privi.
Unul dintre aspectele referitoare la rezultatele raportului Precise, nu privește doar jurnalele sau starea de așteptare, ci privește toate stările de execuție, inclusiv procesorul, precum și returnarea informațiilor din stocare. Depozitarea este o parte foarte importantă a stivei de aplicații, în special cu apariția stării solide. A avea informații de-a lungul acestor linii poate fi foarte util. Pentru anumite unități de stocare, putem efectua derularea și arata ce se întâmplă la nivelul dispozitivului individual. Acest tip de informații - încă o dată, este vizibilitate profundă; are un domeniu larg de aplicare - pentru a vă oferi doar suficiente informații pentru a avea mai mult efect de a trage ca profesionist în performanța aplicației, astfel încât să puteți optimiza aplicațiile dvs. de la capăt la capăt pentru a face față acestor tranzacții de afaceri.
Am câteva studii de caz pe care am vrut să le împărtășesc. Ne deplasăm destul de repede; Sper să merg într-un ritm în regulă. Vorbind despre stocare, toată lumea schimbă hardware-ul în timp. Există o garanție hardware. A livrat cu adevărat ceea ce v-a spus vânzătorul? Puteți evalua asta cu Precise. Intrați și ce s-a întâmplat aici, practic au introdus o nouă unitate de stocare, dar când administratorii de stocare s-au uitat doar la nivelul unității de stocare, au văzut foarte multă contenție și au crezut că ar putea exista o problemă cu această nouă unitate de stocare . Privind mai mult dintr-o perspectivă end-to-end, tocmai pentru a arăta unde s-ar întâmpla asta de fapt. De fapt, au trecut de la o capacitate de aproximativ 400 meg pe secundă, unde stocarea a fost responsabilă pentru 38 la sută din timpul de răspuns, deci este destul de mare. Cu noua unitate de stocare am redus efectiv volumul până la șase, șapte sute de megas pe secundă, deci practic dublu, și putem reduce contribuția la nivelul de stocare la timpul de tranzacție la jumătate. Sunt în stare să grafic de fapt că înainte, aceasta este perioada de tăiere, și apoi după.
Așa că, încă o dată, documentația a dovedit că investiția hardware a meritat și au livrat așa cum se așteptase acel vânzător. Există toate, din cauza complexității, a numărului de lucruri, se pot întâmpla tot felul de lucruri. În acest caz, au avut de fapt o situație în care toată lumea a blamat DBA, DBA a fost ca „Ei bine, nu atât de repede.” Aici ne uităm de fapt la o aplicație SAP, cred că acest tip de scenariu este destul de comun. . Ceea ce s-a întâmplat a fost că au dezvoltat o tranzacție personalizată pentru un utilizator. Utilizatorul este ca: „Acest lucru este atât de lent.” Coderul ABAP - acesta este limbajul de programare în SAP - a spus: „Aceasta este o problemă a bazei de date.” Au sfârșit deschizând Precisă; au măsurat acel utilizator final 60 de secunde, atât de bine peste un minut. Cincizeci și trei de secunde au fost petrecute în partea din spate. Au forat în partea din spate și au putut de fapt să dezvăluie instrucțiunea SQL prezentată în ordine descrescătoare.
Această declarație SQL de top care este responsabilă pentru 25 la sută din consumul de resurse, timpul său mediu de execuție este de două milisecunde. Nu poți blama baza de date. Știi, hei, nu atât de repede, tip. Întrebarea este: de ce există atât de multe execuții? Ei bine, au recuperat-o către ABAP, el a intrat, s-a uitat la cuibarea buclei, a aflat că sună baza de date în locul greșit, practic au făcut schimbarea, au testat schimbarea și acum noul timp de răspuns este cinci secunde. Un pic cam lent, dar ar putea trăi cu asta. Mult mai bine decât 60 de secunde. Uneori, pur și simplu deprimat, este codul aplicației, este baza de date, este stocare? Acestea sunt domeniile în care Precise, având contextul tranzacțiilor end-to-end, este locul în care Precise intră în joc. Practic, puneți capăt acestor lucruri.
Mă uit la timp, se pare că mai avem un pic de timp pentru a parcurge încă câteva. Strecur prin acestea. Această aplicație a fost în curs de dezvoltare de peste un an. Când au intrat în QA, au văzut că serverele web au fost reduse cu maximum 100 la sută și se pare că aplicația nu poate rula sub VMware. Primul lucru pe care l-a spus toată lumea a fost: „Puneți asta pe fizică; nu poate rula sub VMware. ”Precisele le-au oferit modalități suplimentare de a rezolva problema. Ne-am uitat la tranzacții, am văzut un apel pe serverul web, acesta intră ca ASMX în IIS.NET. De fapt a dezvăluit codul de bază. Vedeți asta unde am indicat? Acest lucru este de 23 de zile, 11 ore. Unde, cum este posibil? Ei bine, fiecare invocare durează 9, 4 secunde și acest lucru este invocat de 215.000 de ori. Pentru fiecare invocare, folosește 6 secunde de procesor. Acesta este motivul, acest cod este motivul pentru care acest lucru nu ar putea niciodată să se extindă. De fapt, nu se putea extinde la nivel fizic.
Ce au făcut, s-au întors la dezvoltatorii lor și au spus: „Poate cineva să facă o schimbare?” Au avut un concurs și au testat diferitele sugestii și au venit cu o sugestie care a putut rula mult mai eficient. Noua a completat un punct, puțin mai puțin de două secunde, cu două sutimi de secundă în procesor. Acum, acest lucru ar putea crește și s-ar putea executa în ferma VMware. Practic, am putut să ne documentăm atât la nivel de cod, cât și la nivel de tranzacție. Acesta este un fel de înainte și apoi de după. Acum că puteți vedea aici în graficul de bare de stivă care prezintă web, .NET și baza de date, acum interacționați cu baza de date. Acesta este un profil pe care așteptați să-l vedeți pentru o aplicație care rulează mai normal.
Bine, aleg și aleg în funcție de lucruri suplimentare pe care vi le pot arăta. Multora le place acest lucru, deoarece acest pat de pat de multe magazine. Dacă nu reușești să întâlnești un SLA de afaceri și toată lumea este de genul: „Ajută-ne să ieșim.” Acest magazin a avut o situație în care SLA-ul de afaceri este în comenzi primite până la 15:00, este livrat în acea zi. Este într-adevăr vital că primesc comenzile, iar depozitul este foarte ocupat. Acest ecran de comenzi de vânzări al JD Edwards, a fost înghețat și vă puteți face o idee foarte bună că acesta este un sistem de gestionare a stocurilor de vânzare cu amănuntul, la timp. Rafturile goale sunt inacceptabile în comerțul cu amănuntul. Trebuie să am acolo marfa pentru a o putea vinde. Ce am făcut este să ne scufundăm, în acest caz, ne uităm la baza de date a serverului SQL. Aspectul este același, indiferent dacă este SQL, Oracle, DB2 sau Sybase.
Am identificat selecția din PS_PROD și reușim să surprindem durata, fapt ce execută atât de mult. Albastrul închis s-a potrivit cu cheia care a spus că nu așteaptă o stare de așteptare sau o anumită înregistrare sau chiar stocare - acest lucru este legat de procesor. Am urmărit instrucțiunea SQL până la 34301, astfel încât de fiecare dată când aceasta este executată, creștem contoarele noastre pentru a le urmări. Asta înseamnă că avem un istoric detaliat și îl pot accesa făcând clic pe butonul de ton. Iată fila istoric. Acest ecran arată aici durata medie față de modificări. Miercuri, joi, vineri, durata medie a fost de aproximativ două zecimi de secundă. Foarte puține blocuri de ecran, sunt capabile să îndeplinească SLA de afaceri. Vino pe 27 februarie, ceva se schimbă și tot timpul brusc, de execuție este aici, și de fapt este destul de lent pentru a provoca intervale de timp, ceea ce duce la înghețarea ecranului. Precis, prin păstrarea unui istoric detaliat, inclusiv a planului de execuție și a modificărilor generale ale indexurilor tabelului dacă SQL este utilizat. Am putut să alegem că planul de acces sa schimbat pe 27 februarie. Luni până vineri săptămâna proastă. Vino 5 martie, planul de acces s-a schimbat din nou. Aceasta este o săptămână bună. Această stea roz ne spune volumul actualizat.
Puteți vedea aici numărul de rânduri din tabelele subiacente este în creștere și acest lucru este tipic pentru o afacere. Vrei să crească mesele tale. Chestia este că instrucțiunile sunt analizate, intră instrucțiunile SQL, optimizatorul trebuie să decidă ce să facă și să aleagă când planul de execuție este rapid, să aleagă un alt plan de execuție când este lent, ceea ce provoacă înghețarea ecranului. Pe baza tehnologiei profunde, trebuie să știu care este planul de execuție și să-l capteze precis pentru mine, completând data și ora. Acesta este cel care a fost rapid și eficient, acesta este cel care a fost lent și ineficient. Această unire de filtru folosește pur și simplu mult mai mult procesor pentru a reconcilia, pentru a face această afirmație SQL. Acestea au în continuare același efect final, dar acesta are practic o rețetă mai lentă, mai puțin eficientă pentru furnizarea setului de rezultate. Deci, trecem. Hei, mai avem timp pentru câteva cuvinte?
Eric Kavanagh: Da, mergi pentru asta.
Bill Ellis: Bine, voi sări înainte. Un lucru despre care vreau să luați o notă, am vorbit despre hardware, am vorbit despre SAP, am vorbit despre .NET, am vorbit despre JD Edwards și despre mediul Java-SQL Server. Acesta este SAP, aici ne uităm la PeopleSoft. Matricea de susținere precisă este largă și profundă. Dacă aveți o aplicație, mai mult decât probabil, o putem instrumenta pentru a oferi acest nivel de vizibilitate. Una dintre cele mai mari schimbări care se întâmplă chiar acum este mobilitatea. PeopleSoft a introdus mobilitatea cu UI-ul său fluid. Interfața de utilizare fluidă utilizează un sistem foarte diferit. Această aplicație evoluează. Interfața de utilizare fluidă - ceea ce face din perspectiva managementului este că permite utilizatorilor finali să își folosească telefonul și crește foarte mult productivitatea. Dacă aveți sute sau mii sau chiar mai mulți angajați, dacă le puteți crește productivitatea, 1-2 procente, puteți avea un impact uriaș asupra salariilor și a tuturor celorlalte. Ceea ce s-a întâmplat a fost faptul că acest magazin special a lansat UI Fluid PeopleSoft. Acum, vorbind despre complexitate, acesta este stiva PeopleSoft. O aplicație, cel puțin șase tehnologii, numeroși utilizatori finali. Cum o porniți?
Încă o dată, Precise va putea urmări aceste tranzacții. Ceea ce vă arătăm aici este un grafic de bare stivuit care prezintă client, server web, Java, baza de date Tuxedo, stivă de aplicații PeopleSoft. Hărțile verzi pentru J2EE, care este un fel de mod de a spune WebLogic. Acesta este cutoverul. Utilizatorii finali încep să utilizeze Fluid UI și timpul de răspuns variază de la o oră și jumătate, două secunde, până la aproximativ nouă, zece secunde. Ceea ce nu arată acest ecran este numărul de persoane care „nu răspund”. De fapt, au obținut blocarea ecranului în aplicație. Să aruncăm o privire la o parte din vizibilitatea pe care Precise le poate oferi acestui client.
În primul rând, când mă uit la tranzacțiile PeopleSoft, ei pot vedea practic, am văzut acest tip de lucruri peste tot. Toate tranzacțiile au fost afectate, precum și toate locațiile. De altfel, când te uiți la asta, poți vedea de fapt locații din întreaga lume. Din Asia Pacific, în Europa, precum și în America de Nord. Problema de performanță nu a fost localizată într-o anumită tranzacție sau o anumită locație geografică, este largă în sistem. Este un fel de a spune că modificarea sau modul în care UI Fluid a avut impact global. Puteți vedea aici din punct de vedere al scalabilității, oamenii încearcă să facă același tip de activitate, dar timpul de răspuns practic este doar degradat și degradat. Puteți vedea că lucrurile nu se scalează. Lucrurile merg foarte, foarte prost. Aici, când mă uit la numărul de axe și conexiunile concomitente, vedeți ceva care este foarte interesant în ceea ce privește numărul de acces și conexiunile. Aici facem doar o scalare de până la aproximativ 5.000 și te uiți la acest lucru, care se ridică la 100 de conexiuni concomitente. Aceasta se face după; aceasta este înainte. Așadar, ceea ce cererea mea reală pentru sistem, dacă acest lucru ar putea să se extindă, este în gama de 300.000. Pe vremuri, cu UI-ul clasic, te uiți la 30 de conexiuni simultane.
Acum, ceea ce vă spune acest lucru este că UI Fluid utilizează cel puțin 10x numere de conexiuni simultane. Începem să tragem înapoi ceea ce se întâmplă sub copertile cu PeopleSoft, astfel încât să puteți începe să vedeți impactul asupra serverelor web, faptul că SLA-urile încep să încalce. Nu vor merge în toate, dar ceea ce sfârșește întâmplându-se este că, practic, se bazează pe mesagerie. Practic, exercițiul este WebLogic și provoacă coada în Tuxedo. De fapt, a apărut o problemă de dependență multitieră care a apărut cu Fluid UI, dar Precise a putut să arate că printr-o mulțime de lucruri diferite, ne putem concentra asupra problemei care a fost. Se dovedește că a existat și o problemă în baza de date în sine. Există de fapt un fișier jurnal de mesagerie și, din cauza tuturor utilizatorilor concurenți, acel fișier jurnal a fost blocat. Practic, aveau lucruri de reglat, în fiecare nivel de aplicație. Vorbim despre complexitate, aici este de fapt nivelul Tuxedo care vă arată coada și puteți vedea performanța degradând și în acest nivel. Am putut vedea procesele; Am putut vedea domeniile și serverele. În Tuxedo, pentru ca oamenii să-l folosească, de obicei, ceea ce faceți este să deschideți cozi, domenii și servere suplimentare, la fel ca la supermarket pentru a scăpa de congestionare, pentru a reduce timpul de așteptare. Ultima și ultima opțiune, Precise arată multe informații.
Așa cum am menționat anterior, fiecare tranzacție semnificativă interacționează cu sistemul de înregistrări. Vizibilitatea în baza de date este primordială. Afișare precisă se întâmplă în baza de date, în WebLogic, în Java, .NET, în browser, dar locul pe care Precise îl excelează cu adevărat este în nivelul bazei de date. Aceasta se întâmplă să fie slăbiciunea concurenților noștri. Permiteți-mi să vă arăt unul dintre modurile prin care Precise v-ar putea ajuta să treceți prin asta. Nu voi petrece timp pe triunghiul optimizării bazelor de date, dar ne referim, practic, la costuri reduse, cu riscuri reduse, la modificări de tip larg, cu risc ridicat, de tip ridicat. De fapt, voi extinde acest slide apoi dacă oamenii vor să încerce să-l privească. Este un ghid destul de mare, cred, pentru probleme de reglare. Iată vizualizarea Precise for Oracle. În topul raportului constatărilor, impactul de 60% este această afirmație SQL special. Dacă deschideți acest ecran de activitate, îl afișează acolo. Pot să mă uit la această afirmație selectă, există un singur plan de execuție. Fiecare execuție durează o secundă - 48.000 de execuții. Asta însumează încă 48.000 de ore de execuții.
Albastrul închis, încă o dată, este CPU. Acest lucru este legat de procesor, nu o stare de așteptare, nu un jurnal. Subliniez faptul că, deoarece unii dintre concurenții noștri se uită doar la stările de așteptare și la evenimentele de înregistrare, dar, în general, procesorul este cea mai aglomerată stare de execuție și oferă cel mai mult ramburs. Intrând în această perspectivă expertă - și merg foarte repede - ceea ce am făcut este să mă uit la tabel, 100.000 de rânduri, 37.000 de blocuri. Facem un tabel complet, dar avem șase indici în această privință. Ce se petrece aici? Ei bine, atunci când mă uit la clauza unde, ceea ce face această clauză este că, de fapt, se transformă o coloană în majuscule și se spune unde este egală cu majuscule, găsiți variabila. Ceea ce se întâmplă este de fiecare dată când acest lucru se execută, Oracle trebuie să transforme această coloană în majuscule. În loc să faci asta de aproape cincizeci de mii de ori, este mult mai eficient să construiești acel indice cu majusculele unui indice bazat pe funcții și este disponibil nu numai în diviziunea întreprinderii Oracle, ci și în divizia standard. Când faceți acest lucru, ceea ce puteți face este să verificați planul de execuție care emite acel nou utilizator de index pentru majuscule, asta a fost doar un lucru al meu.
Apoi, dintr-o măsurare înainte și după aceea, te uiți la o durată de execuție de o secundă, agregate până la 9 ore 54 minute, cu aceeași instrucțiune SQL exactă, dar având acel index construit cu majuscule pentru 58.000 de execuții, răspunsul timpul scade la sub-milisecunde, se adună împreună, ajunge până la șapte secunde. Practic, am salvat zece ore de procesor pe serverul meu. Acest lucru este imens. Pentru că, dacă nu mi se datorează o actualizare a serverului, pot să trăiesc pe serverul respectiv. De fapt, scad utilizarea serverului cu 20% și puteți vedea de fapt înainte și după. Acesta este tipul de vizibilitate pe care Precise îl poate oferi. Există, de asemenea, câteva lucruri suplimentare pe care le-am putea privi, de ce aveți toți acești indici dacă nu sunt folosiți? Ei pot urmări acest lucru. Există arhitectură și o voi încheia, de vreme ce ajungem în vârful orei. Sunt un credincios adevărat în această soluție și dorim să fiți un credincios adevărat. La IDERA credem că un proces face un client, așa că, dacă sunteți interesat, putem face evaluări pe site-ul dvs.
Cu asta, voi trece baliza înapoi.
Eric Kavanagh: Da, acest lucru a fost un detaliu extraordinar pe care l-ai arătat acolo. Este foarte fascinant. Cred că poate v-am menționat în trecut că - și știu în unele din celelalte transmisiuni web pe care le-am făcut cu IDERA, am menționat asta - am urmărit de fapt Precise încă de când a fost achiziționat de IDERA, cred că până în 2008, cred, sau 2009. Am fost fascinat de ea atunci. Sunt curios să știu cât de mult se lucrează pentru a rămâne în topul noilor versiuni de aplicații. Ați menționat că SAP HANA, care cred că a fost destul de impresionant că puteți săpa de fapt în arhitectura HANA și puteți face unele probleme de rezolvare. Câți oameni aveți? Cât de mult este un efort din partea ta și cât din asta se poate face oarecum dinamic, ceea ce înseamnă că atunci când instrumentul este dislocat, începi să te înghesui și să vezi lucruri diferite? Cât de mult din asta poate fi dinamic, sortat, verificat de instrument, astfel încât să puteți ajuta oamenii să rezolve probleme de mediu complexe?
Bill Ellis: Ai pus multe întrebări acolo.
Eric Kavanagh: Știu, îmi pare rău.
Bill Ellis: Am oferit multe detalii, deoarece pentru aceste aplicații, privind codul, diavolul este în detaliu. Trebuie să ai acel nivel de detalii pentru a putea avea cu adevărat ceva care să poată fi acționat. Fără măsuri acționabile, știți doar despre simptome. De fapt nu rezolvi probleme. IDERA este despre rezolvarea problemelor. A rămâne la curent cu noile versiuni și chestii este o provocare mare. Întrebarea ce trebuie pentru a face asta, aceasta este într-adevăr pentru managementul produsului. Nu am prea multă vizibilitate în echipă, care practic ne ține la curent cu lucrurile. În ceea ce privește HANA, acesta este de fapt un nou plus la linia de produse IDERA; este foarte interesant. Unul dintre lucrurile cu HANA este - permiteți-mi să vorbesc despre sarcină pentru o secundă. În cadrul sarcinii, magazinele SAP ar face este să reproducă baza de date în scopuri de raportare. Apoi, va trebui să îi împăcați pe oameni cu ceea ce este actual. Ați avea aceste baze de date diferite și ar fi sincronizate pe niveluri diferite. Există doar mult timp și efort, plus hardware-ul, software-ul și oamenii pentru a menține toate acestea.
Ideea HANA de a avea o bază de date in memorie extrem de paralelă, pentru a evita practic necesitatea unei baze de date duplicate. Avem o singură bază de date, o singură sursă de adevăr, este mereu actualizat, astfel evităm necesarul de a face toată această reconciliere. Importanța performanței bazei de date HANA crește - Voi spune 10x sau cel puțin mai valoroasă decât suma tuturor celorlalte baze de date, hardware, resurse pot fi cumpărate. Fiind capabil să gestionați HANA, acum acea componentă este de fapt în testare beta chiar acum, este ceva ce va merge GA în curând. Așadar, este destul de interesant pentru IDERA și pentru noi să sprijinim practic platforma SAP. Nu sunt sigur ce alte părți ale întrebării dvs. am cam schimbat, dar -
Eric Kavanagh: Nu. Sunt lucruri bune acolo. Am aruncat o grămadă întreagă deodată, atât de rău pentru asta. Sunt doar fascinat, într-adevăr, vreau să spun că nu este o aplicație foarte simplă, nu? Săriți în profunzime în aceste instrumente și să înțelegeți cum interacționează între ele și, până la punctul dvs., trebuie să creați povestea împreună în cap. Trebuie să combinați biți de informații pentru a înțelege ce se întâmplă de fapt și ceea ce vă provoacă probleme, astfel încât să puteți intra acolo și să rezolvați aceste probleme.
Un participant se întreabă, cât de dificil este să implementăm Precisă? O altă persoană a întrebat, cine sunt oamenii - în mod evident DBA-uri - dar cine sunt alte alte roluri în organizație care ar folosi acest instrument?
Bill Ellis: Precis este puțin mai complicat de implementat. Trebuie să aveți cunoștințe despre mediul aplicației, în termeni de, știți, această aplicație rulează pe această bază de date, are nevoie sau - servere web de nivel mediu, etc. Cred că având în vedere complexitatea unora dintre aceste aplicații, de fapt este relativ ușor. Dacă pot instrumenta serverul web până la baza de date, pot face asta de la capăt la capăt. Observați că nu am spus nimic despre instrumentarea unui client utilizator final și asta pentru că ceea ce facem este, de fapt, includem dinamic, deci nu trebuie să vă schimbați codul sau nimic altceva. Un JavaScript intră în cadrul paginii aplicației. Indiferent unde se află utilizatorul în lume, atunci când accesează URL-ul din aplicația dvs. și dau jos pagina respectivă, vine instrumentat cu Precise. Acest lucru ne permite să alegem ID-ul utilizatorului, adresa lor IP, de asemenea, primul timp de redare a byte-ului fiecăruia dintre timpul de execuție a scriptului componentelor paginii din browserul utilizatorului final.
În ceea ce privește tranzacțiile, nu trebuie să evidențiați tranzacțiile, deoarece acestea sunt strâns cuplate. Această adresă URL devine un punct de intrare în JVM și apoi a invocat acest mesaj, rezultând un JVC prins din baza de date. Practic, suntem capabili să surprindem acele puncte de conexiune naturale și apoi să vi le prezentăm în ecranul de tranzacție pe care vi l-am arătat unde am calculat și cât timp sau procentul de timp petrecut în fiecare etapă individuală. Toate acestea se fac automat. În general, alocăm 90 de minute de făcut - practic instalăm nucleul precis și apoi începem să implementăm aplicația. În funcție de cunoștințele aplicației, este posibil să ne ducă câteva sesiuni suplimentare pentru a obține instrumentarea întregii aplicații. Multe persoane folosesc doar componenta bazei de date Precise. E in regula. Practic, puteți rupe acest lucru, puteți să-l separați în componentele de care credeți că aveți nevoie de site-ul dvs. Credem cu siguranță că contextul în care instrumentul întreg a stivei de aplicații este astfel instrumentat, astfel încât să puteți vedea că dependența de la nivel la nivel mărește de fapt valoarea monitorizării unui nivel individual. Dacă cineva dorește să exploreze instrumentarea stivei de aplicații în continuare, vă rugăm să accesați site-ul nostru web - cred că acesta este cel mai simplu mod de a solicita informații suplimentare și vom discuta puțin mai departe.
Eric Kavanagh: Permiteți-mi să vă arunc una sau două întrebări rapide. Cred că colectați și construiți un depozit de-a lungul timpului, atât pentru clienții individuali, cât și ca entitate corporativă în general, de interacțiuni între diverse aplicații și diverse baze de date. Cu alte cuvinte, cred că modelarea scenariului este ceea ce fac aluzie. Este cazul? Păstrezi de fapt un fel de depozit de scenarii comune, astfel încât să poți face sugestii utilizatorilor finali atunci când intră în joc anumite lucruri? Ca această versiune a E-Business Suite, această versiune a acestei baze de date etc. - faceți o mare parte din asta?
Bill Ellis: Ei bine, acest tip de informații sunt încorporate în raportul constatărilor. Raportul concluziilor spune care sunt blocajele de performanță și se bazează pe timpul de execuție. O parte din raportul constatărilor este să aflați mai multe și ce faceți în continuare. Informațiile sau experiența de la clienți ș.a. sunt în principiu incluse în biblioteca de recomandări.
Eric Kavanagh: Bine, sună bine. Ei bine, oameni buni, prezentare fantastică astăzi. Bill, mi-a plăcut cât de multe detalii ai avut acolo. M-am gândit doar că acestea sunt informații cu adevărat fantastice, grizonate, granulare, care arată cum se fac toate aceste lucruri. La un moment dat este aproape ca magia neagră, dar, într-adevăr, nu este. Este o tehnologie foarte specifică pe care o îmbinați pentru a înțelege medii foarte complexe și pentru a face oamenii fericiți, deoarece nimeni nu îi place când aplicațiile rulează lent.
Ei bine, oameni buni, vom arhiva acest webcast. Puteți să urcați online la Techopedia sau insideanalysis.com și wow, mulțumim pentru timpul acordat, vă vom contacta la data viitoare. Aveți grijă, adio.
