Av Techopedia Staff, 31. august 2016
Takeaway: Vert Rebecca Jozwiak diskuterer feilsøking og effektivitetsdatabaser med analytikere Eric Kavanagh og Dez Blanchfield samt Bill Ellis fra IDERA.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Rebecca Jozwiak: Mine damer og herrer, hallo, og velkommen til Hot Technologies i 2016. Dagens emne, "Søknad kjører sakte? Tid til å bli nøyaktig." Og vet vi ikke alle for godt hvilke problemer som kan skje når ting kjører sakte? Dette er Rebecca Jozwiak, jeg fyller ut for Eric som er i ferd med å gjøre en ny rolle her, i dag. Ja, dette året er varmt, og du vet, når det gjelder teknologi, som jeg sa, det eneste du virkelig ikke vil ha, er å sakte kjøre noe, hvilken som helst del av systemet ditt. Og bare for å bruke et forbrukereksempel, mener jeg at hvis du har en restaurant, spiller det ingen rolle hvor god maten er, hvis tjenesten er treg, vil du sannsynligvis ikke ende med å gå tilbake. Nå er det enkelt, på en restaurant, å finne ut hvorfor noe går sakte. Kanskje er kjøkkenet lite bemannet, eller det var en funksjonsfeil med noe utstyr, eller kanskje servitørene er litt late, og det er ganske enkelt å identifisere og fikse det.
Men når du tenker på et datasenter, er det en helt annen historie. Det kan være et nettverksproblem, et dårlig spørsmål som klemmer ting, applikasjonsytelse eller en defekt kabel kan til og med føre til noen problemer. Og feilsøking med den typen kompleksitet kan være, vet du, vanskelig i beste fall. Det er slags hva vi skal snakke om i dag. Og vi har som sagt Eric Kavanagh klynget seg inn som analytiker i dag. Vi har fått Dez Blanchfield til datavitenskapsmannen vår, og vi har Bill Ellis fra IDERA, som skal snakke om selskapets løsning som hjelper med applikasjonsprestasjonsstyring. Og med det skal jeg gi ballen videre til Eric. Eric, gulvet er ditt.
Eric Kavanagh: OK, høres bra ut, folkens. Og det var en flott analogi, faktisk, fordi du snakket med vanskeligheter eller letthet som feilsøking kan utføres, og du kommer helt inn på det. Prestasjonsproblemer skyldes alltid et slags problem som er i nettverket. Jeg mener, det kan være så enkelt som for eksempel maskinvare, men bunnlinjen er en hvilken som helst situasjon som krever feilsøking. Det er det jeg skal snakke om i dag. Og la oss gå foran og hoppe på lysbildene her.
Her kommer trøbbel. Feilsøking - det er morsomt for folk som liker det, det er det som er kult. Hvis du finner noen som liker å gjøre feilsøking, kan du holde på den personen, få dem noen verktøy for å få jobben gjort, for virkelig gode ting hvis du kan finne noen som kan komme til bunns i noe og få ting gjort. Men bunnlinjen er at feilsøking er problematisk, og det har alltid vært og alltid vil være det, og hvis du begynner å snakke om feilsøking, er det du virkelig får analysen av årsaken. Hva er årsaken til problemet?
Vel, hvis du bare lene deg tilbake og tenker et øyeblikk på selv mainframe-dagene, var det alle slags problemer som kunne oppstå. Og den gang måtte du ha folk som virkelig visste tingene sine fordi det ikke engang var gode verktøy for å utføre feilsøking, så du måtte virkelig kjenne ledeteksten din, og vi snakker om det om et sekund. Og jeg glemte faktisk å legge inn en av favorittbildene mine, jeg skal se etter det mens vi er på showet i dag, kanskje under presentasjonen av Dez. Men jeg ville vise, for alle som ikke har sett det, et av de morsomste britiske TV-programene noensinne, det heter “IT-folkemengden.” Og når det gjelder feilsøking, var den irske mannen, som er en av to IT-personer i hele selskapet, sier alltid det samme når en samtale begynner, "Har du prøvd å slå den av og på igjen?" Så prøv å slå den av og på igjen. Du vil bli overrasket over hvor ofte den enkle tingen kan løse noen problemer.
De av dere som har gjort feilsøking hjemme, kanskje med foreldrene dine eller vennene dine, sannsynligvis ikke med barna dine fordi de har en tendens til å vite hva de skal gjøre, slå den av og på igjen. Men uansett er feilsøking ikke lett, det kommer aldri til å bli enkelt, men vi skal snakke i dag om noen av tingene du kan gjøre for å gjøre det enklere. Så ledeteksten - ja, jeg er faktisk gammel nok til å huske de første dagene med databehandling da alt du hadde var ledeteksten å gjøre DIR, Enter. Det er det det ville se, katalog med filer og føle seg positiv til at det faktisk ble gjort noen kommando, ikke sant? Des, selvfølgelig, dataforskeren vår, han vet hvordan han bruker ledeteksten. Og hvis du kan bruke ledeteksten, er det gode ting fordi de fleste av oss bare dødelige bruker en slags GUI, et grafisk brukergrensesnitt, men det er alltid noe, det er alltid en viss kobling mellom GUI og kommandolinjen under. Og bare for å gi deg et tilfeldig eksempel, hvis du vil vite hvor mye kode noen av de grunnleggende programmene der ute baker i dokumenter i disse dager, går du inn i den siste versjonen av Microsoft Word, skriver "hallo verden" og gjør deretter "lagre som HTML. ”Og åpne deretter det resulterende dokumentet i en tekstredigerer, og du vil sannsynligvis se sider og sider med tagger. Det kalles kodeoppblåsing, og kodeoppblåsing er ikke veldig bra for feilsøking, bare for å være sløv.
Klient-server fulgte selvfølgelig, og det var gode ting. Og på en måte går vi litt tilbake i den retningen, men tenk bare på kompleksiteten som fulgte med situasjonen, nå hvor er problemet, er det på klienten, er det på serveren, er det nettverket? Hvor er det? Disse nettstedene som bare tenker på virus, og når et virus kan komme inn i et i et nettverk, hva kan skje? Det kan gå hvor som helst. Datainnbrudd er vanvittige i disse dager. De forårsaker ytelsesproblemer. Vi har hatt russiske hackere vi kan identifisere med IP-adressen. Vi er ganske sikre på at de er russiske, eller at de er veldig nærme, eller at de er veldig flinke ukrainere eller polske eller til og med amerikanere som bruker fullmakter. Men vi har hatt hackere kommet inn på vår lille gamle side, Inside Analysis, gjennom tidene og forårsaker alle slags problemer. Ting bare slutter å virke, du kan ikke få ting gjort. Ting som pleide å fungere fungerer ikke. Hvordan vet du? Hvordan vet du hva det er? Akkurat som et annet eksempel her, er et veldig sammensatt miljø, er det veldig vanskelig å komme inn i ugresset og virkelig forstå hvordan ting foregår og fungerer for oss, spesielt hvis du får en hel haug plugin-moduler. Ting kan bli gale ganske raskt. Jeg går litt foran meg selv.
Jeg kastet inn her, vær alltid på vakt mot oppgraderingen. Oppgraderinger skremmer alltid dagslysene ut av meg. Gjerne operativsystemer. Jeg husker dagene da Microsoft faktisk ville foreslått at, ja, du kunne oppgradere operativsystemet ditt fra denne versjonen til den versjonen. Vel, jeg prøvde et par ganger, og det har aldri fungert. Bare husk at jo større, jo mer komplekst et miljø er, desto mer uhåndterlig vil situasjonen bli. Og så er det virtualisering. Tenk på hva VMware gjorde med IT. Det revolusjonerte IT, men det skapte også dette laget med abstraksjoner. Hvis du har fått et lagabstraksjon på det grunnleggende nivået, er det et helt nytt ballspill, det er en helt ny voksball og du må virkelig revurdere hva du gjør, og alle de gamle verktøyene måtte endre seg. Og nå er det selvfølgelig skyen, ikke sant? For kunden er skyen stor, fordi den er veldig enkel, brukergrensesnittet er ganske greit, men selvfølgelig har du ikke veldig mye kontroll over skyen. Men for folkene som er bak kulissene, er det en hel masse ting de trenger å vite og forstå i disse dager. Miljøet har blitt mye, mye mer sammensatt. Og absolutt med netthandel, og du tenker på alle pengene som handles i disse dager. Derfor vil du ikke finne meg til fordel for et kontantløst samfunn snart. Poenget her er at situasjonen blir mer problematisk for dagen.
Og å holde ytelsen optimal vil alltid involvere et element av feilsøking. Jeg bryr meg ikke hva noen forteller deg, det er ikke noe perfekt verktøy, det er ikke en sølvkule, og det vil aldri være fordi - i et annet interessant perspektiv her - vi fortsatt lærer å snakke silisium. Vi lærer fortsatt å forstå hvordan til og med nettverk fungerer på det pussige nivået. Hvis du ser på systemadministrasjonsprogramvare, blir det ganske bra i disse dager. Men likevel ser du på linjer som går opp og ned og ser på representasjoner av virkeligheten, det vil ta en person som vet hva som skjer for å passe sammen ledetrådene du kan stirre på optimale verktøy for å kunne forstå hva som fungerer og hva som ikke er, og det er mye prøving og feiling, bare for å være sløv. Med det skal jeg overlevere det til Dez Blanchfield, og så får vi høre fra Bill Ellis fra IDERA, som kommer til å gjøre oss til skamme med hans kunnskap. Med det, Dez, ta det bort.
Dez Blanchfield: Hei, takk Eric. Takk skal du ha. Ledet fint inn i det lille segmentet mitt. Tittelen min, “Performance Art, ” synes jeg er ekstremt treffende i sammenheng med det vi prater om i dag, fordi vi på mange måter når vi tenker på performance, tenker på dans og musikk og andre kreative ting. Og ærlig talt oftere enn ikke, hvis vi løser problemer og i veldig stor skala IT-miljøer og forretningssystemer, er det virkelig et element av kunst og ofte svart kunst, fordi situasjonen etter min erfaring i noen pluss år er at moderne app-stabler øker veldig raskt kompleksiteten med en hastighet som vi aldri har sett før. Og vi sliter ærlig med å følge med, og det er organisasjoner som Uber for eksempel, og hva som helst, og Pokémon Go-utviklingsteamet, jeg mener at de opplever vekst og kompleksitet og økning av kompleksitet til priser som bare er astronomiske. Det er ikke engang skrevet bøker om det fordi vi ikke hadde tenkt oss det vekstnivået. Mitt syn er at kjernedefinisjonen av en applikasjonsstabel har forandret seg eksponentielt, og jeg kommer til å forklare hvorfor jeg tror det er tilfelle, og så føre til utfordringen på hånden, at mine gode venner på IDERA ser ut til å ha en løsning å løse .
Veldig kort, vi vet alle disse, men bare for å gjenskape dem, du vet, i de første dagene hadde vi det jeg kaller, applikasjonsarkitektur, versjon 1.0. Det var en serverdatamaskin, i dette tilfellet stordatoren med en masse terminaler festet, det var relativt enkelt å diagnostisere problemer hvis du ikke ser ting på terminalen - du kunne spore kabelen mellom terminalen og deretter serverdatamaskinen, og det var enten null kabel eller en kontakt eller noe problem hvis det ikke var relatert til terminalen, og du ser ting på skjermen, det var ganske enkelt å finne ut at tingene som forårsaket problemene, var i selve maskinen. Og du kunne sakte diagnostisere hvor i bunken som var fra maskinvaren helt opp til programvarelaget og brukergrensesnittet. I det jeg kaller versjon 1.1, gjorde vi det litt mer sammensatt. Vi satte enheter i midten slik at vi kunne plassere flere terminaler på plass. Og de var en slags kommunikasjonsenhet, og ofte var de muxes eller multipleksere, og de ville enten løpe over dedikert linje eller en oppringt linje, og slik at du hadde en hovedramme på et fjernt sted - det kan være utdannelse eller internasjonalt - og noe utstyr koblet over en SMA-kobling eller en slags WAN-tilkobling, og terminalene fungerer fortsatt på samme måte. Men du hadde litt mer kompleksitet fordi du måtte finne ut om problemet var mellom terminalene og komms-enheten eller komms-enheten og mainframe. Men stabelen holdt seg relativt lik i stordammen.
Versjon 1.2, litt mer komplisert igjen fordi vi nå la til flere enheter, vi la til skrivere og andre ting, og vi samlet disse tingene, og jeg tenker på en front-end prosessor som vil håndtere alle spørsmålene om enhetene lokalt, skrivere og terminaler og så videre med hovedrammen den fjerne enden. Litt mer kompleksitet. Men igjen, det konsistente temaet for stordatoren var appene som kjørte lokalt, så problemløsningen holdt seg ganske lik inne i applikasjonsstabelen. Og så hadde vi mennesker med ferdigheter som kjørte sortering av problemer med terminaler og skrivere og klyngekontrollere. Men så kompliserte vi ting og vi bygde nettverk og plutselig introduserer den samme typen arkitektur et nettverkslag. Plutselig hadde vi en nettverksbryter, og arbeidsstasjoner var mye mer kompliserte. Og denne versjonen av arkitektur hadde vi ofte grafisk brukergrensesnitt-apper på arbeidsstasjonen. Ikke bare hadde vi en server som kjører appbunken, men vi hadde også en annen stabel med applikasjoner som kjørte lokalt, og selvfølgelig den samme grunnleggende modellen av enheter som kobles til en server. Så tok vi et kvantesprang til den nyere modellen av det jeg kaller 2.1, og det var her vi tok den app-stacken, og vi gjorde den mye mer komplisert, mye vanskeligere å diagnostisere. Og vi introduserte mye flere enheter i front-end, på nettlesere og PC-er og mobile enheter, så videre. Og her begynte applikasjonsstabelen å dykke litt dypere i integrasjonen som operativsystemet og hypervisoren.
Dette bildet her på høyre side har vi hele stabelen, inkludert nettverksinfrastruktur, lagringsservere, virtuelle maskiner, operativsystemet og deretter de tradisjonelle tre lagene med databasemetall-applikasjoner, etc., foran til høyre. Å diagnostisere applikasjonsproblemer og ytelsesproblemer på denne modellen ble bare mye vanskeligere. Det er så mange flere bevegelige deler, og det å prøve å bore ned gjennom den stabelen bare ble, ble du et mareritt, og du måtte involvere flere ferdighetssett og organisering for å takle det. Det var ikke bare applikasjonsteamet ditt lenger, plutselig nå hadde du infrastrukturfolk, du hadde databasespesialister, rent bare jobbet med databaser og ingenting annet - i motsetning til en systemprogrammerer som visste veien rundt databaser. Nå har vi fått et scenario der IT-avdelinger må håndtere en betydelig bredere kompleksitet av "som en tjeneste", og dette hvor verden akkurat eksploderte og problemløsingsutfordringene våre ble, gikk fra å være et mareritt til bare noe som nesten er utålelig på noen måter.
Og dette kom til som en løsbar skala, vi prøver å levere tjenester kl. Versjon 3 av det jeg anser som applikasjonsbunken - den har introdusert dette som en servicemodell, der tradisjonell modell på venstre side, enterprise IT-stacken, der alt måtte styres på vår ende som forbruker og leverandør av tjenester - fra applikasjonssikkerhetsdatabase, operativsystemer, lagring av virtualiseringstjeneste, nettverksdatasentre - vi måtte administrere det hele, men vi hadde tilgang til det hele, og så kunne vi skalere ut våre evner og tekniske ferdighetssett og vi kunne bore rett ned gjennom den stabelen og vi kunne finne ting. Men da infrastrukturtjenesten og plattformtjenesten og programvaretjenestemodellen fulgte med, ble plutselig tilgangen vår til back-end-infrastrukturen, vår tilgang til plattformene og verktøyet vi leverte tjenester fra, tatt bort fra oss. Da vi begynte å konsumere infrastrukturtjeneste, hadde vi bare de fire beste delene fra operativsystemet, databasen, sikkerhetsmiljøapplikasjonen og over, tilgjengelig for oss. Alt under det var svart magi. Og det blir enda mer interessant når du flytter til plattformtjeneste, fordi du også bare administrerer applikasjonsbunken.
Når du kommer til programvare som en tjeneste, og en tradisjonell modell av det er webmail eller nettbank, er alt du har tilgang til en nettleser, så det er utålelig å prøve å diagnostisere hva som ligger bak. Og jeg har brutt dette opp i tidssoner, i tidsluker eller tidsrom hvis du vil eller generasjoner, i at fra venstre mot høyre, har vi gått fra slags pre-2000-tallet og den tradisjonelle stabelen der vi hadde tilgang til hele miljøet, og vi kunne borre gjennom det. Men med tiden ble det mer og mer sammensatt. Til begynnelsen av 2000-tallet til midten av 2000, til sent på 2000 til dagens dag, hvor vi har gått fra infrastrukturtjeneste, plattformtjeneste, programvaretjeneste, til nå refererer vi egentlig til en forretningstjeneste. Og kompleksiteten har økt dramatisk. Det er så mange flere bevegelige deler. Men tilgjengeligheten av ferdigheter blir vanskeligere og vanskeligere og mer og vanskeligere å benytte oss av. Å finne mennesker med de rette ferdighetene med riktig tilgang til de riktige verktøyene for å komme og dykke ned i denne stabelen og finne ut hvor er noe som går sakte. Er det den bærbare datamaskinen eller skrivebordet mitt, er det telefonen eller nettbrettet mitt, er det tilkoblingen min over 3 eller 4G, eller den dedikerte lenken min med ADSL, eller ISDN hva det måtte være? Eller til og med oppringing, selv om det er mindre og mindre tilfelle i disse dager. Er webserveren slutt, er det noe inni webserveren? Er det appserveren? Er det noe rundt minnet og disken til CPU og nettverksytelse inne i applikasjonsserveren? Kjører databasen der inne?
Og du kan forestille deg, du tegner dette bildet veldig raskt av kompleksiteten som begynner å utvide seg som et stort smell-bilde, av denne stadig økende boblen som vi prøver å få armene rundt oss og har ferdighetene til å dykke ned i og kunnskapen og hvorledes man kan dissekere og trekke fra hverandre. Og vi er veldig mye nå i den epoken hvor, du vet, menneskene ikke kan takle den fysiske skalaen, selv om du har muligheten til å trekke databasemiljøet fra hverandre og trekke databasen fra hverandre og dykke ned i detalj i databasen. Antall databaser du må administrere nå vokser raskt. Alt drives nå av en database. Svært få applikasjoner i disse dager drives ikke av en database. Og databasetyper vokser også raskt. Det er ikke bare de tradisjonelle SQL-databasene, noen ganger er SQL, andre ganger ikke-SQL, andre ganger er det en grafisk database, andre ganger er det en dokumentdatabase. Og det er alle disse forskjellige typer funksjoner som disse forskjellige databasene har, og som et resultat har hver av dem forskjellige ytelsesutfordringer og forskjellige ytelseskriterier. Logging av databaser og dokumentdatabaser fungerer veldig, veldig annerledes og utfører en annen funksjon enn en tradisjonell ACID-kompatibel, ANSI 92-kompatibel SQL-database. Og hvilke ting vi lagret der inne.
Vi er på et tidspunkt der jeg - og jeg tror Eric henviste til dette - at mennesker sliter med å følge med på kompleksiteten i det vi bygger og hastigheten som vi bygger, og vi Jeg er nå på det punktet der den eneste måten for oss å administrere denne infrastrukturen, og den eneste måten å overvåke og fordype problemene vi står overfor, er med verktøy og de riktige verktøyverktøyene. Og da alltid den rette generasjonen av verktøy. Verktøy som faktisk forstår back-end infrastrukturen. Det er ikke OK lenger bare å kaste en SQL-skjerm, eller et SQL-spørringsverktøy på noe og begynne å trekke fra hverandre et spørsmål og se hva som får det til å fungere. Vi trenger faktisk et verktøy som forstår dannelsen av spørsmål og riktig måte å lage spørsmål, og de riktige måtene for spørsmål å snakke med infrastrukturen på baksiden, og hvordan de presterer når de gjør det. Og for å se på tidspunktet for interaksjonene og rekkefølgen de foregår i.
Og det er en mye mer sammensatt utfordring, og det fører meg til spørsmålet mitt om roundup, og det vil si at når kompleksiteten til appbunken vi utvikler øker, trenger resultatverktøyene og verktøyene vi bruker for å administrere disse, nødvendigvis å bli stadig smartere og mye mer i stand til å se på flere ting. Men også mye smartere på hvordan de studerer hva som kjører på baksiden og hva de kan oppdage om det, og potensielt til og med en slags analyser som blir utført for å forstå at interaksjonene og ytelsen blir levert, og hvorfor den presterer tregere eller raskere.
Og så med det skal jeg gi videre til vår kjære venn fra IDERA, Bill Ellis, og se hva han har å si i dag om hvordan de løser dette problemet. Bill, over til deg.
Bill Ellis: OK. Jeg heter Bill Ellis og tusen takk. Vi skal snakke om at søknaden min kjører sakte, på tide å få presis. La oss se hva Precise, et IDERA-produkt, kan gjøre og hvordan det kan hjelpe deg. Mange ganger finner du bare ut at det har vært et ytelsesproblem fordi en sluttbruker har ringt deg, og det er virkelig et stort problem i seg selv. Av alle i IT var det ingen som visste før telefonen ringte. Nå, det neste store problemet er hvordan kan vi hjelpe denne personen, og det er virkelig ikke et trivielt problem. Det er en takeaway fra dette. Det er utover dette lysbildet, det er utover de andre. Og jeg vil at du skal se om du kan få det som det er. Men, som vi hadde nevnt, krever en applikasjon, er avhengig av mange forskjellige teknologier, applikasjonsbunken er høy og vokser. Og mange mennesker får tilgang til en applikasjon via en nettleser, og overraskende nok er det mer og mer behandling som skjer i nettleseren med skripting osv., Og så har du selvfølgelig nettverket, webserveren, firmalogikkoden og databasen. Det jeg vil at du skal vurdere er at alle viktige forretningstransaksjoner samhandler med databasen, enten det er tidskortrapportering, lageroppslag, en innkjøpsordre, databasen blir oppdatert. Og slik blir databasen virkelig grunnlaget for ytelsen. Og databasen kan selvfølgelig slå på, eller stole på nedstrømmen på lagring. Hver av disse teknologiene er tett koblet og kan se hva som skjer. Du må vite hva som skjer for å kunne måle er kritisk.
En ting vi finner er at mange av kundene våre har et verktøy, og de har et verktøy for hver teknologi, men det de ikke har er kontekst. Og kontekst er i utgangspunktet muligheten til å koble prikkene mellom hvert nivå i applikasjonsstabelen, og dette er faktisk relativt enkelt. Vi pleide å ha en begrensning på tolv nivåer, men i utgangspunktet endret det, vi har ubegrensede nivåer og vi støtter blandede miljøer, slik at vi i utgangspunktet kan bli ekstremt kompliserte med en presis løsning.
Nå, på et høyt nivå, er det slik vi løser problemet, og det fokuserer på transaksjonen, sluttbrukertransaksjonen fra klikk til disk, forteller oss hvilke som kjører sakte, hvilke som bruker ressurser, men nøkkelen er dette - vi lar deg hente og bruke bruker-ID-en deres beliggenhet og ikke bare hele transaksjonstiden, men hvor mye tid som brukes på hvert enkelt trinn. Tid er ytelsenes valuta, og den viser også hvor ressursene blir brukt. Vi vet ikke hvor problemet kommer til å være, så vi må ha tilstrekkelige beregninger og analyser på hvert nivå for å kunne diagnostisere hva problemet er, hvor problemet kan være.
Nå, i dagens presentasjon, skal jeg fokusere på dette området. Jeg vil at du kan være trygg på at vi i utgangspunktet gir samme synlighet på alle nivåer i applikasjonsstabelen og det avgjørende, er dette å fortelle oss hvem, hva, hvor og så denne delen, dette kommer til å fortelle oss hvorfor. Og det er virkelig grunnen til at det er helt avgjørende for å løse problemer, ikke bare å vite om dem. Nå var det andre som kom veldig tydelig frem i presentasjonen at det er umulig å gjøre dette. Du trenger automatisering. Og automatisering betyr at du har varsling, du har noe som forteller deg, forhåpentligvis før sluttbrukermiljøet, at du har en kontinuerlig trend, bygget opp avvik fra trendvarsling. Og så tilbyr vi også en linje i sanden, du bryter faktisk SLA. Nå tilbyr du mye forskjellig informasjon - ikke alle trenger å konsumere buffeen, noen mennesker vil bare ha en lett matbit, dette er salat, og med det at vi tilbyr en portal kan vi laste opp informasjon, den trenger bare en bestemt bruker eller et bestemt samfunns informasjonsbehov om ytelse. Programmet kjører sakte, det er på tide å få Precise. Vi skal virkelig fokusere på fire ting. Den ene er plasseringen, og legger inn sluttbrukeren. Nok en gang viser den konteksten som knytter sammen prikkene, og den tredje delen av forskningen at nesten 90 prosent applikasjonsproblemer er i databasen, og det er virkelig en slags travesty at flertallet av ytelsesløsningene kan fortelle deg en SQL-setning. Men de forteller deg ikke hvorfor SQL-setningen kjører sakte.
Og så, hvorfor er alltid det avgjørende, og Precise er utmerket til å vise hvorfor, for alle lag og spesielt databasen, og bare for å dele litt om vår supportmatrise med deg, som vi støtter SQL Server, Sybase, DB2 og / eller bulk. Utseendet og løsningen på løsningen er veldig lik, så hvis du ser på flere applikasjoner, men litt forskjellige arkitekturer. Informasjonen jeg deler her har utseendet og preget, tilnærmingen, den er den samme uansett hva de underliggende teknologiene i bruk tilfeldigvis er. Presis er nettaktivert. Vi kommer inn, vi autentiserer Precise, og med det går vi inn, og det første vi kanskje vil se på er ytelse etter sted. Og slik at du faktisk kan se her de forskjellige stedene der folk faktisk får tilgang til henrettelsene sine. Du kan se om noen forlot en side før den ble gjengitt fullt ut, eller om det er feil.
Nå, en ting med disse applikasjonene, er nettverket eller avstanden fra applikasjonsserveren gjør annerledes. Det er veldig enkelt å se at det er et nivå på nettverket. Jeg kan se når folk ble opptatt, og så en annen interessant ting, vi snakket om hvordan det er behandling i nettleseren, de merker faktisk at noen av de forskjellige nettlesertypene gir et bedre miljø for rask prosessering. Og så å vite om folk har tilgang til via Chrome eller IE, eller hva det måtte hende, kan du faktisk oppdage veldig ofte at en nettlesertypeversjon faktisk er overlegen en annen. Noen ganger har du offentlig vendt, du kontrollerer ikke nettleseren, noen ganger er applikasjonene internt vendt der du kan anbefale folk en nettlesertype til sluttbrukersamfunnet, og det er disse typene dybdesynkbar synlighet og analyser som Precise er i stand til å gi. Nå får vi se på en applikasjon.
Jeg er ikke sikker på om dere kan se pekeren min, men jeg ville beskrive dere, toppgrafen. Y-aksen viser gjennomsnittlig responstid. X-aksen er tid over en dag. Og det er faktisk et stablet søylediagram og det stablede søylediagrammet, det totale viser deg hva ytelsen er, og så viser det en grad av hvor mye tid som brukes i hvert enkelt trinn eller hvert enkelt nivå av applikasjonen. Fra klienten, via webserveren, er den grønne Java, dette stedet vi bruker Tuxedo og ned i databasen. Nå viser den nedre halvdelen av skjermen de forskjellige nettmenyene som nås, og vi har deretter assortert med bare en liten grønn pil som peker nedover. Det er i synkende rekkefølge, og det bobler opp til toppen, nettmenyen begynner å vise den. Vi viser faktisk utførelsestid, responstid for hver enkelt teknologi, og så er det faktisk en stolpediagram for hver av disse nettmenyene, og så får vi begynne å få en ide om hva som skjer. Husk nå at vi sorterte dette med en sluttbruker som vil ringe, men hvordan finner jeg sluttbrukeren? Jeg kommer inn her, jeg åpner en meny som lar meg filtrere på en bestemt bruker, så jeg satte den brukeren til Alex Net, klikker OK, så fokuserer vi bare på aktiviteten fra Alex Net. Hva dette nå gjør, er at det gjør at IT og IT-ledelse kan være direkte lydhøre for en sluttbruker, og spesielt at de så på innholdsstyring som hadde seks henrettelser med en responstid på litt over tre sekunder. Vel, tre sekunder er ganske bra, det er ikke forferdelig, men det, kanskje det er tregere.
Det jeg kan gjøre med dette, er at jeg kan skive og terne denne informasjonen på forskjellige måter. Jeg kunne vel sagt, er denne transaksjonen treg for alle? Er det tregere i dag for Alex enn det hadde vært i går? Går det tregt for alle brukere på et bestemt sted? Eller, og hva det gjør er at det gir meg mulighet til å skive litt terninger og få en ide om hva som skjer, hvor universelt problemet er, og det er veldig viktig å kunne identifisere sluttbrukeren, fordi det ikke bare handler om programvaren, infrastrukturen, det handler også om hvordan sluttbrukerne utøver applikasjonen. Ofte kan det hende du har en ny ansatt eller noen med en ny jobbfunksjon, og de er ikke kjent med visse SAP-skjermer eller visse PeopleSoft-paneler, og de trenger en liten peker, kanskje lar de feltene være tomme eller sette inn jokertegn og de tvinger store resultater som skal returneres fra databasen. Men når du har bruker-IDen, kan du faktisk ringe dem før de ringer deg. Den andre tingen vi finner er at når brukerfellesskapet er klar over at IT vet hva de gjør, er det mange ganger de blir bedre oppførte og mange problemer, mange ting som hadde vært problemer, bare slags fordamper, fordi folk oppfører seg, bare operer litt mer forsiktig. De bruker systemet med større omhu.
Sluttbrukeridentifikasjonen er avgjørende. Til slutt er det viktig at IT kan hjelpe en bestemt sluttbruker. Det vi har gjort her, er at vi har gått til "Flow" -fanen. Du kan se det i øverste venstre hjørne. Og vi har fokusert på en bestemt komponent på nettmenyen. Og på høyre side er en analyse av den aktuelle transaksjonen, og så øverst er det faktisk nettleseren og deretter View, bare for å bli kjent med litt av ikonene i GUI er for webserveren, så vi kan se attributtpunktet. Og så er "J" for Java og "T" er for smoking, og naturlig nok er "Q" SQL. Vel, at kontantverdien i utgangspunktet identifiserer en bestemt SQL-setning. Vurder hva dette gjør. Vi har identifisert en bruker til en transaksjon, til den underliggende applikasjonskoden, inkludert de enkelte SQL-setningene. Når jeg ser på de individuelle SQL-setningene, kan jeg se at den totale responstiden er ansvarlig for omtrent seks prosent, og når de legger opp de fire beste SQL-setningene, tok de omtrent en fjerdedel av transaksjonen tid.
Ofte er databasen den enkleste å manipulere. Det er vanligvis enklest å få en billig, mye overlegen ytelse. Nå må jeg gå litt dypere for å finne ut hva som skjer og hva, jeg vil at eksemplet er i stand til å faktisk avsløre den individuelle SQL-setningen, og du vet at jeg nesten kan garantere deg bare ved hvert eneste skudd på linjen hadde et slags databaseverktøy og hva databaseverktøyet gjør, men bare å se på en teknologi isolert, er at du ser på, fokuserer på helsen til den teknologien. Og mange ganger ser folk på en topp ti-liste. Nå er denne SQL-setningen ganske rask, den kommer ikke til å være på topp ti-listen, men det er SQL-setningen som denne transaksjonen er avhengig av. Og det jeg kan gjøre tilbake ved det ordet, konteksten, er at nå kan jeg få dette til dyp blikkoppmerksomhet, men i sammenheng med den individuelle SQL-setningen.
Nå kan den personen åpne opp Precise i sammenheng med den enkelte SQL-setningen, og Precise fanger den faktiske utførelsesplanen som den bruker, utførelsestiden dette er viktige ting for DBA, faktisk vil vise, kan du se at 50 prosent av tiden blir brukt på å vente på lagring. Femti prosent av tiden brukes i CPU, slik at du begynner å få ideer om hvor tiden blir brukt, hvordan jeg kan vrikke den tiden ned, og ideen er å gi folk alternativer, fordi forskjellige svar har forskjellige kostnader og risiko forbundet . Ideelt sett er vi ute etter den lave risikoen og rimelige løsningen på et problem. Nå som SQL-setningen spores av en hasjverdi og det er en venstre “midt på skjermen” i den venstre typen av skjermen, og det som kommer til å gjøre, er at den tar deg til en SQL-oppgave. Og denne SQL-oppgaven er en forhåndsbygget arbeidsbenk, og hva dette gjør, er det at jeg virkelig kan analysere spesifikt hva som påvirker SQL-setningen som starter med utførelsesplanen. Utførelsesplanen velges av optimalisatoren når uttalelsen er analysert, det - tilbake til matanalogien, det er oppskriften som følges for å løse SQL-setningen.
Og noen oppskrifter er mer kompliserte enn andre, og derfor gir vi funn. Og det vil faktisk vises her, hei, mye tid det gjør sekvensiell I / O på en bestemt indeks. Og se nå, når du går tilbake til oksygen, følger du denne indeksen. Har den indeksen blitt defragmentert nylig, hva er helsen til hvis? Hvilken bordplass bor den i? Er tabellplassen adskilt fra tabellen den refererer til? Og så begynner det å gi deg alle mulige ideer om hvordan du kan gjøre for å løse problemet. Nå, tydeligvis, vet du, vi bygger inn en indeks. Det er mye lavere risiko, mye enklere enn kanskje å flytte en indeks fra en tabellplass til en annen tabellplass, så det vi ønsker å gjøre er slags oppbyggingsalternativer, slik at vi kan distribuere alternativet med lavest mulig pris og laveste risiko å løse problemet.
Presis kan også gjøre ting som fange bindvariabler som blir kastet til en SQL-setning. Det er klart at variablene som støpes kommer til å kontrollere størrelsen på resultatene som er satt. Og det vil kontrollere hvor lang tid det tar SQL-setningen å utføre, og hvor mye data som må sendes og behandles av applikasjonen gjennom Java, gjennom .NET, til webserveren som pluss nettverket, endelig gjengitt i sluttbrukerleseren. . Det som skjer i databasen påvirker direkte nettlesertiden. Og så vil det være avgjørende å ha dette nivået av synlighet, slik at vi kan vite nøyaktig hva som skjer og gi DBA flest muligheter, slik at de kan velge hvilket som er mest fornuftig, gitt en bestemt situasjon.
Dette er noen av sitatene og kommer fra en PeopleSoft-butikk som har global distribusjon. Precise støtter PeopleSoft og SAP, Siebel, Oracle, E-Business Suite, hjemmelaget Java- og .NET-applikasjoner. Vi støtter så hvis du ringer webtjeneste til flere JVMer, fra Java til .NET tilbake til Java, kan vi spore alt dette. Det kan være på forhånd, det kan være i skyen. Det avgjørende er at ting må instrumenteres.
Og så, bare et par sitater fra en av kundene våre. "Før presise, brukte våre DBA-er OEM, " - det er et verktøy som kun er basert på databaser, og de sa i utgangspunktet: "Hei, forekomstene ser bra ut." Men de kunne hjelp til å fortelle eller adressere et problem med en bestemt transaksjon. Presis ga synligheten til å gjøre det. Og det å ha den informasjonen om SQL-setningene var avgjørende for å gi DBA-ene synlighet til å skjule ytelsen ut av databasen fullstendig. Og så det var veldig fint. Typisk utover noen av verktøyene du kanskje ser på.
Og da elsket IT-ledelsen virkelig det faktum at Precise var i stand til å oversette en kompleks URL til et panelnavn. Og på den måten hvis en sluttbruker ringer og sier: "Hei, jeg har problemer med dette, " kan du isolere og se hvem som er den brukeren, hva utfører de, hva slags ytelse, de måler faktisk gjengivelsen tid i sluttbrukerens nettleser. Det er et sant mål på sluttbrukeropplevelsen. Og det er også helt nødvendig å ha den bruker-IDen for å hjelpe en bestemt person som ringer.
Hvordan gjør Precise dette? Og så vil vi gjerne dele arkitekturen vår. Precise skal bo på sin egen server, og leve i en VM, det kan leve i skyen. I front-end er Precise nettaktivert, enten du bruker dashbord, varselgrensesnittet eller ekspertgrensesnittet. På datainnsamlingssiden kan vi faktisk gjøre uten agent for flere forskjellige teknologier. Imidlertid vil vi ofte kreve en agent, og det er plusser og minus for å ha en agent. Et stort pluss er dette, er dataene som er samlet inn, kan forbehandles før de sendes over ditt LAN. Og så betyr det at vi kan minimere den totale effekten av overvåkningsløsningen på målmiljøet.
Nå er det bare å vurdere som et alternativ, hvis du har "agentløs", er det fremdeles en datainnsamler, det er bare et spørsmål om hvor den bor, og det ringer og passerer rå data om målapplikasjonen over ditt LAN. Og det er faktisk ganske dyrt. Og så ved å forbehandle kan vi faktisk minimere fotavtrykket. Du vil kunne overvåke både fysisk og virtuell. Og en ting jeg ønsket å si om virtuell teknologi er at jeg virkelig fokuserer på er utnyttelse. Det Precise fokuserer på er strid. Når minimerer VMware-teknologien ressurser til din VM? Og slik blir det veldig enkelt. Hvis du bare ser på innen en gjest-VM, har du bare en del av bildet. Å være i stand til automatisk å oppdage og varsle om strid, det er veldig viktig.
Precise kan overvåke opptil 500 forekomster, så veldig store distribusjoner har i utgangspunktet flere presise servere. Og for en global distribusjon vil det typisk være en presis server i hvert datasenter. Forresten, for de aller største distribusjonene kan du faktisk forbinde disse sammen slik at du kan se bedriftsnivå på hva som foregår og kunne tilby rapportering, osv. Nå, som jeg hadde nevnt, har vi mye teknisk analyse. Ikke alle trenger å gå inn i ekspertgrensesnittet, så vi tilbyr et tilpassbart dashbord. Og hver av disse portlets eller widgets, de er alle valgfrie. Og noen vil kanskje bare gå, “Hei, hvordan kan du slå et varsel om et nivå i vårt miljø? Hvordan gjør sluttbruksgruppene seg fra et ytelsesperspektiv? ”Eller kanskje har du et spørsmål om infrastrukturen, og kanskje til og med Tuxedo-ytelsen. Eller til og med lastbalansering. Det er litt interessant her i denne belastningsbalanserende delen. Jeg ser på portletten i midten på venstre side. Du kan se at antall henrettelser er veldig likt mellom hver av webserverne. Men responstiden er veldig forskjellig på den øverste. Du kan faktisk bore inn og finne ut nøyaktig grunnen til at responstiden på den webserveren var mye tregere enn de andre.
En ting med belastningsbalansering, dette er veldig viktig, og du vet, ikke alle lastbalanseringspolicyer passer for alle applikasjoner. Det er faktisk veldig nyttig å validere retningslinjene for belastningsbalansering. Vi ser faktisk med noen applikasjoner som den nye PeopleSoft Fluid GUI, hvor faktisk noen webservere vil gå offline. Og så er det noe som er veldig kritisk. Hvis du distribuerer PeopleSoft Fluid GUI, kan du kontakte oss. Vi kan gi deg mye innsikt og mye kunnskap om hva andre kunder har møtt med det. Hver av disse portlets kan være ganske detaljerte. Som midten til høyre, med det blå og det grønne, faktisk viser sverdspissmønsteret, det viser slags at søppelsamlingen din i WebLogic-nivået kjører slik du forventer at den skal løpe. Hver av disse portlets kan være veldig fokusert eller kan være veldig høyt. Og grunnen til at det er viktig, eller kan være viktig, er mange ganger at det ikke er bra nok å bare ha denne informasjonen innen IT, noen ganger må du dele denne informasjonen med applikasjonseiere og noen ganger med toppledelsen, om hva som skjer .
Jeg ønsket å dele et par historier, slags "Suksess i datasenteret." Og disse er databasefokusert, og jeg har andre historier som er midtveisfokusert. Men for i dag har jeg veldig lyst til å fokusere på databasen. La oss ta en titt på skjermen fryser. Det som skjedde her er at denne spesielle butikken hadde en virksomhet SLA, at hvis en bestilling mottas innen 15.00, sendes ordren den dagen. Og så lageret er ekstremt travelt i løpet av den tidsrammen. Og så var det veldig frustrerende å få skjermfrysing. Og så veilederen - dette er et mindre selskap - veilederen gikk faktisk inn i IT og går selvfølgelig opp til DBA og sier: "Nå, hva skjer?" Og så hva vi gjorde, var vi i stand til å vise nøyaktig hva skjedde. Nå er dette JD Edwards, en flerlags applikasjon, dette er salgsordre-skjermen. Du kan få et inntrykk av hva virksomheten var, i utgangspunktet et just-in-time inventar, og slik at du i utgangspunktet ser på lagerapplikasjoner. Og nå sender du i utgangspunktet til en rekke forskjellige kundesider, forskjellige butikker. Og det vi gjorde er at vi åpnet opp Precise.
I dette tilfellet, før vi så på Oracle, ser vi her på SQL Server, og nå viser den øverste halvdelen oss en stablet stolpediagram over hvor SQL-setningene bruker tiden sin mens de utføres. Hver svak tilstand blir regnskapsført i y-aksen. X-aksen hvis selvfølgelig over tid, og du kan se at den stablede søylediagrammet endres fra tidsstykket avhengig av hva som kjøres og hvordan det bruker systemet. Nå i dette spesielle tilfellet fokuserte vi på den tredje SQL-sekvensen fra toppen. Det er tekstet VELG FRA PS_PROD, og du kan se i den kolonnen at vi har fanget den faktiske utførelsesplanen. Og du kan se gjennom hele henrettelsene. Det faktum at den aktuelle SQL-uttalelsen var ansvarlig for 9, 77 prosent av ressursforbruket i løpet av denne tidsrammen som vi ser på - og det er et viktig poeng, tidsrammen, Precise holder en rullende historie - og så kan jeg i utgangspunktet ringe inn og finn ut hva som skjedde på et bestemt tidspunkt eller over tid. Jeg kan se trending.
Nå denne SQL-setningen, ser du at stablet søylediagram der, det er mørkeblått. Som sier at vi bruker all CPU. La oss gå foran og fokusere ved å klikke på denne “TUNE” -knappen på den aktuelle SQL-setningen. Det vi gjør er at vi tar det med inn i det verkstedet, ferdigbygde verkstedet som er designet for å si: "Hva vil DBA vite om denne spesielle SQL-setningen?" Og du kan se på høyre side en fane som heter " Historikk ”som er valgt. Og hva jeg ønsker at du skal gjøre nå, er en slags skift over til venstre, der det står “Endringer mot varighet gjennomsnitt”, gjennomsnittlig varighet. Og hver av disse barene representerer arrangementer om dagen.
Du kan se onsdag, torsdag, fredag, henrettelsestiden var, jeg skal runde til punkt to. Y-aksen viser punkt fire sekunder, så punkt to. Svært få skjermfryser, operasjoner går bra, i SLA. Dessverre 27. februar ble utførelsesplan endret, og det forårsaket en øyeblikkelig endring i utførelsestiden. Plutselig går utførelsestiden opp, fire X, kanskje fem X, og ting kjører veldig dårlig. Nå presiser, i depotet, faktisk tidsskrifter alle endringene som kan påvirke atferden. Og du kan se at vi faktisk har fanget endringer i akseplanene. Den i midten sier “Tabellvolum endret.” Og så tabellene vokser og vi har rett på cusp, når SQL-setningen er analysert, velger optimeringsprogrammet en utførelsesplan eller en annen utførelsesplan.
Nå er det heldigvis på denne uken her på mandag at det flipp-floppet, så det var på et bra tidspunkt. Dessverre vipper det igjen, og du vet hva, sluttbrukerne begynner å forutse at skjermen fryser, og de begynner å sende den skjermen på nytt, og de skyver utførelsestellingen opp og opp og opp. Vi har en enorm mengde detaljer, men for å løse dette problemet og deretter unngå det i fremtiden, trenger vi en ekstra informasjon. Og det er vist meg under sammenligningen av de utførelsesplanene. 5. mars da det var raskt og effektivt, på venstre side viser det utførelsesplanen. Da det var tregt og ineffektivt 12. mars, kan du se at det gjør et filterforbindelse. Filterforbindelsen tvinger bare mye mer CPU-forbruk og gjør mye mer arbeid. Utfallet er identisk, det er bare å gjøre mye mer arbeid. Det er som om du går og skaffer deg en ingrediens av gangen, i stedet for å gå til spiskammeret og få alle ingrediensene samtidig. Og det er slik en mer effektiv måte å gjøre dette på. Nå som vanligvis vet dette, var DBA i stand til å bruke spørreplan for å unngå denne sakte utførelsesplanen og låse fast i høy ytelse.
Nå var den neste typen krigshistorie “Rapporter er sent.” Jeg tror mange kan identifisere seg med dette scenariet. Det kan hende du har ad hoc-rapportering, du kan bruke et verktøy som NVISION, du kan ha noe tredjeparts rapporteringsverktøy. Og det som skjer er at verktøyet utvikler SQL. Og ofte er SQL ikke egentlig kodet så bra. Og dette kan også gjelde en situasjon hvor du vet at du har en tredjepartsapplikasjon, ikke sant, der SQL ikke var skrevet internt, og så som en DBA, “Jeg kontrollerer ikke SQL, hva skal jeg gjøre noe med det? ”Vel, Precise gir noe jeg ikke er kjent med noe annet databaseverktøy som gir, og som er et objektbilde. Kombinert med anbefalinger og modellering. Og det vi kan gjøre, er å faktisk synliggjøre hodet. I stedet for bare å se på aktivitet, la oss undersøke, vel, hvilket objekt er tyngst på systemet? Og i form av den nedre delen av skjermen kan du se ordrelinjen SQL og du kan se kolonnen “i MS-SQL”. Og ordrelinjetabellen er som ti ganger travlere enn noe annet bord i systemet. Jeg tror det du også vil merke i den øverste halvdelen, tildelingen av plass vokser, og du kan også se på spesifikasjonene på serveren hvilken versjon av programvare vi kjører. Precise vil faktisk sjekke sporede endringer i de primære innstillingene. Nok en gang, årsak og virkning.
Nå, med fokus på ordrelinjetabellen, hva jeg kan gjøre med det detaljerte historiske depotet mitt, er at jeg faktisk kan korrelere SQL-setningene som er i strid med ordrelinjetabellen. Og du kan begynne å se på hvor leddet i disse SQL-setningene. Og du begynner å legge merke til at hvor-klausulen er ganske lik mellom de forskjellige SQL-setningene. Og jeg vil foreslå deg at i innspillingssystemet ditt vil du finne den samme tingen. Fordi forretningsbrukerne, vil forretningsanalytikerne ønske å gjøre ting som samlet forretningsaktivitet den siste dagen, den siste uken, den siste måneden, det siste kvartalet, det siste året. Du kommer til å se veldig likt hvor klausuler, rekkefølge etter, gruppe etter, og det betyr at det kommer til å være visse indekser som gir mening for disse SQL-setningene.
Og så har Precise en anbefalingsmotor, du kan se det i øvre høyre hjørne, og det vi kan gjøre er å faktisk få anbefalinger. Si: "Hei, jeg kjører alle SQL-setningene, hvilke indekser vil adressere dem?" Indeksene blir presentert for deg, og du kan faktisk se DBL. Nå er Precise skrivebeskyttet, den gir ikke muligheten til å klikke på en knapp og opprette indeksen, men det er enkelt nok til å gjøre utenfor Precise. Men her er det avgjørende, Precise lar deg evaluere og modellere endringene, så det er denne Evaluer-knappen i nedre venstre hjørne av skjermen. Og hva det gjør er at det viser SQL-setningene i før og etter.
La oss se på disse SQL-setningene. Ser du denne kolonnen her som sier "i MS-SQL, " og den sier en time, fire minutter? Den øverste SQL-setningene utfører eller bruker cirka 64 minutters ressurser. Og den forventede forbedringen er 98 prosent. Disse endringene vil spare timer for behandling. Den neste SQL-setningen er 27 minutter og vil i utgangspunktet spare en tredjedel. Det er omtrent ti minutters behandling. Oppsummert vil du faktisk spare timer og timer verdt å behandle med disse foreslåtte endringene. Og slik å kunne vite dette foran, å kunne modellere dette. Du kan også bruke "hva-hvis" -funksjonen til å si: "Vel, jeg vil ikke lage indeksen, eller hva skjer hvis jeg endrer rekkefølgen på kolonnen?" Og så kan jeg bruke denne modelleringsfunksjonen for å finne ut nøyaktig hva som skal skje.
Den andre tingen som er avgjørende, er at når jeg gjør endringen, kan jeg faktisk måle for en individuell SQL-setning. Du så SQL-setningshistorikken i forrige eksempel, og jeg kan faktisk bekrefte om jeg oppnådde besparelsene som ble modellert. Og slik at tilbakemelding, fullføring av tilbakemeldingssløyfen er helt avgjørende.
OK, her er det endelige eksemplet jeg skulle ha for deg. Dette er en SAP-butikk, og du vet, de hadde gått for en stor oppgradering, de gjorde noen ting med tilpassede transaksjoner, og i utgangspunktet var en sluttbruker ikke fornøyd med ytelsen. Og det vi gjorde er at vi var i stand til å fokusere på hva den sluttbrukeren opplevde. Og du kan se øverst på listen “CHOUSE”, og responstiden er litt over 61 sekunder. Denne tingen tar et minutt å henrette. Nå kan du se at vi har en stablet stolpediagram som er rettet mot SAP. På høyre side viser det klienttid, køtid. Det blå er brukstid og i et SAP-miljø, det er ABAP-kode, og deretter databasen. Og så databasen, du vet, den kan være Oracle, den kan være SQL, den kan være HANA. Vi er i utgangspunktet i stand til å vise det.
Nå som vi gjør med Precise er vi å fokusere, for den transaksjonen og den brukeren, hvilke SQL-setninger som kom ut. Nok en gang, den konteksten for å koble prikkene. Nå denne øverste SQL-setningen, kan du se at den er sirklet, den kjøres på to millisekunder. Du kan ikke klandre databasen hvis den kjøres så raskt. Utførelsesantallet er veldig høyt. Egentlig kan vi gå tilbake til ABAP-koderen og si: "Hei, hva skjer?" Vi fant faktisk ut at koden i databasen ble plassert på feil sted, hekker på feil sted i løkken, gjorde at endre og så kan vi måle etter. Du kan faktisk se hva forestillingen er etter. Ikke bare på SQL-setningsnivå, men også på det tilpassede kodenivået. Og slik kunne de leve med en eksekveringstid på fire og et halvt sekund. Og dette er bare et par eksempler på hvordan Precise kan utnyttes, og du kan utnytte det. Akkurat som en rask oppsummering, viser Precise ytelse etter sted, etter sluttbruker-ID, det gir kontekst gjennom applikasjonsstabelen. Du kan bore inn på årsaken. Og jeg tror en av de store differensiererne er å kunne vite, ikke bare SQL-setningen, men hvorfor SQL-setningen kjører sakte, og være i stand til å identifisere striden og i utgangspunktet tilby flere alternativer for å løse problemer. Dette er hva Precise har å tilby, og du kan forbruke oss, vet du, på en lett måte, eller hvis du har veldig dype, veldig utfordrende problemer, elsker vi å ta på dem også.
Eric Kavanagh: OK, jeg må si det var mye fantastisk detalj, Bill. Takk for at du viser alle disse skjermbildene. Og fra mitt perspektiv oppfylte du virkelig det jeg forklarte på toppen av timen, som er nummer én, du må ha det rette verktøyet. Du må ha et verktøy som lar deg mengden kontekst som kreves for å identifisere alle elementene i ligningen, som noen sa i en film en gang, det var litt morsomt. Men la meg gå videre og overlate det til Dez fordi jeg vedder på at han har noen spørsmål til deg, og jeg vil skyve en av disse lysbildene bare for visuelt godteri, hvis du vil. Jeg er faktisk, hold på, la meg ta dette tilbake. Men Dez, jeg er sikker på at du har noen spørsmål, ta det bort.
Dez Blanchfield: Ja, det gjør jeg, wow. Dette verktøyet har kommet langt siden jeg opprinnelig visste det, og jeg var ikke klar over at du faktisk hadde kommet ganske så dypt i bunken nå. Det er bare ganske overveldende. Bare veldig raskt, et par ting. Distribusjonsmodellen, kan du bare virkelig raskt, på et minutt eller to, bare skissere den tradisjonelle eller typiske distribusjonsmodellen. Du nevnte at den var tilgjengelig som en virtuell maskin. Det kan kjøres i skyen. Og jeg antar at et av spørsmålene som sannsynligvis vil komme opp, og jeg tror det var et par spørsmål som kom gjennom i spørsmål og svar-delen. Bare for å oppsummere dem i sammendrag, slik at den vanlige distribusjonsmodellen og den type akse som kreves, er den tradisjonelt distribuert på stedet eller vert eller i skyen? Hvilke typer distribusjonsmodeller ser du normalt? Og hvilken type akse kreves for å få den til å fungere? Må vi endre ting på sikkerhetsnivå rundt nettverkstilgang, og så videre? Eller kan dette bare oppføre seg som sluttbruker?
Bill Ellis: Ja, så for tiden er flertallet av installasjonene på forhånd. Flere og flere legger komponenter av applikasjonsbunken i skyen, og vi kan også håndtere det. Distribusjonen vi trenger en server å kjøre på, den kommer til å oppfylle visse spesifikasjoner. Vi må ha en database for å lagre det historiske depotet, så å møte disse forutsetningene er slags første skritt. Det neste er at vi absolutt trenger å ha litt kunnskap om selve applikasjonen, og installasjonen er veiviserdrevet og i utgangspunktet fylle ut feltene. På grunn av dybden av informasjon vi får, vet du, fra et nettprosessnivå til koden som kjører, trenger vi å ha noen privilegier. Vi har en sikker datamodell, eller sikkerhetsmodell, må jeg si, fordi agentene kjører under legitimasjon som er helt adskilt fra folk som bruker metadataene om transaksjonene osv.? Precise kommuniserer via TCP via IP, og derfor krever vi at visse porter er åpne. Som et raskt eksempel, som at standardporten er 2702. Den typen detaljerte ting er noe hvis folk er interessert, kan vi komme nærmere inn på det. Men vanligvis er vi veldig raske tid-til-verdi. Hvis noen står overfor et stort problem, kan vi ofte få installert tingen og skinne et sterkt lys over en situasjon i løpet av timer.
Dez Blanchfield: Ja, jeg hadde definitivt den sansen også. I distribusjonsmodellen snakket du om veldig stor skala og opptil 500 forekomster og hvordan det kunne forbundes. Hvordan ser det ut på helt inngangsnivå hvis noen vil - fordi jeg vet at IDERA er veldig stor på å gi tilgang til gratis forsøk, gratis demonstrasjoner, og jeg husker at jeg så på nettstedet nesten alt kan spilles med. For folk her inne, og jeg tror jeg savnet det tidligere, men jeg tror det var et spørsmål som dukket opp rundt hvordan ser et typisk nettsted ut og hvordan får folk tilgang til dette og begynner å leke med det og få den typen av erfaring hvor de kan se om de har fått en måte å ta opp noen ytelsesproblemer? Kan de laste ned et ODS og spinne det på hypervisoren, Hyper-V eller bærbar PC, eller trenger de en dedikert maskin for å kjøre den på? Du skisserte arkitekturen før, men bare veldig kort, i løpet av et minutt eller to, hvordan ser det ut for startnivået bare for å bevise et konsept for eksempel?
Bill Ellis: Ja, så modellen vår er litt annerledes enn IDERA-verktøyene. Vi passer liksom mer inn i Embarcadero-scenariet hvor du ønsker å kontakte en av våre salgsrepresentanter. Vi vil bare diskutere med deg hva som er utfordringene, og da vil vi ganske enkelt, en av SE-ene, bli tildelt og i utgangspunktet arbeide gjennom installasjonen med noen. Vanligvis vil du ikke kjøre Precise på den bærbare datamaskinen. Du ønsker å ha en VM eller en server i datasenteret der applikasjonen bor, for å gjøre samlingene. Men vi vil hjelpe deg gjennom hvert trinn i det. Hvis noen er interessert i å forfølge det, vil du definitivt kontakte IDERA.
Dez Blanchfield: Noe av det andre som slo meg var at jeg mener, mye av det vi har dekket i dag, handler om å reagere på ytelsesproblemer. Men det så ut for meg at, og på levende miljøer som folk bruker dem, så som ditt første lysbildefremvisning, tar noen opp telefonen og sier: "Programmet kjører sakte, hjelp." Men det slo meg at under forhåndsutleie av applikasjoner eller oppgraderinger eller nye korrigeringer og reparasjoner, kan du gjennomgå en mengde kapasitetsplanlegging og stresstesting og få Presis til å se på hele miljøet og faktisk finne problemer før du til og med setter sluttbrukere på miljøet. Er det en brukssak du har sett før, eller som folk også gjør det, eller er det ikke en vanlig brukssak?
Bill Ellis: Absolutt, vi ønsker å bruke Precise i hele livssyklusen for applikasjonsutviklingen eller oppgraderingslivssyklusen. Precise tilbyr en skalerbarhetsvisning, det vil vise antall henrettelser som er lagt med responstiden. Hvis både antall henrettelser og responstid vokser sammen, skaler du selvfølgelig ikke, og du trenger å gjøre noe. Den typen ting har hjulpet enormt. Jeg tror det er litt mindre sant nå, men når folk begynte å sette produksjonsapplikasjoner på VMware, var de litt nølende og det var som om du vet det første de ville være: "Å, vi trenger å flytte dette til fysisk. ”Og hva vi faktisk kan gjøre er å vise hva ressursforbruket er, slik at du kan gjøre applikasjonen mer effektiv. På hvert trinn i applikasjonslivssyklusen vil du definitivt bruke Precise. Men jeg må si at produksjonen virkelig er der ytelsen betyr mest og Precise er rettet mot 24/7 produksjonsovervåkning, og at du virkelig ikke vil kjøre produksjonsapplikasjoner uten synlighet.
Dez Blanchfield: Absolutt. Et annet raskt spørsmål bare om den spesifikke dybden testen, innvandring, UAT og så videre - jeg mener, det er flott å ha dette verktøyet, og jeg ser for meg at apputviklere absolutt ville elske å ha tilgang til dette gjennom livssyklusene i utviklingslivssyklusen. . Med de mer komplekse arkitekturene du ser nå, så vi har flyttet fra dedikert tjeneste til virtualiseringer og virtualisering, flytter vi nå til en slags, du vet, adopsjon av outsource til cloud hosting, og vi ser også en overgang til containerisering. Har du sett mange mennesker distribuere dette og modellere den slags regioner eller soner, så noen kan ha det - og i Australia har vi et veldig stort spørsmål rundt personvern, og jeg vet at i Europa er det samme og jeg tror det blir mer en sak i USA hvor data som er i stand til å identifisere meg personlig, ofte må være i et sikrere miljø til det faktiske applikasjonslaget til nettlaget. Og så har vi disse distribusjonene nå der folk kan oppbevare databasen og applikasjonsmaterialene sine internt, men de kan legge websjiktet sitt og leveringsslutt og applikasjon og så videre i en skyleverandør som Azure eller Amazon Web Services og programvare . Hvordan fungerer det med din vanlige distribusjon? Er det slik at du nettopp har fått et annet sett med samlere i regionen, og at de bare samler litt mer? Hvordan ser det ut i den presise verdenen i dagens slags bimodale tilnærming til å drive IT av gamle arv på ett sted, og varene dine er noen ganger i skyen?
Bill Ellis: Ja, så vi støtter et blandet miljø. En ting å vurdere er at det er forskjellige kontrakter med skyleverandørene. Noen av dem vil ikke tillate noen form for agent eller noen form for utvendig overvåking i skyen. For å installere og overvåke med Precise må du ha en type kontrakt som tillater den typen tilgang. Det er definitivt noen begrensninger som vi noen ganger må arbeide gjennom, og det er derfor viktige kriterier du vurderer når du antar at du først signerer kontraktene og deretter og / eller hvis du trenger å implementere Precise.
Dez Blanchfield: Ja, jeg har sett en rekke tilfeller der til og med tradisjonelle databasemiljøer hvis du anskaffer det som en del av tjenesten, spesielt med slike som Azure, mens du anskaffer slike som HDInsight eller SQL som en service, som plattform, kan de vanlige verktøyene dine bare dykke så dypt fordi de ikke er så opptatt av å se på hva som er under panseret. Og slik ender du opp med et visst nivå eller dybde som du kan overvåke til og plutselig du bare ikke kan se bak den magiske gardinen. Er selvbetjening en ting? Er dette tradisjonelt noe som vil fungere i et nettverksoperasjonssenter der teknisk team, folket under CIO bare vil få tilgang til, eller er dette også noe du kan gi tilgang til sluttbrukere? Kanskje ikke nødvendigvis resepsjonen og tradisjonelle HR- og finansfolk, men mer kyndige brukere som driver med, du kjenner, som for eksempel dataforskere, aktuarer, statistikere, folk som driver med veldig stor arbeidsmengde. Er det slik at de kan få tilgang til en slags tilgang til selvbetjening for å se hva som skjer når de kjører disse tunge spørsmålene og hvor smertene kommer slik at de kan sortere hvordan arbeidsmengden deres løper?
Bill Ellis: Det er ganske god sikkerhet i Precise, slik at du kan konfigurere brukere som har forskjellige tilgangsnivåer. På helt grunnleggende nivåer gir bare instrumentpanelene tilsyn. Og innen noen, vet du, hvis noen ønsket å gå inn i ekspertgrensesnittet, kan du på en måte begrense hva de kan se og hva de kan gjøre. Og på en måte å sirkle tilbake til det forrige spørsmålet ditt, som du vet, i helsevesenet har du alle HIPAA-lovene, og så er det definitivt noen betraktninger, og det er faktisk noen distribusjonsalternativer slik at vi kan jobbe med det i begge miljøer. En ting å ta i betraktning med dataene du har sett i denne presentasjonen er at det hele er metadata om ytelse, ikke innholdet i tabellene, du vet, og det er virkelig, det kommer ikke til å komme inn på, slags bekymringer om personvern.
Dez Blanchfield: Ja, jeg likte det. Jeg hadde et eureka-øyeblikk om ditt fjerde eller femte lysbilde av skjermen, og jeg skjønte at du bare drar ytelse, vel, ikke bare, men du drar ytelsesdata, du drar ting, som sagt, metadata ut av de forskjellige nivåene i stabelen, du ser faktisk ikke på innholdet. Og jeg synes dette er en interessant ting fordi det er et av disse verktøyene der du enten kan distribuere det på kort sikt og se på hva som skjer i miljøet, men du trenger ikke ha tilgang til selve dataene. Du kan til og med se på hvordan mannskapene blir drevet. Det siste antar jeg bare raskt, og så vil jeg gi tilbake til Eric, så hvis du har et spørsmål, så få Rebecca til å pakke seg opp, nevnte du før at overhead er nominell, det er et tilfelle at det er til og med et merkbart overhead fra overvåkningssiden av ting og bare se på bakgrunnen, eller er det en så ubetydelig mengde overhead at det bare ikke er verdt å vurdere?
Bill Ellis: Ja, så jeg tror at databaselinjen er hver annen teknologi. På databasesiden er Precise ganske kjent for å slå det laveste omkostningen. På midterste nivå er det, du vet, det er en slags balansegang, du vet, det er ikke bare presis, det gjaldt alle, når det gjelder synlighet og overhead. Og en av tingene er at vi tilbyr en rekke sofistikerte verktøy for å kontrollere hva overhead er. Vi er designet for produksjon, og du vet, det er absolutt nyttig å nippe til så mange problemer i knoppen på utvikling og QA, men, du vet, det er ingenting som å vite hva som skjer i produksjonen.
Dez Blanchfield: Eric, overfor deg, har du noen endelige spørsmål?
Eric Kavanagh: Ja, jeg vil bare si at jeg synes du har gjort en god jobb med å påpeke at kontekst virkelig er nøkkelen, og det er nesten som om vi beveger oss mot denne tidenes tingenes internett, du vil ha alt instrumentert. Og jeg tror standarden nå i produksjonen er å gjøre det, som er gode nyheter, ikke sant? Fordi du vil være i stand til å hente informasjon fra alle disse forskjellige miljøene og sy alt sammen. Men jeg vil nok bare overføre det til deg for noen oppfølgende kommentarer. Det er det dere er fokusert på, gir et visuelt grensesnitt som noen analytiker, en IT-analytiker i hovedsak kan overvåke og analysere hva som skjer i dette komplekse miljøet og deretter finne ut hva de skal endre. For det er ikke bare et verktøy. Du må ha verktøyet, men du trenger den personen som kommer til å grave i detalj og finne svarene, ikke sant?
Bill Ellis: Ja, jeg ser det som å koke opp til toppen og prioritere hvor er det mest tilbakekjøpet, vet du? Hvis det viser seg at det er en annen situasjon fordi ikke alle problemer er i databasen. Hvis databasen er, vet du, ting kjøres på en tidel av et sekund, men på applikasjonsnivået tar ting tre sekunder, det er der den mest tilbakekjøpet er. Og så slags å være i stand til å isolere problemnivået og deretter hva som skjer i nivået for å virkelig fokusere på hvor tilbakekjøpet er. Det akselererer virkelig oppløsningen og optimaliseringen av applikasjonen, og den er så mye raskere og så mye bedre og så mye morsommere enn folk samlet seg til et konferanserom og sa: "Det er ikke jeg, det må være noen andre."
Eric Kavanagh: Det stemmer. Jeg så en flott meme forleden som sa noe som "Bli informert, ikke bare meningsfull." Du går inn på et møte, har du informasjonen, kan du peke på dataene. Det er nøkkelen, og vi kommer dit, takk og lykke. OK folkens vi skal gå videre og pakke sammen, men vi arkiverer alle disse webcastene for senere visning. Sjekk det gjerne når som helst. Vi lister opp alle webcastene våre nå, Hot Tech-serien og Briefing Room-serien på Techopedia.com, så hopp på nettet og sjekk disse menneskene. Med det kommer vi til å ta farvel. Takk for tiden din i dag, Bill. Takk til deg og alt ditt harde arbeid, Dez. Og vi snakker med deg neste gang, folkens. Ha det fint. Ha det.
