Av Techopedia Staff, 2. november 2016
Takeaway: Vert Eric Kavanagh diskuterer applikasjonsytelse og hvordan man kan forbedre effektiviteten med Dr. Robin Bloor, Dez Blanchfield og IDERAs Bill Ellis.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Mine damer og herrer, hei og velkommen igjen til Hot Technologies. Ja absolutt! Jeg heter Eric Kavanagh, jeg vil være din vert for nok en webcast i dag i denne virkelig morsomme, spennende serien som vi har fått som et kompliment til vår Briefing Room-serie. Tittelen er "Application Acceleration: Raskere ytelse for sluttbrukere." Kom igjen folk, hvem vil ikke det? Hvis jeg er fyren der ute og hjelper søknaden din til å løpe raskere, tenker jeg at jeg er fyren som får øl kjøpt til meg i baren etter jobb. Det må være en ganske kul ting å gå inn i og få fart på noens søknad.
Det er et lysbilde om deg, slo meg opp på Twitter @Eric_Kavanagh. Jeg prøver alltid å følge tilbake, og jeg tweet alltid om du nevner meg, så ta gjerne kontakt med meg.
Hele hensikten med dette showet er å fokusere på forskjellige aspekter ved enterprise teknologi og virkelig bidra til å definere bestemte disipliner eller visse ansikter, hvis du vil. Mange ganger vil leverandører plukke opp bestemte markedsføringsbetingelser og snakke om hvordan de gjør dette eller det eller en eller annen ting. Dette showet var virkelig designet for å hjelpe publikum til å forstå hva et programvareverktøy trenger å ha for å være ledende på verdensrommet. Formatet for dette er to analytikere. Hver går først, i motsetning til Briefing Room hvor leverandøren går først. Hver av dem tar på seg det de mener er viktig for deg å vite om en bestemt type teknologi.
I dag snakker vi om applikasjonsakselerasjon. Vi kommer til å høre fra Dez Blanchfield og også doktor Robin Bloor - vi er over hele verden i dag - og så ringer Bill Ellis inn fra det større Virginia-området. Med det skal jeg overlevere det til vår første programleder, Dr. Bloor. Vi tweetet hashtaggen til #podcast forresten, så føl deg fri til å tweet. Ta den bort.
Dr. Robin Bloor: Ok, takk for introduksjonen. Applikasjonsytelse og servicenivå - dette er et slags område, jeg har gjort mye arbeid på dette området i løpet av årene, i den forstand at jeg faktisk har gjort veldig mye arbeid med å overvåke ytelsen og trene i en måte eller en annen, hvordan du prøver å beregne disse nivåene. Det må sies at inntil - vi pleide å ha denne epoken for en stund siden, der folk bygde systemer i siloer. I utgangspunktet var mye arbeid de faktisk må gjøre for at et system skal fungere rimelig bra hvis det var i en silo, faktisk ikke var så vanskelig fordi det er veldig lite, veldig lite mengde variabler du måtte ta i betraktning. Så snart vi fikk ordentlig nettverk, kom interaktiv og serviceorientering inn i ligningen. Det ble litt vanskelig. Ytelse kan være endimensjonal. Hvis du bare tenker på et program som kjører en bestemt kodebane gjentatte ganger, føles det som en endimensjonal ting rimelig, på rettidig måte. Så snart du begynner å snakke om servicenivå, snakker du faktisk om flere ting som konkurrerer om datamaskinressursen. Det blir flerdimensjonalt veldig raskt. Hvis du begynner å snakke om forretningsprosesser, kan forretningsprosesser trådes sammen fra flere applikasjoner. Hvis du snakker om serviceorientert arkitektur, kan en gitt applikasjon faktisk få tilgang til mulighetene til flere applikasjoner. Da blir det en veldig komplisert ting.
Jeg så på - for lenge siden tegnet jeg dette diagrammet. Dette diagrammet er minst 20 år gammelt. I utgangspunktet kaller jeg det Diagrammet for alt fordi det er en måte å se på alt som finnes i IT-miljøet. Det er egentlig bare fire stykker: brukere, data, programvare og maskinvare. Selvfølgelig endrer de seg over tid, men du skjønner faktisk når du ser på dette at det er en hierarkisk eksplosjon av hver av disse brikkene. En maskinvare ja, en maskinvare kan være en server, men en server består av muligens flere CPUer, nettverksteknologi og minne, og dette, slags forferdelig mange kontrollører, som det skjer. Hvis du faktisk ser på dette, brytes det hele i stykker. Hvis du faktisk tenker å prøve å orkestrere alt dette, med hensyn til data som endres, programvarens ytelse endres, fordi maskinvaren endres og så videre og så videre, ser du faktisk på en utrolig vanskelig flersvarig situasjon. Dette er kompleksitetskurven. Selvfølgelig er det kompleksitetskurve for omtrent alt, men jeg har sett den tegnet gang på gang når jeg snakker om datamaskiner. I utgangspunktet, hvis du setter noder på den ene aksen og de viktige forbindelsene på den andre aksen, ender du opp med en kompleksitetskurve. Det spiller nesten ingen rolle hva nodene og tilkoblingene er, og det vil gjøre hvis du ønsker en representasjon av volumveksten i telefonnettet.
Når du snakker om noder i datamiljøet, snakker du faktisk om individuelle ting som bryr seg om hverandre. Kompleksitet viser det seg å være et spørsmål om forskjellige strukturer og de forskjellige begrensningene du prøver å overholde. Også tallene. Når tallene går opp, blir de gale. Jeg hadde en interessant prat i går, jeg snakket med noen - jeg kan ikke nevne hvem han var, men det betyr ikke noe - de snakket om et nettsted som hadde 40 000 - det er fire-null, 40 000 - forekomster av databaser på siden. Bare tenk på det - 40 000 forskjellige databaser. Selvfølgelig var det eneste vi hadde - de hadde tydeligvis mange, mange tusen applikasjoner. Vi snakker om en veldig stor organisasjon, men jeg kan ikke nevne den. Du ser faktisk på det, og du prøver faktisk på en eller annen måte å få servicenivåer som kommer til å være tilstrekkelig over hele linjen for flere brukere, med flere forskjellige, hvis du vil, forventninger. Det er en sammensatt situasjon, og at alt jeg virkelig sier er at disse tingene er komplekse. Tallene øker alltid. Begrensningene bestemmes av forretningsprosesser og forretningsmål. Du vil ha lagt merke til forventningene endres.
Jeg husker så snart Gmail, Yahoo-post og Hotmail, alle disse postsystemene kom opp, begynte folk å forvente at deres interne postsystemer i organisasjonen ville tjene servicenivået til disse enorme operasjonene med enorme serverfarmer utenfor organisasjonen og begynte å bli presset for å få alle den slags ting til å skje. Faktisk er avtaler på tjenestenivå en ting, men forventning er en annen ting, og de kjemper mot hverandre i en organisasjon, en vanskelig ting. Her er bare et forretningsperspektiv. I noen systemer er den optimale responstiden en tidel av et sekund av menneskelig responstid. En tiendedels sekund er tiden det tar en kobra å bite deg. Hvis du står foran en kobra, og den bestemmer seg for å bite deg, er det for sent, det kommer til at du ikke kan svare på en tidels sekund. En tiendedels sekund handler om tiden det tar for ballen å forlate hånden på muggen for å nå fyren med balltre. I utgangspunktet, når han ser ballen kastet, må han svare på akkurat det tidspunktet. Menneskelig respons, slags interessant ting. Programvare til programvare kan åpenbart ha en høyere forventning.
Så kommer du inn i noen situasjoner som jeg tror er de markedssituasjonene, der det å være først er der forretningsverdien er. Dette er som om du vil selge en bestemt aksje i aksjemarkedet sannsynligvis er mindre, for eksempel fordi du tror at den går ned og mange andre tror at den går ned, får du den beste prisen hvis du først kommer på markedet. Det er mange situasjoner, annonsevisning og slike ting, veldig lik situasjon. Du har denne bevegelsen når det gjelder forventning på tjenestenivå. Du har en ting som er et slags glasstak for menneskelig respons. Når det er programvare til programvare, hvis du har denne taksituasjonen, er det ingen beste servicenivå. Raskere enn alle andre er best.
OK, dette er, tror jeg, det siste lysbildet som jeg gjorde, men dette er bare for å gi deg et stort bilde av kompleksiteten, når du faktisk ser på organisasjonens krav, tjenesten. Du har, når du går opp på venstre side her, har du systemadministrasjon, som er et sett med programvare som tjener til servicestyring, som prøver å administrere et servicenivå. Over det har du fått forretningsprestasjonsstyring. Hvis du ser nedover bunnen her, området for automatisering av tjenester, har du fragmenterte tjenester som utvikler seg til standardiserte tjenester, hvis du faktisk vil investere i denne typen ting, som utvikler seg til integrerte tjenester, som utvikler seg til optimaliserte tjenester . Det meste hva folk har gjort er bare i nedre venstre hjørne av dette. Kanskje litt serviceledelse. Forvaltningsstyring, veldig sjelden. Fragmentert, nesten det hele. En perfekt verden ville fylt det rutenettet. Instrumentering - Jeg nevnte et underoptimaliseringsproblem. Du kan optimalisere deler av et system, og det er ikke bra for hele systemet. Hvis du gjør hjertet optimalt, kan blodet ditt sirkulere for fort for resten av organene dine. Det er et problem med store organisasjoner og servicenivåer. Det er klart ingenting kommer til å oppnås uten sofistikerte verktøy fordi variablene nettopp har fått - det er vel for mange variabler til å prøve og optimalisere.
Når det er sagt, vil jeg gi videre til Dez som vil snakke om noe annet helt, forhåpentligvis.
Dez Blanchfield: Takk, Robin. I likhet med Dr. Robin Bloor har jeg brukt altfor mange år på å tenke på ytelsen til veldig komplekse systemer i veldig stor skala. Sannsynligvis ikke helt den samme skalaen som Robin, men ytelse er et daglig tema og det er en del av vårt DNA å ønske ytelse, for å få det beste ut av alt. Faktisk har jeg brukt en grafikk av en av mine favoritt ting i verden, Formel I bilkjøring, der hele planeten sitter stille en stund og ser på biler gå rundt i sirkler veldig raskt. Hvert eneste aspekt, det er ingen aspekt ved formel I som ikke spesifikt handler om å oppnå ytelse. Mange mennesker poo-poo sporten fordi de tror det er bortkastet penger. Det viser seg at bilen vi kjører hver eneste dag for å slippe barna på fotball i helgene og på skolen de andre dagene, er avledet fra prestasjonsbasert utvikling og forskning. Det er på en måte livet i Bil-racing. Hverdags teknologi, hverdagsvitenskap, kommer ofte av slike som har vært fokusert utelukkende på høy ytelse.
Realiteten er imidlertid at vår nye "alltid på" verden, som krever 100 prosent oppetid - som Robin nevnte tidligere - med ting som innføring av webmail og andre tjenester vi tar for gitt på kontinuerlig rom, og vi forventer nå at vårt foretak og arbeidsmiljø. Realiteten er at å være oppe ikke alltid betyr at du oppfyller avtalen din på servicenivå. Jeg har tatt dette behovet for å administrere applikasjonsytelse og avtaler på servicenivåavtaler har gjennomgått et grunnleggende skifte det siste tiåret. Vi prøver ikke bare å bekymre deg for ytelsen til ett system lenger. Når verden var litt enklere, kan vi ha en situasjon der en enkelt server som kjører flere tjenester kan overvåkes live, og det var relativt greit å støtte. Vi kunne - og her er det lille, tingene vi pleide å bekymre oss for da jeg for eksempel var en systemadministrator for mange år siden - ville vi se oss om, er tjenesten typisk oppe og svarer? Kan jeg logge inn på en terminal for eksempel? Svarer operativsystemet, og kan jeg skrive inn kommandoer? Er applikasjonene i gang? Kan jeg se prosesser og minne ved å gjøre ting og I / O på tvers av nettverket og så videre? I mainframe-dagene kunne du høre bånd gå glidelås-zip og papir falle ut av dem.
Svarer appene, og kan vi logge på og gjøre ting på dem? Er brukerne i stand til å koble seg til noen av disse serverne? Det fortsetter. De er ganske grunnleggende, vet du. Så noen få morsomme - er helpdesken grønn? For hvis ikke, så går alt bra, og hvem kommer til å skaffe smultringene? Livet var veldig enkelt i disse dager. Selv i disse dager, og da jeg snakker med for 20–30 år siden, var kompleksiteten fremdeles veldig høy. Vi kunne på en relativt enkel måte administrere avtaler på servicenivå og følge med på ytelsen. Vi kan ikke gjøre det for hånd lenger, som Robin antydet. Utfordringen er for stor. Fakta er tiden da noen få gode apper, administratorer, systemnettverk og database, administratorer kan overvåke og møte SLA-er for ytelse. SLA-er er så langt borte nå at jeg slet i går da jeg la de siste notatene mine sammen for å tenke på året da jeg sist klarte å se på et system med en veldig kompleks stabel, og gi mening om det og til og med forstå hva som var skjer under panseret, og jeg kommer fra en dypt teknisk bakgrunn. Jeg kan ikke forestille meg hvordan det er å møte det på en daglig basis nå på en administrativ måte.
Hva skjedde? Vel, i 1996 ble databasedrevne apper transformert med internettbommen. Mange av oss har vært igjennom det. Selv om du ikke var rundt internettbommen, kan du enkelt bare se deg rundt og innse at i hverdagen, at vi kobler alt til internett nå. Jeg tror vi har en brødrister som tilsynelatende kommer med muligheten til å komme på Wi-Fi som er latterlig, fordi jeg ikke trenger brødristeren min koblet til internett. På 2000-tallet, spesielt på begynnelsen av 2000-tallet, måtte vi takle denne enorme veksten i kompleksitetsrunden som leverte serviceytelser i dot-com boom. Så en annen latterlig klosset gnist i web 2.0, der smarttelefoner kom til og nå var applikasjoner i våre hender 24/7 og var alltid på-modus.
Det er 2016 nå, vi står overfor en annen quagmire i form av sky og big data og mobilitet. Dette er systemer som er så store at de ofte er vanskelige å forstå og sette på engelsk. Når vi tenker på det faktum at noen av de store enhjørningene som vi snakker om har titusenvis av petabytes med data. Dette er hele gulvet med diskplass og lagring bare for å holde e-post, bilder og sosiale medier. Eller i noen tilfeller, innen transport og fraktlogistikk, er alt i bank, det er der pengene dine er, eller hvor posten din er, eller din, der det du kjøpte på eBay. Den neste store bølgen vi skal møte er denne veldig tunge utfordringen med tingenes internett.
Hvis dette ikke var ille nok, er vi i ferd med å bygge kunstig intelligens og kognitiv databehandling til omtrent alt. Vi snakker med Siri og Google-motorer i disse dager. Jeg vet at Amazon har en av sine egne. Baidu har en av disse enhetene der du kan snakke med, de konverterer den til tekst som går inn i et normalt system, databasen lager et spørsmål og kommer tilbake og reverserer prosessen. Tenk på kompleksiteten som går inn i det. Realiteten er at kompleksiteten i dagens standard applikasjonsstabel er langt utenfor menneskelige evner. Når du tenker på alt som skjer når du trykker på en knapp på smarttelefonenheten eller nettbrettet, snakker du til det, konverterer det til tekst, kjører det hele veien til internett til et back-end-system, en front-end mottar som konverterer den til en spørring, kjører spørringen gjennom en applikasjonsstabel, går gjennom en database, treffer plate, kommer ut igjen, og i midten er det et transportnettverk, det er et lokalt nettverksstatussenter. Kompleksiteten er gal.
Vi hevder effektivt dette som hyperscale. Kompleksiteten og hastigheten på hyperscale er bare øyevann. Bruksområder og databaser er blitt så store og så komplekse at administrering av ytelse faktisk er en vitenskap i seg selv. Mange omtaler det som en rakettvitenskap. Vi har teknologi på stedet, vi har offsite-teknologi, vi har en rekke alternativer for datasenter; fysisk og virtuell. Vi har fysiske og virtuelle servere, vi har sky, vi har infrastruktur som en tjeneste og plattform som en tjeneste og programvare ettersom en tjeneste nå er en ting vi tar for gitt. Det siste, programvare som en tjeneste, ble skremmende for en stund for noen år siden da økonomidirektører og deler av organisasjonen innså at de kunne hente kredittkortet sitt og bare kjøpe ting selv og gå rundt CIO, og vi kalte denne “skyggen” IT ”og administrasjonssjefene prøver nå å vri denne ryggen og bryte kontrollen over.
I infrastruktur har vi programvaredefinert nettverk, virtualiseringsnettverk av nettverk, under det vi har, antagelig over, nå har vi fått mikrotjenester og apper for aktive tjenester. Når du klikker på en URL, er det en haug med forretningslogikk som ligger på slutten av nettadressen som beskriver hva den trenger for å faktisk levere den. Det har ikke nødvendigvis forhåndsbygd logikk som venter på den. Vi har tradisjonelle databaser på den ene siden som skalerer veldig, veldig store. Vi har slike som Hadoop-infrastruktur og økosystemer i det andre spekteret som er så store at som sagt, du vet, folk snakker om hundrevis av petabyte med data nå. Vi har kompleksitet mobilitet så langt som enheter som bærer rundt, bærbare datamaskiner og telefoner og nettbrett.
Vi har fått BYOD i noen lukkede miljøer og stadig mer, siden de erfarne Gen Y-ene har med seg egne enheter. Vi la dem bare snakke med dem om nettgrensesnitt. Enten over internett eller via Wi-Fi, har vi gratis Wi-Fi i kafeen nede mens de tar kaffe. Eller vår interne Wi-Fi. Maskin-til-maskin er alltid til stede nå. Det er ikke direkte en del av tingenes internett, men det er også relatert. Tingenes internett er et helt nytt spill med en kompleksitet som er ufattelig. Kunstig intelligens, og hvis du tror at det vi leker med nå, med alle Siri og andre relaterte enheter vi snakker med, er komplisert, vent til du kommer til en situasjon der du ser noe som heter Olli som er en 3D trykt buss som tar omtrent seks personer og kan kjøre seg selv rundt i byen, og du kan snakke vanlig engelsk til den, og den vil snakke tilbake til deg. Hvis den rammer trafikk, vil den bestemme seg for å ta til venstre eller høyre av hovedområdet der det er trafikk. Når det svinger og du blir bekymret for hvorfor den svinger til venstre eller høyre av hovedveien, vil den si til deg: "Ikke bekymre deg, jeg skal til venstre. Det er trafikk fremover, og jeg kommer til å gå rundt det. ”
Å administrere ytelsen til alle systemene der inne og alle kompleksitetene, spore hvor disse dataene går, om de går inn i databasen, alle sammenkoblinger og alle relevante biter, er bare tankene å svi. Realiteten er at å styre ytelse og SLAer med dagens hastighet og skala krever verktøy og systemer, og som standard er dette ikke lenger noe der du bare skulle tro at det ville være fint å ha et verktøy - det er en forutsetning; det er bare helt nødvendig. Her er noe som et lite eksempel, en liste over applikasjonsdesigndiagrammer på høyt nivå for OpenStack, åpen kildekode-definert sky. Dette er bare en stor del. Dette er ikke bare servere og database. Det er her hver lille blå klatt representerer klynger av ting. I noen tilfeller filer og servere eller hundrevis av databaser eller selvfølgelig ikke mer enn titusenvis av små biter av applikasjonslogikk. Det er en liten versjon. Det er virkelig helt ubehagelig når du begynner å tenke på kompleksiteten som kommer i dette. I dag, til og med på bare stor dataplass, vil jeg bare sette noen skjermbilder av bare merkevarene. Når du tenker på alle brikkene vi har å styre her, snakker vi ikke bare om ett merke nødvendigvis, dette er alle merker i big data-landskapet og toppmerket, ikke bare hver eneste lille eller åpen kildekode. Du ser og du synes det er ganske sjovt diagram.
La oss bare se på et par vertikaler. La oss ta markedsføring, for eksempel. Her er et lignende diagram, men fra teknologibunker som er tilgjengelige i markedsføringsteknologi alene. Dette er grafen for 2011. Her er 2016-versjonen. Bare tenk på, dette er bare antall merker av produkter du kan kjøre for teknologi med hensyn til markedsføringsteknologi. Ikke kompleksiteten i systemene der inne, ikke den forskjellige appen og nettet og utviklingen og nettverket og alt det andre. Bare merkevaren. Det er før, for fem år siden, og her er i dag. Det vil bare bli verre. Vi er på dette punktet der virkeligheten er, mennesker kan ganske enkelt ikke sikre alle avtaler på tjenestenivå. Vi kan ikke dykke i detaljer, raskt nok og i den skalaen vi trenger. Her er et eksempel på hvordan en overvåkningskonsoll ser ut nå. Dette er som nesten tjue odde skjermer limt sammen og later som om de er en flott, stor projisert skjermovervåkning hver eneste lille brikke. Nå er det interessant her inne, jeg vil ikke nevne merkevaren, men denne overvåkningsplattformen overvåker en enkelt applikasjon i et logistikk- og forsendelsesmiljø. Bare en app. Hvis du tenker på hva Robin snakket om hvor organisasjoner kan ha 40 000 databaser nå i produksjonsmiljøer. Kan du bare visualisere hvordan 40 000 versjoner av denne samlingen av skjermer som overvåker ett program kan være? Det er en veldig modig verden vi lever i. Som Robin sa, og jeg vil absolutt, 100 prosent gjenspeile at uten de rette verktøyene, uten den rette støtten og folk på bordet som bruker disse verktøyene, er applikasjonsytelse et tapt spill for menneskene og det må gjøres av verktøy og programvare.
Med det vil jeg overføre til vennene våre i IDERA.
Eric Kavanagh: OK, Bill.
Bill Ellis: Takk skal du ha. Deler skjermen min her. Jeg antar at noen kan bekrefte at du kan se skjermen min?
Dr. Robin Bloor: Ja.
Eric Kavanagh: Det ser bra ut.
Bill Ellis: Takk skal du ha. Den ene tingen han refererte til var at jeg virkelig ikke kan vente på var den selvkjørende bilen. Den ene tingen som jeg ikke hadde hørt noen snakke om er, hva skjer når det snør? Jeg lurer litt på om ingeniørene i California skjønte at det i andre deler av landet snør ganske mye.
Dez Blanchfield: Jeg liker det, jeg kommer til å huske den.
Eric Kavanagh: En typisk kilometer i timen.
Bill Ellis: Vi er her for å snakke om applikasjonsprestasjonsstyring i et sammensatt miljø. En ting jeg liker å snakke om er mange mennesker, når de snakker om ytelse, er reaksjonens art, hei flere servere, mer CPU, mer minne, etc. Den andre siden av den mynten behandler effektiviteten. Det er to sider av den samme mynten, og vi kommer til å se på begge. Det endelige målet er å oppfylle serviceavtalene for forretningstransaksjonene. Til slutt eksisterer all denne teknologien for virksomheten. Vi snakket om å ha en bransjens første resultatstyringsdatabase. Idealet med det er å passe inn i den ideelle formen for ytelse og administrere den fra begynnelsen av applikasjonens livssyklus.
Temaene koker virkelig ned til fire stykker; det ene er prosessen med å administrere ytelse. Vi snakket med alle, og alle har verktøy. Hvis de ikke har verktøy, har de skript eller kommandoer, men det de mangler er kontekst. Kontekst er ganske enkelt å koble punktene på tvers av applikasjonsstablene. Disse applikasjonene for - er nettleserbasert. De er veldig tett koblet fra nivå til nivå. Hvordan lagene samvirker er også viktig. Deretter snakker vi om forretningstransaksjonen. Vi skal gi synligheten ikke bare for de tekniske menneskene, men også for applikasjonseierne og driftslederne.
Jeg har et par casestudier for bare å dele med deg hvordan kundene har brukt disse til å bruke. Dette er en veldig praktisk del av presentasjonen her. La oss se på hva som vanligvis skjer. Jeg liker å diagramme - det var akkurat som en utrolig collage av teknologier. Antallet teknologier i datasenteret har akkurat vokst, og vokst, og vokst. I mellomtiden bryr ikke en sluttbruker seg om det, og er glemme det. De vil bare utøve transaksjonen, ha den tilgjengelig, ha den fullført raskt. Det som vanligvis skjer er at fagfolkene i IT ikke er klar over at sluttbrukerne til og med hadde et problem, helt til de selv rapporterer. Det sparker i gang en tidkrevende, treg prosess og ofte frustrerende. Det som skjer er at folk vil åpne verktøyene sine, og de ser på en undergruppe av applikasjonsbunken. Med den delmengden blir det veldig vanskelig å svare på det enkleste spørsmålet. Er det vanlig at du har problemet? Hvilken transaksjon er det? Hvor i applikasjonsbunken ligger flaskehalsen? Ved å bruke hele denne tiden, se nivå etter nivå, ikke være i stand til å svare på disse spørsmålene, ender du opp med å bruke mye tid og energi, mye personell, midler og energi på å finne ut av det.
For å løse dette, for å gi en bedre måte, er det Precise faktisk gjør å ta sluttbrukerens sportransaksjon, fange metadata om det, følge transaksjonen gjennom nettverket, inn på webserveren, inn i forretningslogikknivået og vi støtter .NET og ABAP og PeopleCode og E-Business Suite, i multitier-applikasjoner som til slutt alle transaksjonene kommer til å samhandle med journalsystemet. Enten det er en inventaroppslag, rapportert arbeidstid, samhandler de alltid med databasen. Databasen blir grunnlaget for forretningsresultater. Databasen er på sin side avhengig av lagring. Hva metadataene om transaksjonene svarer på, hvem, hvilken transaksjon, hvor i applikasjonsbunken, og så har vi dyp kodenivåsynlighet for å vise deg hva som utføres. Denne informasjonen blir fanget kontinuerlig, lagt inn i resultatstyringsdatabasen - som blir et enkelt ark for alle å se hva som skjer. Det er forskjellige mennesker og organisasjoner som bryr seg om hva som skjer: tekniske eksperter, applikasjonseiere, til syvende og sist virksomheten. Når et problem dukker opp, vil du kunne trekke ut informasjon om den transaksjonen.
Før vi får se på investeringstransaksjonen, vil jeg vise deg hvordan det kan se ut for forskjellige personer i organisasjonen. På en administrasjonsnivå kan det være lurt å ha oversikt over flere applikasjoner. Det kan være lurt å vite om helsen som er beregnet av SLA-samsvar og tilgjengelighet. At helsen ikke betyr at alt er 100 prosent som fungerer perfekt. Det er rom i dette tilfellet du kan se at investeringstransaksjonen er i advarselsstatus. Nå, litt dypere, kanskje i bransjen, vil du ha noen ytterligere detaljer om individuelle transaksjoner, når de bryter SLAer, transaksjonsteller, etc. Operasjonsteamet vil ønske å bli varslet om dette gjennom et varsel fra noen sortere. Vi har innebygde ytelsesvarsler. Vi måler faktisk ytelsen i sluttbrukerens nettleser. Enten det er Internet Explorer, Chrome, Firefox osv., Vi er i stand til å oppdage, dette svarer på det første spørsmålet: har en sluttbruker et problem?
La oss dykke inn og se hva annet vi kan vise om det. Menneskene som er interessert i forestilling vil åpne opp Precise. De vil vurdere transaksjonene. De vil se på SLA-kolonnen for å identifisere transaksjoner som ikke var SLA-kompatible. De vil kunne se sluttbrukere som ble påvirket, så vel som hva den transaksjonen gjorde da den strømmet over applikasjonen. Slik du dechiffrerer disse hieroglyfene er, dette er nettleseren, URLen, U er for URL, det er inngangspunktet til JVM. Nå gjør denne spesielle JVM en webserver til den andre JVM som deretter kjører SQL-setningen. Dette er helt klart et databaseproblem fordi denne SQL-uttalelsen var ansvarlig for 72 prosent av responstiden. Vi er fokusert på tid. Tid er ytelsenes valuta. Det er slik sluttbrukere opplever om ting går sakte eller ikke, og det er et mål på ressursforbruk. Det er veldig nyttig; det er en slags beregning som er viktigst for å evaluere ytelsen. Når dette problemet blir overlevert til DBA, er det ikke bare et databaseproblem, det er denne SQL-setningen. Dette er konteksten jeg snakket om.
Nå bevæpnet med denne informasjonen kan jeg gå inn og analysere hva som har skjedd. Jeg kan se først og fremst, y-aksen er tid over hele dagen. Unnskyld meg, y-aksen er responstid, x-aksen er tid over dagen. Jeg kan se at det er et databaseproblem, det er to forekomster, gå tilbake til den flyten, plukk opp den SQL-setningen og gå inn i ekspertvisningen, der Precise kan vise deg hva som skjer, kontrollene, hvor lang tid den koden tar henrette. I databasen er det utførelsesplanen. Du vil merke deg at Precise valgte ut den virkelige utførelsesplanen som ble brukt på utførelsestidspunktet, som er skilt fra den estimerte planen, som ville være når planen ble gitt og ikke i løpet av utførelsestiden. Det gjenspeiler kanskje eller ikke at databasen faktisk gjorde det.
Nå her nede er en svartid analyse for SQL-setningen. Nitti prosent av tiden brukt på lagring; ti prosent ble brukt i CPU. Jeg kan se teksten til SQL-setningen så vel som funnrapporten. Teksten til SQL-setningen begynner faktisk å avsløre noen kodingsproblemer. Det er valgt stjerne; som returnerer alle radene - unnskyld meg, alle kolonnene fra radene som ble returnert. Vi slår tilbake flere kolonner som applikasjonen kanskje ikke trenger. Disse kolonnene bruker plass og ressurser å behandle. Hvis du kjører SAP, er en av de store endringene, fordi HANA-databasen er søyle, det som i utgangspunktet omskriver SAP for ikke å velge utvalgt stjerne, slik at de kan redusere ressursforbruket betraktelig. Dette er i utgangspunktet noe som skjer mye tid også i hjemmearbeidede applikasjoner, enten Java, .NET, etc.
Den skjermen, dette viser deg hvem, hva, når, hvor og hvorfor. Hvorfor kommer til, som SQL-setningen og utførelsesplanen som lar deg løse problemer. Fordi Precise kjøres kontinuerlig, kan du faktisk måle før og etter, på SQL-uttalelsesnivå, på transaksjonsnivå, så enten kan du måle for deg selv, så vel som gjennom applikasjonseiere og for ledelse, at du har løst problemet . Den dokumentasjonen er veldig nyttig. Det er mye kompleksitet i denne applikasjonsbunken. Av mange applikasjoner, faktisk, alle vi har snakket med, kjører minst en del av applikasjonsbunken under VMware. I dette tilfellet ser de på kundeserviceapplikasjonen, de ser på transaksjonstid og korrelerer det med nedgangen er en virtualiseringshendelse. Presise sporer alle virtualiseringshendelsene. Vi har en plug-in til vCenter for å hente det.
Vi er også i stand til å oppdage strid. Stridighet er annerledes enn utnyttelse. Viser faktisk når det er mulig at en støyende nabo påvirker din gjeste-VM, i sammenheng med kundeserverens applikasjon. Nå er jeg i stand til å bore inn og få informasjon, og jeg kan faktisk se de to VM-ene som i dette tilfellet kjemper om CPU-ressurser. Dette gjør at jeg kan ha synlighet slik at jeg kan se på planlegging. Jeg kan sette en gjest VM på en annen fysisk server. Alle disse typene ting du kanskje svarer på, og i tillegg til det, kan jeg faktisk se på kodeeffektiviteten for å få den til å bruke mindre CPU. Jeg tror jeg har et ganske godt eksempel i denne presentasjonen av hvordan noen klarte å redusere CPU-forbruket etter størrelsesordrer.
Det var VMware. La oss gå inn i selve koden, programkoden. Precise vil kunne vise deg hva som skjer innen Java, .NET, ABAP-koden, E-Business, PeopleCode, etc. Dette er inngangspunktene til, i dette tilfellet, til WebLogic. Her nede er det en funnrapport som forteller meg at det er disse EJB-ene du trenger å se på, og vil fortelle meg at du også har fått låsing på dette systemet. Nok en gang driller du ned i virksomhetslogikknivået, for å vise hva som skjer. I dette tilfellet ser jeg på spesielle tilfeller; Jeg støtter også gruppering. Hvis du har mange JVM-er som kjører, kan du enten se på klyngen som helhet, eller se på flaskehalser i den enkelte JVM.
Når du får låst, kan jeg få unntak. Unntak er litt annerledes enn et ytelsesproblem. Vanligvis kjøres unntak veldig raskt. Fordi det er en logisk feil, og når du har truffet den logiske feilen, slutter den. Vi var i stand til å fange opp en stakkspor på grunn av et unntak, dette kan spare mye tid når det går gjennom å prøve å finne ut hva som skjer, du bare har stakkesporet akkurat der. Vi kan også fange minnelekkasjer også. Løsningen inkluderer også database-tier, jeg kan gå inn, jeg kan evaluere database-forekomsten. Nok en gang er y-aksen hvor tiden ble brukt, x-aksen er tid over dagen. Det er en funnrapport som bare automatisk forteller meg hva som skjer i systemet og hva jeg kan se på.
En av tingene med Precises funnrapport, det ser ikke bare på logger eller ventetilstand - det ser på alle utførelsestilstander inkludert CPU, samt returnering av informasjon fra lagring. Lagring er en veldig viktig del av applikasjonsbunken, spesielt med bruk av solid tilstand. Det kan være veldig nyttig å ha informasjon langs disse linjene. For visse lagringsenheter kan vi faktisk bore ned og vise hva som skjer på det individuelle enhetsnivået. Den typen informasjon - nok en gang, det er dyp synlighet; det er bredt i omfanget - for å gi deg akkurat nok informasjon til å ha mer innflytelse å trekke som en applikasjonsytelsesprofesjonell, slik at du kan optimalisere applikasjonene dine fra en ende til ende-basis for å oppfylle de forretningstransaksjonene.
Jeg har et par casestudier jeg ønsket å dele med deg. Vi cruise ganske raskt; Jeg håper jeg går i et greit tempo. Når vi snakker om lagring, bytter alle over tid maskinvare. Det er en maskinvaregaranti. Leverte den virkelig det selgeren fortalte deg? Du kan evaluere det med presis. Du kommer inn, og hva som skjedde her, de la i utgangspunktet inn en ny lagringsenhet, men da lagringsadministratorene bare så på lagringsenhetsnivået, så de mye strid, og de trodde det kunne være et problem med denne nye lagringsenheten. . Ser på mer fra et ende til ende perspektiv, nettopp for å vise hvor det faktisk ville skje. De gikk faktisk fra en gjennomstrømning på rundt 400 meg per sekund, hvor lagringen var ansvarlig for 38 prosent av responstiden, så den er ganske høy. Med den nye lagringsenheten slo vi faktisk opp gjennomstrømningen til seks, syv hundre megs per sekund, så i utgangspunktet dobbelt, og vi klarer å redusere bidraget fra lagringsnivået til transaksjonstiden til halvparten. Jeg kan faktisk tegne det ut før, dette er cutover-perioden, og deretter etterpå.
Så nok en gang, dokumentasjon for å bevise at maskinvareinvesteringen var verdt det, og at de leverte som den bestemte leverandøren hadde forventet. Det er alt, på grunn av kompleksiteten, antall ting, det er alle slags ting som kan skje. I dette tilfellet hadde de faktisk en situasjon der alle hadde skylden på DBA, DBA var som "Vel, ikke så raskt." Her ser vi faktisk på en SAP-applikasjon, jeg synes denne typen scener er ganske vanlig . Det som skjedde var at de utviklet en tilpasset transaksjon for en bruker. Brukeren er som, "Dette går så tregt." ABAP-koderen - det er programmeringsspråket i SAP - sa: "Dette er et databaseproblem." De endte opp med å åpne opp Precise; de målte sluttbrukeren 60 sekunder, så godt over ett minutt. Femti-tre sekunder ble brukt på bakenden. De boret i bakenden og de var faktisk i stand til å avsløre SQL-setningen presentert i synkende rekkefølge.
Denne øverste SQL-setningen som er ansvarlig for 25 prosent av ressursforbruket, og den gjennomsnittlige utførelsestiden er to millisekunder. Du kan ikke skylde på databasen. Hei, ikke så fort, fyr. Spørsmålet er, hvorfor er det så mange henrettelser? Vel, de sprang den tilbake til ABAP, han gikk inn, kikket inn i hekkens hekk, fant ut at de ropte databasen på feil sted, de gjorde i utgangspunktet endringen, testet endringen og nå er den nye responstiden fem sekunder. Litt sakte, men de kunne leve med det. Langt bedre enn 60 sekunder. Noen ganger, bare å frese ut, er det applikasjonskoden, er det databasen, er det lagring? Det er områdene der Precise, ved å ha sammenhengen til ende-til-ende-transaksjoner, er det der Precise kommer inn i bildet. Du avslutter i utgangspunktet de tingene.
Jeg ser på tiden, ser ut til at vi fortsatt har litt tid til å gå gjennom et par til av disse. Jeg strømmer gjennom disse. Denne applikasjonen var under utvikling i over ett år. Da de gikk inn på QA, så de at webserverne ble maksimert ut 100 prosent, og det så ut som om applikasjonen ikke kunne kjøres under VMware. Det første alle sa, var: “Legg på dette fysisk; den kan ikke kjøres under VMware. ”Precise tilbød dem faktisk flere måter å løse problemet på. Vi så på transaksjonene, vi så en webserver samtale, den kommer inn som en ASMX i IIS.NET. Den avslørte faktisk den underliggende koden. Ser du dette der jeg peker? Dette er 23 dager, 11 timer. Hvordan er det mulig? Vel, hver påkallelse tar 9, 4 sekunder, og denne tingen påberopes 215 000 ganger. For hver innkalling bruker den 6 sekunder CPU. Dette er grunnen, denne koden er grunnen til at denne tingen aldri kunne skalere. Faktisk kunne det ikke skaleres i fysisk.
Det de gjorde, er at de gikk tilbake til utviklerne sine, og de sa: "Kan noen gjøre en endring?" De hadde en konkurranse, og de testet ut de forskjellige forslagene, og de kom med et forslag som var i stand til å løpe mye mer effektivt. Den nye fullførte ett poeng, litt under to sekunder, med to hundredeler av et sekund i CPU. Nå kan dette skaleres, og det kan kjøre på VMware-gården. Vi var i stand til å dokumentere det på både kodenivå og transaksjonsnivå. Dette er slags før, og deretter etter. Nå som du kan se her i stabellinjediagrammet som viser web, .NET og database, samhandler du nå med databasen. Dette er en profil du forventer å se for et program som kjørte mer normalt.
OK, jeg velger og velger med tanke på flere ting jeg kan vise deg. Mange mennesker liker dette fordi dette bedazzles mange butikker. Hvis du ikke klarer å møte en SLA-virksomhet, og alle er som, "Hjelp oss." Denne butikken hadde en situasjon der SLA-virksomheten er i bestillinger mottatt innen klokken 15, sendes den den dagen. Er veldig viktig at de får ordrene ut, og lageret har det veldig travelt. Denne salgsordre-skjermen til JD Edwards var iskaldt, og du kan få en veldig god ide om at dette er et akkurat-i-tid detaljhandelsstyringssystem. Tomme hyller er uakseptable i detaljhandelen. Måtte ha varene der for å selge den. Det vi gjorde var at vi dykket i, i dette tilfellet ser vi på SQL-serverdatabasen. Utseendet og følelsen er den samme enten det er SQL, Oracle, DB2 eller Sybase.
Vi identifiserte utvalgene fra PS_PROD og vi er i stand til å fange varigheten, det faktum at de kjører så mye. Den mørkeblå stemte overens med nøkkelen som sa at de ikke venter på noen ventetilstand eller logging eller lagring - denne tingen er bundet av CPU. Vi sporet SQL-setningen innen 34301, så hver gang dette blir utført øker vi tellerne våre for å holde oversikt over det. Det betyr at vi har en detaljert historie og jeg får tilgang til den ved å klikke på den melodiske knappen. Her er fanen Historikk. Dette skjermbildet her viser gjennomsnittlig varighet kontra endringer. Onsdag, torsdag, fredag var gjennomsnittlig varighet omtrent to tidels sekund. Svært få skjermfryser. De kan møte SLA-virksomheten. Kom 27. februar, noe endrer seg, og plutselig er utførelsestiden her oppe, og det er faktisk treg nok til å forårsake timeouts, noe som resulterer i at skjermen fryser. Nøyaktig ved å føre en detaljert historie, inkludert utførelsesplanen og generelle endringer i tabellens indekser hvis den SQL er i bruk. Vi kunne plukke opp at tilgangsplanen endret seg 27. februar. Mandag til og med fredagens dårlige uke. Kom 5. mars endret tilgangsplanen igjen. Dette er en god uke. Denne rosa stjernen forteller oss volumet som er oppdatert.
Her kan du se antall rader i de underliggende tabellene og det er typisk for en virksomhet. Du vil at bordene dine skal vokse. Saken er at utsagnene er parse, SQL-setningene kommer inn, optimisatoren må bestemme hva de skal gjøre og velge når utførelsesplanen er rask, velge en annen utførelsesplan når den er treg, noe som forårsaker at skjermen fryser. På et dypt teknologisk grunnlag, trenger jeg å vite hva utførelsesplanen er, og Precise fanger den for meg komplett med dato og klokkeslett. Dette er den som var rask og effektiv, dette er den som var treg og ineffektiv. Dette filterforbindelsen bruker ganske enkelt mye mer CPU for å forene, for å gjøre akkurat denne SQL-setningen. De har fortsatt den samme endelige effekten, men denne har i utgangspunktet en tregere, mindre effektiv oppskrift for å levere resultatsettet. Så vi går gjennom. Hei, har vi tid til et par til?
Eric Kavanagh: Ja, gå for det.
Bill Ellis: Ok, jeg skal hoppe videre. Én ting jeg vil at du skal notere oss, vi snakket om maskinvare, snakket om SAP, vi snakket om. NET, vi snakket om JD Edwards og Java-SQL Server-miljøet. Dette er SAP, her over ser vi på PeopleSoft. Precises støttematrise er bred og dyp. Hvis du har en applikasjon, mer enn sannsynlig, kan vi instrumentere den for å gi dette nivået av synlighet. En av de største endringene som skjer akkurat nå er mobilitet. PeopleSoft introduserte mobilitet med Fluid UI. Fluid UI bruker et system veldig annerledes. Denne applikasjonen er i utvikling. Fluid UI - hva det gjør fra et styringsperspektiv er at det lar sluttbrukerne bruke telefonen sin, og det øker produktiviteten betraktelig. Hvis du har hundrevis eller tusenvis eller enda flere ansatte, hvis du kan øke produktiviteten deres, 1–2 prosent, kan du ha enorm innvirkning på lønningslisten og alt annet. Det som skjedde var at denne spesielle butikken rullet ut PeopleSoft Fluid UI. Når vi snakker om kompleksitet, er dette PeopleSoft-stabelen. Én applikasjon, minimum seks teknologi, mange sluttbrukere. Hvordan starter du det?
Nok en gang kommer Precise til å kunne følge disse transaksjonene. Det vi viser deg her er en stablet stolpediagram som viser klient, webserver, Java, Tuxedo-database, PeopleSoft-applikasjonsstabel. De grønne kartene til J2EE, som er en slags fancy måte å si WebLogic på. Dette er overgangen. Sluttbrukerne begynner å bruke Fluid UI og responstiden går fra kanskje halvannet, to sekunder, opp til rundt ni, ti sekunder. Hva denne ene skjermen ikke viser, er antall personer som fikk "ikke svar." De fikk faktisk skjermfrysing i applikasjonen. La oss se på noe av synligheten som Precise er i stand til å gi denne kunden.
Først av alt, når jeg ser på PeopleSoft-transaksjonene, kan de i utgangspunktet se, vi så denne typen ting over hele linjen. Alle transaksjonene ble påvirket, samt alle lokasjonene. Forresten, når du ser på dette, kan du faktisk se steder rundt om i verden. Fra Asia Pacific, til Europa så vel som Nord-Amerika. Prestasjonsproblemet var ikke lokalisert til en bestemt transaksjon, eller bestemt geografisk beliggenhet, det er systemet bredt. Det er på en måte å si at endringen eller måten Fluid UI hadde global innvirkning på. Her ser du fra skalerbarhetssynspunkt, folk prøver å utføre den samme typen aktivitet, men responstiden er i utgangspunktet bare degradert og degradert. Du kan se at ting ikke skaleres. Ting går veldig, veldig dårlig. Over her, når jeg ser på aksetallet og samtidige forbindelser, ser du noe som er veldig interessant når det gjelder tilgangstallet og forbindelsene. Her skaler vi bare opp til rundt 5000 og du ser på omtrent, dette topper seg med 100 samtidige forbindelser. Dette gjøres etter; dette er før. Så hva min reelle etterspørsel etter systemet, hvis denne tingen kan skaleres, ligger i 300 000 rekkevidde. I gamle dager, med det klassiske brukergrensesnittet, ser du på 30 samtidige forbindelser.
Det som forteller deg er at Fluid UI bruker minst 10 ganger antall samtidige forbindelser. Vi begynner å trekke tilbake det som skjer under dekslene med PeopleSoft, slik at du kan begynne å se virkningen på webserveren, det faktum at SLA-er begynner å bryte. Ikke tenkt å gå inn på alt, men det som ender opp med å skje er at de i utgangspunktet er avhengige av meldinger. De trener i utgangspunktet er WebLogic og forårsaker kø i Tuxedo. Det var faktisk et flernærere avhengighetsproblem som dukket opp med Fluid UI, men Precise var i stand til å vise at ved en hel haug forskjellige ting, at vi kan fokusere på hva problemet var. Det viser seg at det også var et problem i selve databasen. Det er faktisk en meldingsloggfil, og på grunn av alle samtidige brukere, låste denne loggfilen seg. Den hadde i utgangspunktet ting å stille inn, i hvert eneste lag i applikasjonsbunken. Snakk om kompleksitet, her er faktisk Tuxedo-nivået som viser deg køen, og du kan se ytelsen degraderende i dette laget. Jeg kunne se prosessene; Jeg kunne se domenene og serverne. I Tuxedo, for at folk skal bruke det, er det du gjør for å åpne for flere køer, domener og servere, akkurat som i supermarkedet for å avlaste overbelastningen, for å minimere køtiden. Det siste og siste alternativet, Precise viser mye informasjon.
Som jeg hadde nevnt tidligere, samhandler hver betydelig transaksjon med journalsystemet. Synlighet i databasen er avgjørende. Precise viser hva som skjer i databasen, i WebLogic, i Java, .NET, i nettleseren, men stedet som Precise virkelig utmerker seg er i databasetrekket. Dette skjer for å være svakheten til konkurrentene. La meg vise deg en av måtene Precise kan hjelpe deg å gå gjennom dette. Jeg har ikke tenkt å bruke tid på trekanten med databasealoptimalisering, men vi ser i utgangspunktet på lave kostnader, lav risiko, til store omfang, høyrisiko og høykostnadsendringer. Jeg vil faktisk tweete ut dette lysbildet etterpå hvis folk vil prøve å se på det. Det er en ganske stor guide, tror jeg, for innstilling av problemer. Her er ekspertvisningen Precise for Oracle. Topp på funnrapporten, 60 prosent innvirkning er denne spesielle SQL-setningen. Hvis du åpner opp denne aktivitetsskjermen, viser den den der oppe. Jeg kan se på denne valgte uttalelsen, det er en utførelsesplan. Hver henrettelse tar et sekund - 48.000 henrettelser. Det legger opp til 48.000 flere timer henrettelser.
Den mørkeblå, nok en gang, er CPU. Denne tingen er CPU-bundet, ikke en ventetilstand, ikke en logg. Jeg understreker at fordi noen av våre konkurrenter bare ser på ventetilstander og loggingshendelser, men generelt sett, er CPU den travleste utførelsesstaten og tilbyr mest tilbakekjøp. Å komme inn på dette ekspertbildet - og jeg går veldig raskt - det jeg gjorde var at jeg så på bordet, 100 000 rader, 37 000 blokker. Vi holder på med en full-tabell, men vi har seks indekser på denne tingen. Hva foregår her? Vel, når jeg ser på hvor leddet, hva dette der klausulen gjør er at det faktisk er å konvertere en kolonne til store bokstaver, og den sier hvor den er lik store bokstaver, finn variabel. Det som skjer er at hver gang denne tingen kjøres, må Oracle konvertere denne kolonnen til store bokstaver. I stedet for å gjøre det nesten femti tusen ganger, er det mye mer effektivt å bygge indeksen med store bokstaver i en funksjonsbasert indeks, og den er ikke bare tilgjengelig i Oracle enterprise divisjon, også standard divisjon. Når du gjør det, kan du bekrefte utførelsesplanen som utsteder den nye indeksbrukeren med store bokstaver, det var bare noe av det.
Så, fra en før og etter måling, ser du på ett sekunders utførelsestid, aggregerer opptil 9 timer 54 minutter, med den samme eksakte SQL-setningen, men har den indeksen innebygd stor bokstav for 58 000 henrettelser, svaret tiden synker til under millisekunder, samlet sammen, det kommer opp til syv sekunder. Jeg lagret i utgangspunktet ti timers CPU på serveren min. Dette er enormt. For hvis jeg ikke har krav på en serveroppdatering, kan jeg leve på den serveren. Jeg senker faktisk denne serverbruken med 20 prosent, og du kan faktisk se før og etterpå. Det er den typen synlighet som Precise kan gi. Det er også noen flere ting vi kan se på, hvorfor har du alle disse indeksene hvis de ikke blir brukt? De kan følge opp med det. Det er arkitektur, og jeg vil pakke det opp siden vi når toppen av timen. Jeg er en sann troende på denne løsningen, og vi vil at du skal være en sann troende. Hos IDERA tror vi at en prøveversjon gjør en kunde, så hvis du er interessert, kan vi gjøre evalueringer på nettstedet ditt.
Med det vil jeg passere fyret tilbake.
Eric Kavanagh: Ja, dette har vært en enorm detalj som du viste der. Det er egentlig ganske fascinerende. Jeg tror jeg kanskje har nevnt for deg tidligere - og jeg vet at i noen av de andre webcastene vi har gjort med IDERA, har jeg nevnt det - jeg har faktisk sporet nøyaktig siden det ble kjøpt opp av IDERA, helt tilbake til 2008, tror jeg, eller 2009. Jeg ble fascinert av det den gang. Jeg er nysgjerrig på å vite hvor mye arbeid det går med å holde på toppen av nye utgivelser av applikasjoner. Du nevnte at SAP HANA, som jeg synes var ganske imponerende at du faktisk kan grave deg inn i HANA-arkitekturen og gjøre litt feilsøking der. Hvor mange mennesker har du? Hvor stor innsats er det fra din side og hvor mye av det som kan gjøres noe dynamisk, noe som betyr at når verktøyet blir satt i gang, begynner du å krype rundt og se forskjellige ting? Hvor mye av det kan dynamisk, sorteres og fastslås av verktøyet, slik at du kan hjelpe folk med å feilsøke komplekse miljøer?
Bill Ellis: Du stilte mange spørsmål der.
Eric Kavanagh: Jeg vet, beklager.
Bill Ellis: Jeg ga mye detaljer, for djevelen er i detalj når jeg ser på koden. Du må ha det nivået av detaljer for å virkelig kunne ha noe som er handlingsbart. Uten handlingsverdige beregninger, vet du bare om symptomer. Du løser faktisk ikke problemer. IDERA handler om å løse problemer. Å holde seg oppdatert på nye utgivelser og sånt er en stor utfordring. Spørsmålet om hva som skal til for å gjøre det, det er egentlig for produktstyring. Jeg har ikke mye synlighet i teamet som i utgangspunktet holder oss oppdatert på ting. Når det gjelder HANA, er det faktisk et nytt tillegg til IDERA-produktlinjen; det er veldig spennende. En av tingene med HANA er - la meg snakke om oppgaven et sekund. I oppgaven vil SAP-butikkene gjøre at de replikerer databasen for rapporteringsformål. Da må du få folk til å forene seg med det som faktisk er gjeldende. Du vil ha disse forskjellige databasene, og de vil ikke være synkronisert etter forskjellige nivåer. Det er bare mye tid og krefter, pluss maskinvaren, programvaren og folk for å opprettholde alt det.
Ideen med HANA å ha en svært parallell database i minnet, for i utgangspunktet å unngå behovet for dupliserte databaser. Vi har en database, en kilde til sannhet, den er alltid oppdatert. På den måten unngår du det som trengs for å gjøre all den forsoningen. Viktigheten av ytelsen til HANA-databasen går opp - jeg vil si 10 ganger eller i det minste mer verdifullt enn summen av alle de andre databasene, maskinvaren og ressursene kan kjøpe. Å kunne administrere HANA, nå som den komponenten faktisk er i betatesting akkurat nå, er det noe som kommer til å gå GA snart. Så det er ganske spennende for IDERA og for oss å i utgangspunktet støtte SAP-plattformen. Jeg er ikke sikker på hvilke andre deler av spørsmålet ditt jeg snakket om, men -
Eric Kavanagh: Nei det er alle gode ting der inne. Jeg kastet en hel haug på deg på en gang, så synd på det. Jeg er bare fascinert, egentlig, jeg mener at dette ikke er en veldig enkel applikasjon, ikke sant? Du graver dypt inn i disse verktøyene og forstår hvordan de samhandler med hverandre, og til ditt poeng, må du slags fortelle historien sammen i hodet ditt. Du må kombinere informasjonsbiter for å forstå hva som faktisk skjer og hva som forårsaker problemer, slik at du kan gå inn dit og løse disse problemene.
En deltaker spør, hvor vanskelig er det å implementere Precise? En annen person spurte, hvem er menneskene - tydeligvis DBA-er - men hvem er noen andre roller i organisasjonen som vil bruke dette verktøyet?
Bill Ellis: Precise er litt mer komplisert å distribuere. Du må ha litt kunnskap om applikasjonsmiljøet, med tanke på, du vet, denne applikasjonen kjøres på denne databasen, den trenger eller - mellomtjeneste webservere, etc. Jeg tror gitt kompleksiteten til noen av disse applikasjonene, det er faktisk relativt enkelt. Hvis jeg kan instrumenter webserveren opp til databasen din, kan jeg gjøre det fra en til ende. Du merker at jeg ikke sa noe om instrumentering av en sluttbrukerklient, og det er fordi det vi gjør er at vi faktisk inkluderer dynamisk, slik at du ikke trenger å endre koden din eller noe annet. En JavaScript går inn i søknadsrammen. Uansett hvor brukeren er i verden, når de får tilgang til URLen fra applikasjonen din, og de får ned den siden, kommer den instrumenterte med Precise. Dette gjør det mulig for oss å velge ut bruker-ID, deres IP-adresse, også den første byte-gjengivelsestiden for hver av sidekomponentenes utførelsestid i sluttbrukerleseren.
Når det gjelder transaksjonene, trenger du ikke å kartlegge transaksjonene fordi de er tett koblet. Denne nettadressen blir et inngangspunkt for JVM og påkaller deretter denne meldingen, noe som resulterer i en JVC hentet fra databasen. Vi er i stand til å fange de naturlige tilkoblingspunktene og deretter presentere dem for deg i den transaksjonsskjermen som jeg viste deg hvor vi også beregnet hvor mye tid, eller prosentandelen av tiden som ble brukt i hvert enkelt trinn. Alt dette gjøres automatisk. Generelt sett tildeler vi 90 minutter å gjøre - for å i utgangspunktet installere den presise kjernen og så begynner vi å implementere applikasjonen. Avhengig av kunnskapen om applikasjonen, kan det ta noen ekstra økter for å få hele applikasjonen instrumentert. Mange bruker bare databasekomponenten til Precise. Det er greit. Du kan i utgangspunktet bryte dette, dele det opp i komponentene du føler nettstedet ditt trenger. Vi tror absolutt at sammenhengen med å ha hele applikasjonsbunken instrumentert, slik at du kan se at avhengighet fra nivå til nivå faktisk forsterker verdien av å overvåke et individuelt nivå. Hvis noen ønsker å utforske instrumenteringsprogrammene deres videre, kan du gå til nettstedet vårt. Jeg antar at det er den enkleste måten å be om ytterligere informasjon, og vi vil diskutere den litt videre.
Eric Kavanagh: La meg kaste et eller to raske spørsmål til deg. Jeg tipper at du samler og bygger opp et lager over tid, både for individuelle klienter og som en samlet virksomhet, av interaksjoner mellom forskjellige applikasjoner og forskjellige databaser. Med andre ord, jeg antar at scenariomodellering er det jeg antyder. Er det tilfelle? Opprettholder du faktisk et slags depot av vanlige scenarier slik at du kan komme med forslag til sluttbrukere når visse ting kommer inn i bildet? Som denne versjonen av E-Business Suite, denne versjonen av denne databasen osv. - gjør du mye av det?
Bill Ellis: Vel, den typen informasjon er innebygd i funnrapporten. Funnrapporten sier hva som er ytelsesflaskehalsene, og det er basert på utførelsestiden. En del av funnrapporten er å lære mer, og hva gjør du videre. Informasjonen eller opplevelsen fra kunder og så videre er i utgangspunktet innlemmet i det biblioteket med anbefalinger.
Eric Kavanagh: Ok, det høres bra ut. Vel folkens, fantastisk presentasjon i dag. Bill, jeg elsket hvor mye detalj du hadde der inne. Jeg trodde bare at dette var virkelig fantastisk, skitne, kornete informasjon, som viste hvordan alle disse tingene gjøres. På et bestemt tidspunkt er det nesten som svart magi, men egentlig er det ikke det. Det er veldig spesifikk teknologi dere setter sammen for å forstå veldig, veldig komplekse miljøer og gjøre folk glade fordi ingen liker når applikasjoner går sakte.
Vel folkens, vi arkiverer denne webcasten. Du kan hoppe online til Techopedia eller insideanalysis.com og wow, takk for tiden din, vi henter deg opp neste gang. Ta vare, farvel.
