Af Techopedia Staff, 2. november 2016
Takeaway: vært Eric Kavanagh diskuterer applikationsydelsen og hvordan man forbedrer effektiviteten med Dr. Robin Bloor, Dez Blanchfield og IDERAs Bill Ellis.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Mine damer og herrer, hej og velkommen igen til Hot Technologies. Ja bestemt! Mit navn er Eric Kavanagh, jeg vil være din vært for en anden webcast i dag i denne virkelig sjove, spændende serie, vi har fået som et kompliment til vores Briefing Room-serie. Titlen er "Applikationsacceleration: hurtigere ydelse for slutbrugere." Kom nu folk, hvem vil ikke det? Hvis jeg er fyr derude, der hjælper din ansøgning med at løbe hurtigere, tænker jeg, at jeg er den fyr, der får øl, der er købt til mig i baren efter arbejde. Det skal være en ret cool ting at gå i og fremskynde nogens anvendelse.
Der er et lysbillede om din virkelig, slå mig op på Twitter @Eric_Kavanagh. Jeg prøver altid at følge tilbage, og jeg tweeter altid igen, hvis du nævner mig, så velkommen til at nævne mig.
Hele formålet med dette show er at fokusere på forskellige aspekter af virksomhedsteknologi og virkelig hjælpe med at definere bestemte discipliner eller visse ansigter, hvis du vil. Mange gange vil leverandører indhente bestemte markedsføringsbetingelser og tale om, hvordan de gør dette eller det eller en anden ting. Dette show var virkelig designet til at hjælpe vores publikum med at forstå, hvad et software-værktøj skal have for at være førende inden for dets rum. Formatet heraf er to analytikere. Hver går først, i modsætning til det briefingsrum, hvor sælgeren går først. Hver af dem tager det, de synes er vigtigt for dig at vide om en bestemt type teknologi.
I dag taler vi om applikationsacceleration. Vi hører fra Dez Blanchfield og også doktor Robin Bloor - vi er over hele verden i dag - og så ringer Bill Ellis ind fra det større Virginia-område. Med det overleverer jeg det til vores første præsent, Dr. Bloor. Vi tweetede hashtaggen til #podcast forresten, så føl dig fri til at tweet. Tage det væk.
Dr. Robin Bloor: Okay, tak for den introduktion. Applikationspræstationer og serviceniveau - dette er et slags område, jeg har gjort en masse arbejde på dette område i årenes løb, i den forstand, at jeg faktisk har arbejdet meget for at overvåge ydeevne og træne i et måde eller en anden, hvordan man prøver at beregne disse niveauer. Det må siges, at indtil - vi plejede at have denne æra for et stykke tid siden, hvor folk byggede systemer i siloer. Grundlæggende er det meget arbejde, de faktisk skal gøre for at få et system til at fungere rimeligt godt, hvis det var i en silo, faktisk ikke var for hårdt, fordi der er meget lille, meget lille mængde af variabler, du var nødt til at tage højde for. Så snart vi fik ordentligt netværk, kom interaktiv og serviceorientering i ligningen. Det blev lidt vanskeligt. Ydeevne kan være en-dimensionel. Hvis du bare tænker på et program, der udfører en bestemt kodesti gentagne gange, føles det med rimelighed på rettidig måde som en en-dimensionel ting. Så snart du begynder at tale om serviceniveau, taler du faktisk om flere ting, der konkurrerer om computerressource. Det bliver multidimensionelt meget hurtigt. Hvis du begynder at tale om forretningsprocesser, kan forretningsprocesser trådes sammen fra flere applikationer. Hvis du taler om serviceorienteret arkitektur, kan en given applikation faktisk få adgang til flere applikations muligheder. Så bliver det en meget kompliceret ting.
Jeg kiggede på - for længe siden tegnede jeg dette diagram. Dette diagram er mindst 20 år gammelt. Grundlæggende kalder jeg det Diagram over Alt, fordi det er en måde at se på alt, hvad der findes i IT-miljøet. Det er egentlig kun fire stykker: brugere, data, software og hardware. Naturligvis ændrer de sig over tid, men du er faktisk klar over, når du ser på dette, at der er en hierarkisk eksplosion af hver enkelt af disse stykker. Et hardware ja, en hardware kan være en server, men en server består muligvis af flere CPU'er, netværksteknologi og hukommelse, og dette, slags en frygtelig masse controllere, som det sker. Hvis du faktisk ser på dette, bryder det hele ned i stykker. Hvis du rent faktisk tænker på at prøve at orkestrere alt dette, med hensyn til data, der ændrer, softwarens ydelse ændres, fordi hardware ændres osv., Ser du faktisk på en utroligt vanskelig multi-variat situation. Dette er kompleksitetskurven. Selvfølgelig er det kompleksitetskurve for næsten alt, men jeg har set det tegnet gang på gang, når jeg taler om computere. Grundlæggende, hvis du lægger noder på den ene akse og de vigtige forbindelser på den anden akse, ender du med en kompleksitetskurve. Det betyder næsten ikke noget, hvad knudepunkter og forbindelser er, og det vil gøre, hvis du vil have en repræsentation af volumenvæksten i telefonnettet.
Faktisk, når du taler om knudepunkter i computermiljøet, taler du om individuelle ting, der bryder sig om hinanden. Kompleksitet, det viser sig at være, et spørgsmål om variation struktur og de forskellige begrænsninger, som du prøver at overholde. Også tallene. Når tallene stiger, bliver de skøre. Jeg havde en interessant chat i går, jeg talte med nogen - jeg kan ikke nævne, hvem han var, men det betyder ikke rigtig noget - de talte om et websted, der havde 40.000 - det er fire-nul, 40.000 - forekomster af databaser på siden. Bare tænk på det - 40.000 forskellige databaser. Selvfølgelig var det eneste, vi havde - de havde tydeligvis mange, mange tusinder af applikationer. Vi taler om en meget stor organisation, men jeg kan ikke navngive den. Du ser faktisk på det, og du prøver faktisk på en eller anden måde at få serviceniveau, der vil være tilstrækkeligt overalt for nogle flere brugere, med flere forskellige, hvis du vil, forventninger. Det er en kompleks situation, og alt det, jeg virkelig siger, er, at disse ting er komplekse. Antallet stiger altid. Begrænsningerne bestemmes af forretningsprocesser og forretningsmæssige mål. Du har bemærket, at forventningerne ændrer sig.
Jeg kan huske, så snart Gmail, Yahoo-mail og Hotmail, alle disse postsystemer kom op, folk begyndte at have en forventning om, at deres interne postsystemer i organisationen ville fortjene serviceniveauet for disse enorme operationer med store serverfarme uden for organisationen og begyndte at blive presset for at få alt det slags til at ske. Faktisk er aftaler på serviceniveau en ting, men forventning er en anden ting, og de bekæmper hinanden inden for en organisation, en akavet ting. Her er bare et forretningsperspektiv. I nogle systemer er den optimale responstid en tiendedel af et sekund af den menneskelige responstid. En tiendedel af et sekund er den tid, det tager en cobra at bide dig. Hvis du står foran en cobra, og den beslutter at bide dig, er det for sent, det sker, fordi du ikke kan svare på en tiendedel af et sekund. En tiendedel af et sekund handler om den tid det tager for bolden at forlade hånden på kanden for at nå fyren med flagermus. Grundlæggende, når han ser bolden kastet, er han nødt til at svare på nøjagtigt det tidspunkt. Menneskelig respons, en slags interessant ting. Software-til-software kan naturligvis have en højere forventning.
Derefter kommer du ind i nogle situationer, som jeg tror er de markedssituationer, hvor det at være først er hvor forretningsværdien er. Dette er som hvis du vil sælge en bestemt aktie på aktiemarkedet sandsynligvis er mindre, for eksempel fordi du tror, det går ned, og mange andre mennesker synes, at det går ned, får du den bedste pris, hvis du først kommer på markedet. Der er en masse situationer, annoncevisning og lignende ting, meget lignende situation. Du har denne bevægelse med hensyn til forventning på serviceniveau. Du har en ting, der er en slags glasloft til menneskelig reaktion. Når det først er software til software, hvis du har denne loftssituation, er der ikke noget bedste serviceniveau. Hurtigere end alle andre er bedst.
Okay, dette er, tror jeg, det sidste lysbillede, som jeg lavede, men dette er bare for at give dig et stort billede af kompleksiteten, når du først ser på en organisations krav, tjenesten. Du har, når du går op i venstre side her, har du systemadministration, som er et sæt software, der tjener til servicestyring, som prøver at styre et serviceniveau. Over det har du fået forretningsprestationsstyring. Så hvis du ser nedefter her, området service management automatisering, har du fragmenterede tjenester, der udvikler sig til standardiserede tjenester, hvis du rent faktisk interesserer dig for at investere i denne slags ting, der udvikler sig til integrerede tjenester, der udvikler sig til optimerede tjenester . Det, folk ofte har gjort, er kun i nederste venstre hjørne af dette. Måske en smule servicestyring. Forvaltningsstyring, meget sjælden. Fragmenteret, næsten det hele. En perfekt verden ville fylde dette gitter. Instrumentering - Jeg nævnte et underoptimeringsproblem. Du kan optimere dele af et system, og det er ikke godt for hele systemet. Hvis du gør hjertet optimalt, kan dit blod muligvis cirkulere for hurtigt til resten af dine organer. Det er et problem med store organisationer og serviceniveau. Der er helt klart intet, der vil blive opnået uden sofistikerede værktøjer, fordi variablerne netop har fået - godt der er for mange variabler til at prøve og optimere.
Når det er sagt, overgår jeg til Dez, der forhåbentlig vil tale om noget andet.
Dez Blanchfield: Tak, Robin. Ligesom Dr. Robin Bloor har jeg brugt alt for mange år på at tænke på ydelsen af meget komplekse systemer i meget stor skala. Sandsynligvis ikke helt den samme skala som Robin, men præstation er et dagligt emne, og det er en del af vores DNA at ønske ydeevne, for at få det bedste ud af alt. Faktisk har jeg brugt en grafik af en af mine foretrukne ting i verden, Formel I-bilracing, hvor hele planeten sidder stille et stykke tid og ser biler gå rundt i cirkler meget hurtigt. Hvert eneste aspekt, der er intet aspekt af formel I, der ikke specifikt handler om at få ydeevne. Mange mennesker poo-poo sporten, fordi de synes, det er spild af penge. Det viser sig, at bilen, vi kører hver eneste dag for at droppe børnene i fodbold i weekenden og på skolen de andre dage, stammer fra præstationsbaseret udvikling og forskning. Det er slags livet i Formel I-bilracing. Hverdagsteknologi, hverdagsvidenskab, kommer ofte af lignende som noget, der har været fokuseret udelukkende på høj ydeevne.
Realiteten er dog, at vores nye ”altid på” verden, der kræver 100 procent oppetid - som Robin nævnte tidligere - med ting som introduktion af webmail og andre tjenester, vi tager for givet i kontinuerligt rum, og vi forventer nu, at vores virksomhed og arbejdsmiljø. Virkeligheden er, at det at være ude ikke altid betyder, at du opfylder din serviceaftale. Jeg har taget dette behov for at administrere applikationsydelse og aftaler om serviceniveau har gennemgået et grundlæggende skift i det sidste årti. Vi prøver ikke bare at bekymre os om ydeevnen i et system længere. Når verden var lidt enklere, har vi måske en situation, hvor en enkelt server, der kører flere tjenester, kan overvåges live, og det var relativt ligetil at understøtte. Vi kunne - og her er min lille, de ting, vi plejede at bekymre os om, da jeg for eksempel var en systemadministrator for mange år siden - vi ville se os om, er tjenesten typisk op og svarer? Kan jeg f.eks. Logge ind på en terminal? Reagerer operativsystemet, og kan jeg indtaste kommandoer? Kører applikationerne? Kan jeg se processer og hukommelse i at gøre ting og I / O på tværs af netværket og så videre? I mainframe-dagene kunne du høre bånd, der gik zip-zip-zip og papir falder ud af dem.
Svarer apperne, og kan vi logge ind og gøre ting på dem? Er brugerne i stand til at oprette forbindelse til nogle af disse servere? Det fortsætter. De er ret grundlæggende, ved du. Så et par sjove - er helpdesken grøn? For hvis ikke, løber alting fint, og hvem får donuts? Livet var virkelig enkelt i disse dage. Selv i disse dage, og så taler jeg for 20-30 år siden, var kompleksiteten stadig rigtig høj. Vi kunne på en relativt ligetil måde styre aftaler på serviceniveau og holde øje med ydeevnen. Vi kan ikke gøre det i hånden mere, som Robin antydede. Udfordringen er for stor. Faktum er det tidspunkt, hvor et par gode apps, administratorer, systemnetværk og database, administratorer kan overvåge og imødekomme SLA'ers ydelse. SLA’er er så langt væk nu, at jeg kæmpede i går aftes, da jeg lagde mine endelige noter til endda at tænke på året, hvor jeg sidst formåede at se på et system med en meget kompleks stak, og give mening af det og endda forstå, hvad der var foregår under hætten, og jeg kommer fra en dybt teknisk baggrund. Jeg kan ikke forestille mig, hvordan det er at se det dagligt nu på en administrativ måde.
Hvad skete der? I 1996 blev databasestyrede apps transformeret med internetboom. Mange af os har været igennem det. Selv hvis du ikke var omkring internetboom, kan du nemt bare se dig omkring og indse, at vi i hverdagen kobler alt sammen til internettet nu. Jeg tror, vi har en brødrister, der tilsyneladende kommer med muligheden for at komme på Wi-Fi, hvilket er latterligt, fordi jeg ikke har brug for min brødrister tilsluttet internettet. I 2000'erne, især de tidlige 2000'ere, var vi nødt til at tackle den enorme vækst i kompleksitetsrunden, der leverede serviceydelse i dot-com boom. Derefter endnu en latterlig akavet gnist i web 2.0, hvor smartphones kom til og nu var applikationer i vores hænder døgnet rundt og var altid tændt.
Det er 2016 nu, vi står over for en anden quagmire i form af sky og big data og mobilitet. Dette er systemer, der bare er så store, at de ofte er vanskelige at forstå og på engelsk. Når vi tænker på det faktum, at nogle af de store enhjørninger, vi taler om, har titusinder af hundrede petabytes med data. Dette er hele gulvet med diskplads og opbevaring bare for at holde din e-mail, billeder og sociale medier. Eller i nogle tilfælde inden for transport og forsendelseslogistik, alt sammen i bank, det er hvor dine penge er, eller hvor din post er, eller din, hvor den ting, du har købt på eBay, er. Den næste store bølge, vi er ved at stå over for, er denne meget tunge udfordring med tingenes internet.
Hvis dette ikke var dårligt nok, er vi ved at bygge kunstig intelligens og kognitiv computing til næsten alt. Vi taler med Siri og Google-motorer i disse dage. Jeg ved, Amazon har en af sine egne. Baidu har en af disse enheder, hvor du kan tale med, de konverterer den til tekst, der går i et normalt system, databasen opretter en forespørgsel og kommer tilbage og vender processen. Tænk på kompleksiteten, der går ind i det. Realiteten er, at kompleksiteten i nutidens standardapplikationsstakke er langt ud over menneskelige evner. Når du tænker over alt, hvad der sker, når du trykker på en knap på din smartphone-enhed eller din tablet, taler du til det, konverterer det til tekst, kører det hele vejen til internettet til et back-end-system, en front-end modtager at konverterer det til en forespørgsel, kører forespørgslen gennem en applikationsstabel, går gennem en database, rammer en disk, kommer ud igen, og i midten er der et transportnetværk, der er et lokalt netværksstatuscenter. Kompleksiteten er gal.
Vi hævder effektivt dette som hyperscale. Kompleksiteten og hastigheden af hyperscale er bare øjenvanding. Applikationer og databaser er blevet så store og så komplekse, at styring af ydeevne faktisk er en videnskab i sig selv. Mange omtaler det som en raketvidenskab. Vi har teknologi på stedet, vi har offsite-teknologi, vi har en række muligheder for datacentre; fysisk og virtuel. Vi har fysiske og virtuelle servere, vi har sky, vi har infrastruktur som en service og platform, da en service og software, da en service er en ting, vi nu tager for givet. Det sidstnævnte, software som en tjeneste, blev skræmmende for et stykke tid for et par år siden, da CFO'er og dele af organisationen indså, at de kunne hente deres kreditkort og bare købe ting selv og gå rundt i CIO og effektivt kaldte vi denne "skygge IT ”og CIO’erne forsøger nu at vinde denne tilbage og kæmpe kontrol igen.
I infrastruktur har vi softwaredefineret netværk, virtualiseringsnetværk under det, vi har, sandsynligvis over, nu har vi mikrotjenester og apps af aktive tjenester. Når du klikker på en URL, er der en masse forretningslogik, der sidder i slutningen af den URL, der beskriver, hvad den har brug for for faktisk at levere den. Det har ikke nødvendigvis forudbygget logik, der venter på det. Vi har traditionelle databaser på den ene side, der skalerer meget, meget store. Vi har lignende Hadoop-infrastruktur og økosystemer i det andet spektrum, der er lige så store, at som jeg sagde, du ved, folk taler om hundreder af petabytes data nu. Vi har kompleksitetsmobilitet så vidt angår enheder, der bærer rundt, bærbare computere og telefoner og tablets.
Vi har BYOD i nogle lukkede miljøer og i stigende grad nu, da de erfarne Gen Y medbringer deres egne enheder. Vi lader dem bare tale med dem om webgrænseflader. Enten over internettet eller via Wi-Fi har vi en gratis Wi-Fi i caféen nedenunder, når de spiser kaffe. Eller vores interne Wi-Fi. Maskine-til-maskine er altid til stede nu. Det er ikke direkte en del af tingenes internet, men det er også relateret. Internettet af ting er et helt nyt spil med en kompleksitet, der er sindssyg. Kunstig intelligens, og hvis du synes, at det, vi spiller med nu, med alle Siri og andre relaterede enheder, vi taler med, er kompliceret, skal du vente til du kommer til en situation, hvor du ser noget kaldet Olli, som er en 3D trykt bus, der tager omkring seks personer og kan køre sig selv rundt i byen, og du kan tale almindeligt engelsk til den, og den vil tale tilbage til dig. Hvis det rammer trafik, vil det beslutte at dreje til venstre eller højre fra hovedområdet, hvor der er trafik. Når det drejer, og du bliver bekymret for, hvorfor det drejes til venstre eller højre fra hovedvejen, vil det sige til dig: ”Vær ikke bange, jeg er ved at dreje til venstre. Der er trafik forude, og jeg vil gå omkring det. ”
At styre ydeevnen for alle systemer derinde og al den kompleksitet, spore hvor disse data går, om de går ind i databasen, alle sammenkoblinger og alle de relevante bits er bare tanker at forveksle. Virkeligheden er, at styring af ydeevne og SLA'er i nutidens hastighed og skala kræver værktøjer og systemer, og som standard er dette ikke længere noget, hvor du bare synes, det ville være dejligt at have et værktøj - det er en forudsætning; det er bare absolut nødvendigt. Her er noget lige som et lille eksempel, en liste over applikationsdesigndiagrammer på højt niveau til OpenStack, open source software-defineret sky. Dette er bare en stor del. Dette er ikke kun servere og database. Det er her, hver lille blå klat repræsenterer klynger af ting. I nogle tilfælde kører filer og servere eller hundreder af databaser eller naturligvis ikke mere end titusinder af små stykker applikationslogik. Det er en lille version. Det er virkelig helt ubehageligt, når man begynder at tænke på den kompleksitet, der opstår i dette. I dag, selv i bare det store dataplads, lægger jeg bare nogle skærmbilleder af kun mærkerne. Når du tænker på alle de stykker, vi er nødt til at styre her, så taler vi ikke kun om et mærke nødvendigvis, dette er alle mærker i big data-landskabet og det øverste brand, ikke kun hver lille lille eller open source. Du ser, og du synes, det er et ganske sjovt diagram.
Lad os bare se på et par vertikaler. Lad os tage marketing f.eks. Her er et lignende diagram, men fra teknologibunkerne, der er tilgængelige alene i marketingteknologi. Dette er grafen for 2011. Her er 2016-versionen. Bare tænk over, dette er kun antallet af mærker af produkter, du kan køre til teknologi med hensyn til marketingteknologi. Ikke kompleksiteten af systemerne derinde, ikke den forskellige app og web og udvikling og netværk og alt det andet. Bare mærket. Der er før, for fem år siden, og her er i dag. Det bliver kun værre. Vi er på dette tidspunkt nu, hvor virkeligheden er, mennesker kan simpelthen ikke sikre alle aftaler på serviceniveau. Vi kan ikke dykke i detaljer nok, hurtigt nok og i den skala, vi har brug for. Her er et eksempel på, hvordan en overvågningskonsol ser ud nu. Dette er som næsten tyve-ulige skærme limet sammen og foregiver at være en stor, stor projiceret skærm, der overvåger hvert lille stykke. Nu er det interessant herinde, jeg vil ikke nævne mærket, men denne overvågningsplatform overvåger en enkelt applikation i et logistik- og forsendelsesmiljø. Bare en app. Hvis du tænker over, hvad Robin talte om, hvor organisationer kan have 40.000 databaser nu i produktionsmiljøer. Kan du bare visualisere, hvad 40.000 versioner af denne samling af skærme, der overvåger et program, kunne være? Det er en meget modig verden, vi lever i. Som Robin sagde, og jeg vil absolut, 100 procent gentage, at uden de rigtige værktøjer, uden den rigtige støtte og folk på bordet ved hjælp af disse værktøjer, er applikationsydelse et tabt spil for mennesker og det skal gøres af værktøjer og software.
Med det vil jeg videregive til vores venner i IDERA.
Eric Kavanagh: Okay, Bill.
Bill Ellis: Tak. Deling af min skærm her. Jeg gætte, kan nogen bekræfte, at du kan se min skærm?
Dr. Robin Bloor: Ja.
Eric Kavanagh: Det ser godt ud.
Bill Ellis: Tak. Den ene ting, han refererede til, var, at jeg virkelig ikke kan vente på, var den selvkørende bil. Den ene ting, som jeg ikke havde hørt nogen tale om, er, hvad sker der, når det snør? Jeg spekulerer på, om ingeniørerne i Californien indså, at det i andre dele af landet snør ganske lidt.
Dez Blanchfield: Jeg kan godt lide det, jeg vil huske den.
Eric Kavanagh: En typisk kilometer i timen.
Bill Ellis: Vi er her for at tale om applikationsprestationsstyring i et komplekst miljø. Én ting, jeg kan lide at tale om, er mange mennesker, når de taler om ydeevne, reaktionens art er, hej flere servere, mere CPU, mere hukommelse osv. Den anden side af denne mønt er behandlingseffektivitet. Virkelig, det er to sider af den samme mønt, og vi vil se på dem begge. Det ultimative mål er at opfylde serviceaftalerne for forretningstransaktionerne. I sidste ende findes al denne teknologi for virksomheden. Vi talte om at have en branchen-første performance management database. Det ideelle er at passe ind i den ideelle form for ydeevne og styre den fra starten af applikationens livscyklus.
Emnerne koger virkelig ned til fire stykker; den ene er processen med at styre præstationer. Vi talte med alle, og alle har værktøjer. Hvis de ikke har værktøjer, har de scripts eller kommandoer, men det, de mangler, er kontekst. Kontekst er blot at forbinde prikkerne på tværs af applikationsstakken. Disse applikationer til - er browserbaseret. De er meget tæt koblet fra niveau til niveau. Hvordan niveauerne interagerer er også afgørende. Derefter taler vi om forretningstransaktionen. Vi vil give synligheden ikke kun for de tekniske mennesker, men også for applikationsejere og driftsledere.
Jeg har et par casestudier for bare at dele med dig, hvordan kunderne har brugt disse. Dette er en meget praktisk del af præsentationen her. Lad os se på, hvad der typisk sker. Jeg kan godt lide at diagramme - det var ligesom en utrolig collage af teknologier. Antallet af teknologier i datacentret er lige vokset og vokset og vokset. I mellemtiden er en slutbruger ligeglad med det og glemmer det. De vil bare udøve transaktionen, få den til rådighed, have den hurtigt afsluttet. Hvad der typisk sker, er, at fagfolk inden for IT ikke er klar over, at slutbrugerne endda havde et problem, indtil de selvrapporterer. Det starter med en tidskrævende, langsom proces og ofte frustrerende. Hvad der sker er, at folk åbner deres værktøjer, og de ser på en undergruppe af deres applikationsstabel. Med denne undergruppe bliver det meget vanskeligt at besvare det enkleste spørgsmål. Er det sædvanligt, at du har problemet? Hvilken transaktion er det? Hvor i applikationsstakken er flaskehalsen? Ved at bruge hele denne tid, se niveau efter niveau, ikke være i stand til at besvare disse spørgsmål, ender du med at bruge en masse tid og energi, en masse personale, midler og energi slags at finde ud af.
For at løse dette for at give en bedre måde, hvad Precise gør, er faktisk at tage slutbrugerens sportransaktion, indfanger metadata om det, følger transaktionen gennem netværket, ind på webserveren, ind i forretningslogik-niveauet og vi understøtter .NET og ABAP og PeopleCode og E-Business Suite i multitier-applikationer, der i sidste ende alle transaktioner vil interagere med postsystemet. Uanset om det er en opgørelse af inventar, rapporteret arbejdstid, interagerer de altid med databasen. Databasen bliver grundlaget for forretningspræstationer. Databasen på sin side er afhængig af lagring. Hvad metadataene om transaktionerne svarer på, hvem, hvilken transaktion, hvor i applikationsstakken, og så har vi dyb synlighed på kode niveau for at vise dig, hvad der udføres. Denne information indfanges kontinuerligt, sættes i performance management databasen - der bliver et enkelt ark musik for alle at se, hvad der foregår. Der er forskellige mennesker og organisationer, der er interesserede i, hvad der sker: de tekniske eksperter, applikationsejere, i sidste ende selve virksomheden. Når et problem kommer ud, vil du være i stand til at udtrække oplysninger om denne transaktion.
Før vi ser på investeringstransaktionen, vil jeg vise dig, hvordan det kan se ud for forskellige mennesker i organisationen. På en administrationsniveaus ønsker du måske et overblik over flere applikationer. Du ønsker måske at vide om det helbred, der beregnes af SLA's overholdelse og tilgængelighed. At helbredet betyder ikke, at alt fungerer 100 procent perfekt. Der er plads i dette tilfælde, hvor du kan se, at investeringstransaktionen er i advarselsstatus. Nu, lidt dybere, måske inden for branchen vil du have nogle yderligere detaljer om individuelle transaktioner, når de overtræder SLA'er, transaktionstællinger osv. Operationsteamet ønsker at blive underrettet om det gennem en advarsel fra nogle sortere. Vi har indbyggede præstationsalarmer. Vi måler faktisk ydelsen i slutbrugerens browser. Uanset om det er Internet Explorer, Chrome, Firefox osv., Vi er i stand til at registrere, svarer dette på det første spørgsmål: har en slutbruger et problem?
Lad os dykke ind og se hvad vi ellers kan vise om det. De mennesker, der er interesseret i performance, vil åbne op for Precise. De ville evaluere transaktionerne. De ser på SLA-kolonnen for at identificere transaktioner, der ikke var SLA-kompatible. De ville være i stand til at se slutbrugerne, der blev påvirket, såvel som hvad transaktionen gjorde, da den flød over applikationen. Den måde, du dechiffrerer disse hieroglyfier er, dette er browseren, URL'en, U er til URL, det er indgangspunktet i JVM. Nu gør denne særlige JVM en webserver til den anden JVM, der derefter udfører SQL-sætningen. Dette er helt klart et databaseproblem, fordi denne SQL-erklæring var ansvarlig for 72 procent af responstiden. Vi er fokuseret på tiden. Tid er præstationens valuta. Det er, hvordan slutbrugerne oplever, om ting kører langsomt eller ej, og det er et mål for ressourceforbrug. Det er meget praktisk; det er slags en enkelt metrik, der er mest vigtig for evaluering af ydeevne. Når dette problem afleveres til DBA, er det ikke kun et databaseproblem, det er denne SQL-sætning. Dette er den sammenhæng, jeg talte om.
Nu bevæbnet med disse oplysninger kan jeg gå ind og analysere hvad der er sket. Jeg kan først se, y-aksen er tid over dagen. Undskyld, y-aksen er responstid, x-aksen er tid over dagen. Jeg kan se, at der er et databaseproblem, der er to forekomster, gå tilbage til denne strøm, afhent den SQL-erklæring og gå ind i ekspertvisningen, hvor Precise er i stand til at vise dig, hvad der sker, dens kontroller, hvor lang tid den kode tager udføre. I databasesystemet er det eksekveringsplanen. Du vil bemærke, at Precise valgte den rigtige udførelsesplan, der blev brugt på udførelsestidspunktet, som adskilles fra den estimerede plan, som ville være, når planen blev givet og ikke i udførelsestiden. Det afspejler måske ikke, at databasen faktisk gjorde.
Nu her nede er en svartid analyse for SQL-sætningen. Halvfems procent af tiden brugt på opbevaring; ti procent blev brugt i CPU'en. Jeg kan se teksten i SQL-erklæringen såvel som fundets rapport. Teksten til SQL-sætningen begynder faktisk at afsløre nogle kodningsproblemer. Det er valgt stjerne; der returnerer alle rækker - undskyld mig, alle kolonner fra de rækker, der blev returneret. Vi vender yderligere kolonner, som applikationen muligvis ikke har brug for. Disse kolonner forbruger plads og ressourcer til behandling. Hvis du kører SAP, er en af de store ændringer, fordi HANA-databasen er søjleformet, det grundlæggende omskrivning af SAP for ikke at vælge udvalgt stjerne, så de kan reducere ressourceforbruget meget. Dette er dybest set noget, der sker meget tid også i hjemmegroede applikationer, hvad enten Java, .NET osv.
Den skærm, dette viser dig, hvem, hvad, hvornår, hvor og hvorfor. Hvorfor kommer man til, ligesom SQL-sætningen og eksekveringsplanen, der giver dig mulighed for at løse problemer. Fordi Precise kører kontinuerligt, kan du faktisk måle før og efter, på SQL-erklæringsniveau, på transaktionsniveau, så enten kan du måle for dig selv, såvel som gennem applikationsejere og til styring, at du har løst problemet . Denne dokumentation er virkelig nyttig. Der er en masse kompleksitet i denne applikationsstack. Af mange applikationer kører faktisk alle, vi har talt med, mindst en del af applikationsstakken under VMware. I dette tilfælde ser de på kundeserviceapplikationen, de ser på transaktionstid og korrelerer det med afmatningen er en virtualiseringshændelse. Præcis sporer alle virtualiseringsbegivenheder. Vi har et plug-in til vCenter for at hente det.
Vi er også i stand til at opdage strid. Stridighed er anderledes end udnyttelse. Viser faktisk, hvornår en støjende nabo måske påvirker din gæst VM i sammenhæng med kundeserverens applikation. Nu er jeg i stand til at bore ind og få information, og jeg kan faktisk se de to VM'er, der i dette tilfælde strider om CPU-ressourcer. Dette gør det muligt for mig at have synlighed, så jeg kan se på planlægning. Jeg kan placere en gæst VM på en anden fysisk server. Alle disse typer af ting, som du måske reagerer på, og så kan jeg udover det faktisk se på kodeeffektiviteten for måske at få den til at bruge mindre CPU. Jeg synes, jeg har et temmelig godt eksempel i denne præsentation af, hvordan nogen var i stand til at reducere CPU-forbruget med størrelsesordrer.
Det var VMware. Lad os gå ind i selve koden, programkoden. Precise vil være i stand til at vise dig, hvad der sker inden for Java, .NET, ABAP-koden, E-Business, PeopleCode osv. Dette er indgangspunkter til, i dette tilfælde, i WebLogic. Her nede er der en fundrapport, der fortæller mig, at det er disse EJB'er, du skal se på, og vil fortælle mig, at du også fik låsning på dette system. Endnu en gang boret ned i forretningslogik-niveauet for at vise, hvad der foregår. I dette tilfælde ser jeg på bestemte tilfælde; Jeg støtter også gruppering. Hvis du har adskillige JVM'er, der kører, kan du enten se på klyngen som helhed eller se på flaskehalse inden for den enkelte JVM.
Når du kommer i låsning, kan jeg få undtagelser. Undtagelse er lidt anderledes end et ydelsesproblem. Typisk kører undtagelser meget hurtigt. Fordi der er en logisk fejl, og når du først har ramt den logiske fejl, slutter den. Vi var i stand til at fange en stakespore på toppen af en undtagelse. Dette kunne spare en masse tid, da det går igennem at prøve at finde ud af, hvad der foregår, du har bare stakesporet lige der. Vi er også i stand til at fange hukommelseslækager også. Løsningen inkluderer også databasesystemet, jeg kan gå ind, jeg kan evaluere databaseinstansen. Endnu en gang er y-aksen, hvor tiden blev brugt, x-aksen er tid over dagen. Der er en rapport om resultater, der bare automatisk fortæller mig, hvad der sker i systemet, og hvad jeg måske ser på.
En af tingene ved Precises resultater rapporterer, at det ikke bare ser på logfiler eller ventetilstand - det ser på alle eksekveringstilstande inklusive CPU samt returnering af oplysninger fra lageret. Opbevaring er en meget vigtig del af applikationsstakken, især med fremkomsten af fast tilstand. Det kan være meget nyttigt at have information langs disse linjer. For visse lagringsenheder kan vi faktisk bore ned og vise, hvad der sker på det individuelle enhedsniveau. Den type information - endnu en gang er det dyb synlighed; det er bredt i omfang - for at give dig lige nok information til at have mere gearing til at trække som en applikationspræstationsprofessionel, så du kan optimere dine applikationer på en ende til ende basis for at imødekomme disse forretningstransaktioner.
Jeg har et par casestudier, jeg ville dele med dig. Vi sejler temmelig hurtigt sammen; Jeg håber, jeg går i et okay tempo. Når vi taler om opbevaring, skifter alle over tid hardware. Der er en hardware-garanti. Leverede det virkelig, hvad sælgeren fortalte dig? Du kan evaluere det med præcist. Du kommer ind, og hvad der skete her, de lagde dybest set en ny lagerenhed, men da lageradministratorerne bare kiggede på lagringsenhedsniveauet, så de en masse strid, og de troede, at der kunne være et problem med denne nye lagerenhed . Ser man mere fra et ende til ende perspektiv, netop for at vise, hvor det rent faktisk ville ske. De gik faktisk fra en kapacitet på omkring 400 meg per sekund, hvor lagringen var ansvarlig for 38 procent af responstiden, så den er temmelig høj. Med den nye lagerenhed fik vi faktisk gennemstrømningen til seks, syv hundrede megs pr. Sekund, så dybest set dobbelt, og vi er i stand til at skære lagerstyrets bidrag til transaktionstiden i halve. Jeg er i stand til faktisk at tegne det ud før, dette er cutover-perioden og derefter efterfølgende.
Så igen, dokumentation for at bevise, at hardwareinvesteringerne var det værd, og at de leverede, som den bestemt leverandør havde forventet. Der er alt, på grund af kompleksiteten, antallet af ting, der er alle slags ting, der kan ske. I dette tilfælde havde de faktisk en situation, hvor alle på den måde beskyldte DBA, DBA var som "Nå, ikke så hurtigt." Her ser vi faktisk på en SAP-applikation, jeg synes, at denne type scenarie er temmelig almindelig . Hvad der skete var, de udviklede en brugerdefineret transaktion for en bruger. Brugeren er som "Dette er så langsomt." ABAP-koderen - det er programmeringssproget i SAP - sagde, "Dette er et databaseproblem." De endte med at åbne Precise; de målte slutbrugeren 60 sekunder, så godt over et minut. Femogtredie sekunder blev brugt i bagenden. De borede i bagenden og de var faktisk i stand til at afsløre SQL-sætningen, der blev præsenteret i faldende rækkefølge.
Denne top SQL-sætning, der er ansvarlig for 25 procent af ressourceforbruget, dets gennemsnitlige eksekveringstid er to millisekunder. Du kan ikke skylde databasen. Hej, ikke så hurtigt, fyr. Spørgsmålet er, hvorfor er der så mange henrettelser? Nå, de sprang tilbage til ABAP, han gik ind, kiggede ind i indlejringen af løkken, fandt ud af, at de kaldte databasen på det forkerte sted, de lavede dybest set ændringen, testede ændringen og nu er den nye responstid fem sekunder. Lidt langsomt, men de kunne leve med det. Langt bedre end 60 sekunder. Nogle gange er det bare at friste ud, er det applikationskoden, er det databasen, er det opbevaring? Det er de områder, hvor præcise, ved at have sammenhængen til ende-til-ende-transaktioner, er det, hvor præcise kommer i spil. Du afslutter dybest set disse ting.
Jeg ser på det tidspunkt, ser ud til, at vi stadig har lidt tid til at gennemgå et par flere af disse. Jeg streamer gennem disse. Denne ansøgning var under udvikling i over et år. Da de gik i QA, så de, at webserverne blev maksimeret 100 procent, og det så ud som om applikationen ikke kunne køre under VMware. Den første ting, som alle sagde, var: ”Læg dette på fysisk; det kan ikke køre under VMware. ”Precise tilbød dem faktisk yderligere måder at løse problemet. Vi kiggede på transaktionerne, vi så et webserveropkald, det kommer ind som en ASMX i IIS.NET. Det afslørede faktisk den underliggende kode. Ser du det, hvor jeg peger? Dette er 23 dage, 11 timer. Wow, hvordan er det muligt? Nå, hver tilkaldelse tager 9, 4 sekunder, og denne ting påberåbes 215.000 gange. For hver opfordring bruger den 6 sekunder CPU. Dette er grunden, denne kode er grunden til, at denne ting aldrig kunne skaleres. Faktisk kunne det ikke skaleres i fysisk.
Hvad de gjorde, er de gik tilbage til deres udviklere, og de sagde: ”Kan nogen foretage en ændring?” De havde slags en konkurrence, og de testede de forskellige forslag, og de kom med et forslag, der var i stand til at køre meget mere effektivt. Den nye afsluttede et punkt, lidt mindre end to sekunder, med to hundrededel af et sekund i CPU. Nu kan dette skaleres, og det kunne køre på VMware-gården. Vi var i stand til dybest set at dokumentere det på både kodeniveau og transaktionsniveau. Dette er slags før og derefter efter. Nu, hvor du kan se her i stabelbjælken, der viser web, .NET og database, interagerer du nu med databasen. Dette er en profil, du ville forvente at se for et program, der kørte mere normalt.
Okay, jeg vælger og vælger med hensyn til yderligere ting, jeg kan vise dig. Mange mennesker kan lide dette, fordi dette bedazzles mange butikker. Hvis du ikke er i stand til at møde en virksomheds-SLA, og alle er som "Hjælp os med det." Denne butik havde en situation, hvor virksomheds-SLA er i ordrer, der er modtaget kl. 15, sendes den den dag. Er virkelig vigtigt, at de får ordrene ud, og lageret er meget travlt. Denne JD Edwards 'salgsordreskærm var frysende, og du kan få en meget god idé om, at dette er et just-in-time retailbeholdningssystem. Tomme hylder er uacceptable i detailhandelen. Skal have varerne der for at sælge den. Hvad vi gjorde er, at vi dykkede i, i dette tilfælde kigger vi på SQL-serverdatabasen. Udseendet er det samme, uanset om det er SQL, Oracle, DB2 eller Sybase.
Vi identificerede vælgeren fra PS_PROD, og vi er i stand til at fange varigheden, det faktum, at de udfører så meget. Den mørkeblå matchede nøglen, der sagde, at de ikke venter på nogen ventetilstand eller noget logning eller endda opbevaring - denne ting er bundet af CPU. Vi sporet SQL-sætningen af 34301, så hver gang dette udføres øger vi vores tællere for at holde styr på det. Det betyder, at vi har en detaljeret historie, og jeg kan få adgang til den ved at klikke på den melodiknap. Her er fanen Historik. Dette skærmbillede her viser gennemsnitlig varighed kontra ændringer. Onsdag, torsdag, fredag, var den gennemsnitlige varighed cirka to tiendedele af et sekund. Meget få skærmfrysninger, de er i stand til at imødekomme virksomhedens SLA. Komme den 27. februar, ændrer der sig noget, og pludselig er udførelsestiden her oppe, og det er faktisk langsomt nok til at forårsage timeouts, hvilket resulterer i frysning af skærmen. Præcise ved at føre en detaljeret historie, herunder eksekveringsplanen og generelle ændringer af tabellens indekser, hvis denne SQL er i brug. Vi kunne hente, at adgangsplanen ændrede sig den 27. februar. Mandag til fredags dårlige uge. Kom 5. marts ændrede adgangsplanen igen. Dette er en god uge. Denne lyserøde stjerne fortæller os, om lydstyrken er opdateret.
Her kan du se antallet af rækker i de underliggende tabeller vokser, og det er typisk for en virksomhed. Du vil have, at dine borde skal vokse. Sagen er, at udsagnene er parse, SQL-udsagnene kommer ind, optimeringsprogrammet skal beslutte, hvad de skal gøre, og vælge, når eksekveringsplanen er hurtig, vælg en anden eksekveringsplan, når den er langsom, hvilket forårsager, at skærmen fryser. På et dybt teknologisk grundlag er jeg nødt til at vide, hvad eksekveringsplanen er, og Precise indfanger den for mig komplet med dato og tidsstempel. Dette var den, der var hurtig og effektiv, det er den, der var langsom og ineffektiv. Dette filterforbindelse bruger simpelthen meget mere CPU til at forene, for at gøre netop denne SQL-sætning. De har stadig den samme ultimative effekt, men denne har dybest set en langsommere, mindre effektiv opskrift til at levere resultatsættet. Så vi går igennem. Hej, vi har tid til et par mere?
Eric Kavanagh: Ja, gå til det.
Bill Ellis: Okay, jeg springer videre. Én ting vil jeg have, at du noterer os, vi talte om hardware, talte om SAP, vi talte om. NET, vi talte om JD Edwards og Java-SQL Server-miljøet. Dette er SAP, her over ser vi på PeopleSoft. Precises understøttelsesmatrix er bred og dyb. Hvis du har en ansøgning, mere end sandsynligt, kan vi instrumentere den til at give dette niveau af synlighed. En af de største ændringer, der sker lige nu, er mobilitet. PeopleSoft introducerede mobilitet med dens Fluid UI. Fluid UI bruger et system meget forskelligt. Denne applikation er under udvikling. Fluid UI - hvad det gør fra et ledelsesperspektiv er det giver slutbrugerne mulighed for at bruge deres telefon, og det øger produktiviteten meget. Hvis du har hundreder eller tusinder eller endnu flere ansatte, hvis du kan øge deres produktivitet, 1-2 procent, kan du have en enorm indflydelse på lønningslisten og alt andet. Hvad der skete var, at denne bestemte butik rullede ud PeopleSoft Fluid UI. Nu taler vi om kompleksitet, dette er PeopleSoft-stakken. Én applikation, mindst seks teknologi, adskillige slutbrugere. Hvordan starter du det?
Endnu en gang vil Precise kunne følge disse transaktioner. Det, vi viser dig her, er en stablet søjlediagram, der viser klient, webserver, Java, Tuxedo-database, PeopleSoft-applikationsstabel. De grønne kort til J2EE, som er en slags fancy måde at sige WebLogic. Dette er overgangen. Slutbrugerne begynder at bruge Fluid UI, og responstiden går fra måske halvanden, to sekunder, op til omkring ni, ti sekunder. Hvad denne ene skærm ikke viser, er antallet af mennesker, der fik "ikke svarer." De fik faktisk skærmfrysning i applikationen. Lad os se på noget af den synlighed, som Precise er i stand til at give denne kunde.
Først og fremmest, når jeg ser på PeopleSoft-transaktionerne, kan de dybest set se, vi så denne type ting overalt. Alle transaktioner blev påvirket såvel som alle placeringerne. I øvrigt, når du ser på dette, kan du faktisk se steder rundt om i verden. Fra Asien og Stillehavet til Europa såvel som Nordamerika. Ydelsesproblemet var ikke lokaliseret til en bestemt transaktion eller en bestemt geografisk placering, det er hele systemet. Det er en slags måde at sige, at ændringen eller den måde, Fluid UI havde global indflydelse på. Her kan du se fra skalerbarhedsmæssigt synspunkt, folk forsøger at udføre den samme type aktivitetsmængde, men responstiden er dybest set bare forringet og nedbrudt. Du kan se, at tingene ikke skalerer. Ting går meget, meget dårligt. Over her, når jeg ser på aksetællingen og de samtidige forbindelser, ser du noget, der er meget interessant med hensyn til adgangstælling og forbindelser. Her skalerer vi kun op til ca. 5.000, og du ser på, det topper med 100 samtidige forbindelser. Dette gøres efter; dette er før. Så hvad min reelle efterspørgsel efter systemet er, hvis denne ting kan skaleres, er inden for 300.000. I gamle dage, med det klassiske UI, ser du på 30 samtidige forbindelser.
Hvad det nu fortæller dig, er, at Fluid UI bruger mindst 10x antal samtidige forbindelser. Vi begynder at trække tilbage, hvad der sker under dækkene med PeopleSoft, så du kan begynde at se indvirkningen på webserverne, det faktum, at SLA'er begynder at bryde. Ikke til at gå ind på alt, men det, der ender med at ske, er, at de stort set er afhængige af beskeder. De træner dybest set WebLogic og forårsager kø i Tuxedo. Der var faktisk et multitier afhængighedsspørgsmål, der dukkede op med Fluid UI, men Precise var i stand til at vise, at ved en hel masse forskellige ting, at vi kan fokusere på, hvad problemet var. Det viser sig, at der også var et problem i selve databasen. Der er faktisk en messaging-logfil, og på grund af alle de samtidige brugere låstede denne logfil. Grundlæggende havde det ting at indstille på hvert enkelt niveau i applikationsstakken. Tal om kompleksitet, her er faktisk Tuxedo-niveauet, der viser dig køen, og du kan også se ydelsen nedværdigende inden for dette niveau. Jeg kunne se processerne; Jeg kunne se domænerne og serverne. For mennesker, der skal bruge dette i Tuxedo, er det, hvad du gør, typisk at åbne yderligere køer, domæner og servere, ligesom i supermarkedet for at afhjælpe overbelastningen, for at minimere køtiden. Sidste og sidste mulighed, Precise viser en masse information.
Som jeg nævnte tidligere, interagerer enhver væsentlig transaktion med registreringssystemet. Synlighed i databasen er vigtig. Præcise viser, hvad der sker inden i databasen, i WebLogic, i Java, .NET, i browseren, men det sted, som Precise virkelig udmærker sig, er i databasens niveau. Dette sker som vores konkurrenters svaghed. Lad mig vise dig en af de måder, som Precise kan hjælpe dig med at gennemgå dette. Jeg vil ikke bruge tid på trekanten af databaseoptimering, men vi ser dybest set på lave omkostninger, lave risici, til vidt omfang, høje risiko, høje omkostningstypeskift. Jeg tweeter faktisk dette lysbillede bagefter, hvis folk vil prøve at se på det. Det er en ret stor guide til tuning af problemer. Her er Exise for Oracle ekspertvisning. Øverst på resultaterne af rapporten er virkningen på 60 procent netop denne SQL-erklæring. Hvis du åbner denne aktivitetsskærm, viser den den derude. Jeg kan se på denne valgte erklæring, der er en udførelsesplan. Hver henrettelse tager et sekund - 48.000 henrettelser. Det tilføjer op til 48.000 flere timers henrettelser.
Den mørkeblå, endnu en gang, er CPU. Denne ting er CPU bundet, ikke en ventetilstand, ikke en log. Jeg understreger, at fordi nogle af vores konkurrenter kun ser på ventetilstander og logningsbegivenheder, men generelt set, er CPU den travleste eksekveringstilstand og tilbyder det mest tilbagekøb. At komme ind i denne ekspertvisning - og jeg går meget hurtigt - hvad jeg gjorde, var at jeg kiggede på bordet, 100.000 rækker, 37.000 blokke. Vi laver en fuldtabel, men vi har dog seks indekser på denne ting. Hvad sker der her? Nå, når jeg ser på hvor klausulen, hvad det her, hvor klausul gør, er det faktisk at konvertere en kolonne til store bogstaver, og det siger, hvor det er lig med store bogstaver, find variabel. Hvad der sker, er, hver gang denne ting udføres, er Oracle nødt til at konvertere denne kolonne til store bogstaver. I stedet for at gøre det næsten halvtreds tusind gange, er det meget mere effektivt at opbygge dette indeks med store bogstaver i et funktionsbaseret indeks, og det er ikke kun tilgængeligt i Oracle virksomhedens afdeling, også standardafdeling. Når du gør det, hvad du derefter kan gøre er at bekræfte udførelsesplanen, der udsteder den nye indeksbruger perm store bogstaver, det var bare slags min ting.
Derefter, fra en før-og-efter måling, ser du på en sekunders eksekveringstid, aggregerer op til 9 timer 54 minutter med den samme nøjagtige SQL-sætning, men har det indeks indbygget med store bogstaver til 58.000 henrettelser, svaret tiden falder til under-millisekunder, samlet sammen, det kommer op til syv sekunder. Grundlæggende har jeg gemt ti timers CPU på min server. Dette er enormt. For hvis jeg ikke skal have en serveropdatering, kan jeg leve på denne server. Jeg taber faktisk denne serverforbrug med 20 procent, og du kan faktisk se før og efter. Det er den type synlighed, som Precise kan give. Der er også nogle yderligere ting, som vi måske ser på, hvorfor har du alle disse indekser, hvis de ikke bruges? De kan følge op med det. Der er arkitektur, og jeg vil pakke den op, da vi når toppen af timen. Jeg er en sand troende på denne løsning, og vi vil have dig til at være en sand troende. Hos IDERA mener vi, at en prøveversion gør en kunde, så hvis du er interesseret, kan vi foretage evalueringer på dit websted.
Med det passerer jeg fyret tilbage.
Eric Kavanagh: Ja, dette har været en enorm detalje, som du viste der. Det er virkelig ganske fascinerende. Jeg tror, at jeg måske har nævnt Dem i fortiden, at - og jeg ved i nogle af de andre webcasts, som vi har lavet med IDERA, har jeg nævnt det - jeg har faktisk sporet præcist siden det blev købt af IDERA, helt tilbage til 2008, tror jeg, eller 2009. Jeg blev fascineret af det dengang. Jeg er nysgerrig efter at vide, hvor meget arbejde der går i at blive oven på nye udgivelser af applikationer. Du nævnte, at SAP HANA, som jeg synes var temmelig imponerende, at du rent faktisk kan grave i HANA-arkitekturen og lave noget fejlfinding der. Hvor mange mennesker har du? Hvor meget af en indsats er det fra din side, og hvor meget af det kan gøres noget dynamisk, hvilket betyder, at når værktøjet bliver sat i gang, du begynder at kravle rundt og se forskellige ting? Hvor meget af det kan dynamisk, sorteres og konstateres af værktøjet, så du kan hjælpe folk med at løse komplekse miljøer?
Bill Ellis: Du stillede mange spørgsmål der.
Eric Kavanagh: Jeg ved, undskyld.
Bill Ellis: Jeg leverede en masse detaljer, for djævlen er i detaljerne, når jeg ser på koden. Du skal have det detaljeringsniveau for virkelig at være i stand til at have noget, der kan handles. Uden handlingsmæssige beregninger ved du bare om symptomer. Du løser faktisk ikke problemer. IDERA handler om at løse problemer. At være på toppen af de nye udgivelser og ting er en stor udfordring. Spørgsmålet om, hvad det kræver for at gøre det, det er virkelig til produktstyring. Jeg har ikke meget synlighed i teamet, der dybest set holder os ajour om tingene. Med hensyn til HANA er det faktisk en ny tilføjelse til IDERA-produktlinien; det er meget spændende. En af tingene med HANA er - lad mig tale om opgaven et øjeblik. I denne opgave ville SAP-butikkerne gøre, at de replikerer databasen til rapporteringsformål. Så bliver du nødt til at få folk til at forene sig med det, der faktisk er aktuelle. Du ville have disse forskellige databaser, og de er ude af synkronisering efter forskellige niveauer. Der er bare meget tid og kræfter, plus hardware, softwaren og folk til at vedligeholde alt det.
Ideen med HANA om at have en meget parallel database i hukommelsen, for dybest set at undgå behovet for duplikatdatabaser. Vi har en database, en kilde til sandhed, den er altid ajour. På den måde undgår du det nødvendige for at gøre al denne forsoning. Betydningen af udførelsen af HANA-databasen går op - jeg vil sige 10 gange eller i det mindste mere værdifuld end summen af alle disse andre databaser, hardware, ressourcer kan købe. At være i stand til at styre HANA, nu er denne komponent faktisk i beta-test lige nu, det er noget, der kommer til at gå GA snart. Så det er ret spændende for IDERA og for os grundlæggende at støtte SAP-platformen. Jeg er ikke sikker på, hvilke andre dele af dit spørgsmål jeg formåede, men -
Eric Kavanagh: Nej, det er alt godt derinde. Jeg kastede en hel masse på dig på én gang, så ked af det. Jeg er bare fascineret, virkelig, jeg mener, at dette ikke er en meget enkel applikation, ikke? Du graver dybt ned i disse værktøjer og forstår, hvordan de interagerer med hinanden, og til dit punkt, skal du slags dele historien sammen i dit hoved. Du er nødt til at kombinere bit af information for at forstå, hvad der faktisk sker, og hvad der forårsager dig besværet, så du kan gå ind der og løse disse problemer.
En deltager spørger, hvor vanskeligt er det at implementere præcist? En anden person spurgte, hvem er folket - tydeligvis DBA'er - men hvem er nogle andre roller i organisationen, der ville bruge dette værktøj?
Bill Ellis: Det præcise er lidt mere kompliceret at implementere. Du skal have noget kendskab til applikationsmiljøet, hvad angår, du ved, denne applikation kører på denne database, den har brug for eller - mellemtrin-webservere osv. Jeg tror, i betragtning af kompleksiteten i nogle af disse applikationer, det er faktisk relativt let. Hvis jeg kan instrumenter webserveren op til din database, kan jeg gøre det fra ende til anden. Du bemærker, at jeg ikke sagde noget om instrumentering af en slutbrugerklient, og det er fordi, hvad vi gør, vi faktisk inkluderer dynamisk, så du ikke behøver at ændre din kode eller noget andet. En JavaScript går ind i applikationssiderammen. Uanset hvor brugeren er i verden, når de får adgang til URL'en fra din applikation, og de bringer den side ned, kommer den instrumenteret med Precise. Det giver os mulighed for at vælge bruger-ID, deres IP-adresse, også den første byte-gengivelsestid for hver af sidekomponenternes script-udførelsestid i slutbrugerbrowser.
Med hensyn til transaktionerne behøver du ikke kortlægge transaktionerne, fordi de er tæt koblet. Denne URL bliver et indgangspunkt for JVM og påberåbes derefter denne meddelelse, hvilket resulterer i en JVC fanget fra databasen. Vi er dybest set i stand til at fange de naturlige forbindelsespunkter og derefter præsentere dem for dig i det transaktionsskærmbillede, som jeg viste dig, hvor vi også beregnet, hvor meget tid eller procentdelen af tiden, der blev brugt i hvert enkelt trin. Alt dette gøres automatisk. Generelt set afsætter vi 90 minutter til at gøre - til dybest set at installere den præcise kerne og derefter begynde at implementere applikationen. Afhængig af viden om applikationen kan det tage nogle ekstra sessioner for at få hele applikationen instrumenteret. Mange mennesker bruger bare databasekomponenten i Precise. Det er fint. Du kan dybest set bryde dette, opdele det i de komponenter, du har lyst til, at dit websted har brug for. Vi mener bestemt, at konteksten med at have hele applikationsstakken instrumenteret, så du kan se, at niveau-til-niveau-afhængighed faktisk forstørrer værdien af at overvåge et individuelt niveau. Hvis nogen ønsker at udforske instrumentering af deres applikationsstakke yderligere, skal du gå til vores websted - jeg antager, at det er den nemmeste måde at anmode om yderligere oplysninger, og vi vil diskutere det lidt videre.
Eric Kavanagh: Lad mig kaste et eller to hurtige spørgsmål til dig. Jeg gætter på, at du samler og opbygger et lager over tid, både for individuelle klienter og som en samlet virksomhedsenhed, af interaktioner mellem forskellige applikationer og forskellige databaser. Med andre ord, jeg antager, at scenarimodellering er det, jeg antyder. Er det tilfældet? Vedligeholder du faktisk en slags opbevaring af almindelige scenarier, så du kan komme med forslag til slutbrugere, når visse ting kommer i spil? Som denne version af E-Business Suite, denne version af denne database osv. - gør du meget af det?
Bill Ellis: Nå, den type information er indbygget i konklusionens rapport. Resultaterne rapporterer, hvad der er præstationsflaskehalse, og det er baseret på udførelsestidspunktet. En del af denne rapport er at lære mere, og hvad gør du derefter. Oplysningerne eller oplevelsen fra kunder og så videre er grundlæggende indarbejdet i det bibliotek med anbefalinger.
Eric Kavanagh: Okay, det lyder godt. Nå folkens, fantastisk præsentation i dag. Bill, jeg elskede, hvor meget detaljer du havde derinde. Jeg troede bare, at dette var virkelig fantastisk, grusomt, detaljeret information, der viste, hvordan alle disse ting gøres. På et bestemt tidspunkt er det næsten som sort magi, men det er det faktisk ikke. Det er meget specifik teknologi, som I fyrer sammensat for at forstå meget, meget komplekse miljøer og gøre folk glade, fordi ingen kan lide, når applikationer kører langsomt.
Nå folkens, vi arkiverer denne webcast. Du kan hoppe online til Techopedia eller insideanalysis.com og wow, tak for din tid, vi henter dig næste gang. Pas på, farvel.
