Av Techopedia Staff, 6. september 2017
Takeaway: Vert Eric Kavanagh diskuterer PeopleSoft performance management med Matt Sarrel og Bill Ellis i denne episoden av Hot Technologies.
Eric Kavanagh: OK, mine damer og herrer. Hei og velkommen igjen. Det er en onsdag klokka 4 øst, og de siste årene, det er ment i denne verdenen av IT og big business og data, er det tid for Hot Technologies. Ja, jeg heter Eric Kavanagh. Jeg skal være din moderator for dagens begivenhet.
Vi skal snakke om systemene som driver virksomhet, folkens; vi snakker om PeopleSoft, hvordan du kan administrere ytelsen til komplekse miljøer. Jeg liker alltid å nevne at du spiller en stor rolle i disse hendelsene, så vær ikke sjenert. Still spørsmålet ditt når som helst; Du kan gjøre det ved hjelp av chatvinduet eller spørsmål og svar - uansett hvordan det kommer seg gjennom. Jeg vil gjerne høre hva du vil vite, og det er den beste måten; du får den beste verdien for din tid. Vi arkiverer alle disse webcastene for senere lytting, så bare husk på det.
Hvis systemer kjører sakte, bare husk hvordan livet pleide å være. Dette bildet er faktisk fra 1968, takket være en dame som heter Danelle, og jeg må si at dette virkelig er en sterk påminnelse om hvor mye ting som har endret seg. Verden har blitt bemerkelsesverdig mer sammensatt, og selvfølgelig har forretningsbehov og brukeropplevelse en tendens til å gå hånd i hånd. Men i disse dager er det litt av en frakobling. Som vi ofte sier, er det et misforhold, og faktum er at forretningsfolk alltid vil ha ting raskere og raskere, IT-team som må levere er de som blir satt under press for å få jobben gjort, og det er en intens verden der ute.
Jeg må si, konkurransen har varmet opp overalt. Hvis du bare ser på en hvilken som helst bransje, kan du se at det er stor utvikling i disse dager - Amazon kjøper for eksempel Whole Foods. Du kan være trygg på at dagligvarebransjen tar en hard titt på den. Vi ser dette overalt, så det er virkelig pålagt bedriftsledere å sørge for at de finner ut hvordan de skal - og her er buzzword i disse dager - omforme seg digitalt, hvordan de kan bevege seg utover det gamle sentralbordet til mye mer nye og robuste systemer. Det er det vi skal snakke om i dag.
Et av problemene som står overfor mange organisasjoner, spesielt de som har eksistert en stund, er disse arvsystemene. Det er en gammel IBM-hovedramme fra tilbake på dagen. Det er gamle systemer overalt. En av vitsene er at et arvsystem er et system som er i produksjon, noe som betyr at øyeblikket det går i produksjon, teknisk sett er det et arvsystem. Det kommer alltid til å være nye måter å gjøre ting på.
Og det er noen veldig interessante utviklinger de siste årene om å finne måter å praktisk talt forene systemer for ikke nødvendigvis bare å forbedre ytelsen til ett system, men for å finne en måte å lage en slags avlegger eller en off-loading taktikk for å håndtere ytelse på andre måter. I dag skal vi snakke mer om hvordan du kan forbedre ytelsen til et system som PeopleSoft, som selvfølgelig er utrolig komplisert. Men når det gjøres bra, når det er lastet, når det blir implementert, når det styres bra, kan det gjøre fantastiske ting. Men når det ikke er klart godt, er det når du har alle slags problemer.
Så hva skjer? Du må være realistisk om ting og i ethvert miljø, hvis brukere ikke får det de vil, før eller siden går de til skyggesystemer. Det skjer hele tiden. Skyggesystemer kan være veldig produktive, de kan hjelpe folk med å få jobben gjort. Men selvfølgelig er det mange problemer. Helt klart i hele området med overholdelse og regulering er skyggesystemer et stort nei. Men de er der ute, og jeg tror det er viktig å huske at systemene dine, hvis hovedsystemet ditt ikke fungerer raskt eller ikke fungerer effektivt, før eller siden kommer det til å bli løst løsninger og at de midlertidige løsningene kan være veldig vanskelige å oppdage, de kan være vanskelig å solnedgang fordi de ender opp med å være kritiske for virksomheten. De kan være vanskelige å integrere, så bare husk at de er der ute, og det er bare en annen grunn til å forbedre ytelsen.
Nylig har jeg hørt om dette uttrykket, og jeg må kaste det der ute: "hastighetens tyranni." Jeg tror bare det å høre at du sikkert vet hva jeg snakker om og hva som skjer i de fleste organisasjoner, er at arbeidsmengden når en kritisk masse, og folk gjør så mye de kan, og det blir veldig vanskelig å endre noe. Du ender opp med å lide av “tyranni av presserende” - alt må gjøres med en gang. Vel, oppgradering av et system skjer ikke med en gang.
Alle som noen gang har levd gjennom å oppgradere en ERP fra en versjon til en annen versjon, vet at det er en relativt smertefull prosess, så vær bare oppmerksom på dette: Hvis du ser det i organisasjonen din, gjenkjenner den. Forhåpentligvis kan du komme gjennom til noen, eller hvis du er en senior person som en CIO eller CTO eller CEO, kan du erkjenne at dette er et veldig farlig scenario fordi når du først er bak den åtte ballen, er det virkelig vanskelig å komme seg ut bakfra åtte ball.
Det er som hele maratonundersøkelsen: Hvis du havner langt etter i et løp av noe slag og alle er foran deg og dere fremdeles løper, vil det bli veldig vanskelig å ta igjen hvis du faller for langt bak. Så bare pass på det og husk det.
Og med det skal jeg overlevere det til Matt Sarrel for å gi oss litt innsikt om hvordan vi skal håndtere kompleksitet med PeopleSoft-miljøer. Matt, ta den bort.
Matt Sarrel: OK, takk, Eric. Hei alle sammen. Og så, la oss se, så begynner jeg med å fortelle deg hvorfor jeg tror jeg er den rette personen som snakker med deg om å styre prestasjoner. Så jeg har 30 års erfaring innen teknologi. Jeg liker å si at jeg jobbet meg opp gjennom å være en hands-on, nettverksadministrator, direktør for IT, VP for engineering ved et par oppstarter. Så gjorde jeg denne overgangen til å bli teknisk direktør på PC Mag. Det er bildet mitt der, men i utgangspunktet ser jeg ut som en liten gutt.
Og så fortsette og være journalist i en rekke forskjellige publikasjoner som eWeek og InfoWorld, være analytiker på Gigahome, samarbeide med Bloor Group og også drive konsulentvirksomhet. Og der er meg: Dette bildet til venstre er slik jeg ser ut nå. Dette bildet i midten er liksom der jeg er veldig fornøyd - i et rom fullt av ledninger og blinkende lys, og hvor det er kaldt - det må være veldig kaldt og alle andre må være ukomfortable for at jeg skal føle meg komfortabel temperatur- klok. Og det er kontaktinformasjonen min, hvis du har spørsmål om oppfølging.
Jeg vil stille scenen her og bare snakke om fremføring, som Eric snakket om. Vi har nå kommet inn i denne verdenen der brukere har denne forventningen som er satt av forbrukerapper og nettsteder. Og folk pleide å være villige til å gå på jobb og sitte der og vente på systemene sine fordi det var det de trengte, og nå er ikke folk villige til å sitte der. Så det er et spørsmål om de vil at denne motorsykkelen skal fly rundt banen. De vil sannsynligvis ikke at fyren skal sykle og bære datteren sin på skolen. Men hva skal du gi?
Og det er vanskelig fordi - egentlig var jeg litt raus med dette til tre sekunder så bra - folk vil ha en umiddelbar respons også, og de vil ha tilgang fra hvor som helst. At hvor som helst kan være hvor som helst i bygningen din eller på campus, eller det kan være hvor som helst i verden når som helst, avhengig av hvor bra virksomheten din fungerer. Og jeg antar at det jeg bygger opp til, er at når vi snakker om ytelse, er det viktig å tenke på ytelse fra brukeropplevelsens vinkel.
Det er viktig å definere resultatmål før måling og innstilling. Jeg har dette bildet av en tuner og deretter en tuner. Den faktiske mannen som er en mottaker, han trenger å vite hva han stemmer for, eller det er ikke noe poeng å faktisk legge hendene på pianoet og stille det inn. Så å definere mål på forhånd, det vil slags holde det ekte i stedet for å tilpasse mål til å passe til dagens situasjon. Det er viktig å overvåke beregninger over tid og innse hvordan systemer endres med brukerbelastning applikasjonsytelse, som påvirkes av ressursscener og bruksmønstre.
Det er alltid viktig å korrelere alt dette sammen med en brukeropplevelse eller støttehendelser, etablere en grunnlinje for ytelsen du forventer å kunne levere, og når du nærmer deg avvik fra den grunnlinjen, har du proaktive varsler slik at du kan ta grep før vi treffer “fail whale” -status. Og du vet at det krever muligheten til å kunne bestemme og løse årsaken til ytelsesproblemet veldig raskt og enkelt. Og igjen, dette er jo tidligere, jo bedre, ikke sant?
Vi vet at fra tidligere historie med å se på utviklingsinnsats, jo tidligere du kan finne og fikse ytelsesproblemer, jo bedre er du. Hvis du venter til all koden eller systemet ditt er i live for å starte ytelsestesting eller for å begynne å avdekke problemer, vil jeg ikke si at det er for sent, men igjen, nå er du fyren som har fått en dårlig start i maraton og nå spiller du innhenting i stedet for å hoppe rett ut og komme videre. Så hvordan gjør du dette? Forutser du gjennomsnittet og toppbelastningen din?
Og du går foran og du størrelse på dine fysiske servere eller virtuelle servere eller skyforekomster eller containere og containerressurser og deretter kjøre et bevis på konsept og kjøre en pilot? Dette er tidspunktene dette er, slutten på hvor du ønsker å fange noe, selv om du fremdeles er bedre med å fange den i produksjonen enn å ignorere den i produksjonen. Men når du er i piloten, burde du allerede ha etablert metodikk og prosedyrer rundt kontinuerlig overvåking og forbedring.
OK, så mange selskaper - vi snakker om digital transformasjon. DevOps, i DevOps-revolusjonen spiller en enorm rolle i den digitale transformasjonen. Og dette er en ende til ende prosess som virkelig aldri stopper. Så det er som de to hendene som tegner hverandre, og dette er gode ting. Det er en uendelig sløyfe mellom disse to hendene på plan, kode, bygge, teste, slippe, distribuere, betjene, overvåke, tilbake til plan. Det mater seg selv og vi automatiserer det slik at det går raskt. Det skaper en feedback-loop for produksjonsovervåking og bruker den til proaktivt å avdekke ytelsesproblemer og fikse dem før de påvirker hele brukerbasen.
Og en annen ting, nå som du har fått det til, IT-utviklere og driftsmedarbeidere som beveger seg veldig raskt og justert, kan du også enkelt samkjøre denne innsatsen med forretningspersonalet også. Enterprise softwareytelse er et komplekst dyr. Man kan likne det med et fotballag som sitter foran en tavle og tar retning, og alt fungerer hver for seg og alt fungerer sammen. Jeg tenker alltid på det som den gamle historien om da jeg fikk min første bil og fikset en ting. Jeg fikset klimaanlegget, og det som skjedde var at resten av kjølesystemet sviktet. Så du har dine smertepunkter og alt går sammen og gjør justeringer. Du må organisere alt på en slik måte og bygge prosessene slik at når du gjør endringene dine, forstår du hvordan alt påvirker alt annet.
Og vær også forsiktig og dobbeltsjekke. Test, ugyldig, implementer. Og igjen kommer vi til dette problemet med å bygge kontinuerlige overvåkings- og ytelsesforbedringsprogrammer. Og dette er faktisk min siste lysbilde. Mens vi snakker om denne kompleksiteten, og det er en vakker kompleksitet akkurat som innsiden av denne klokken, har vi så mange bevegelige brikker til PeopleSoft. Hver ting påvirker alt annet helt opp og ned i bunken. Og det er så mange forskjellige steder hvor du kan se etter nøkler til ytelsesproblemer at du veldig lett kan gå tapt uten riktig verktøy og uten riktig prosess. Og igjen på alt, i mange tilfeller, det jeg tror vi har lært, er at du kan feilsøke infrastruktur, men den enorme variabelen kommer til å være din tilpassede programkode. Og det å ha de riktige prosessene på plass for testing og kontinuerlig forbedring av programkoden, er det som kommer til å være viktig.
Og så er det slutten på min del, og jeg vil overføre dette til Bill.
Eric Kavanagh: OK, Bill, la meg gi deg nøklene til WebEx her. Jeg liker den vakre kompleksiteten - det er hyggelig. Du hadde et par virkelig gode sitater der, Matt. OK, Bill, ta den bort. Gå til "hurtigstart" hvis du vil dele skjermen. Alle dere.
Bill Ellis: Takk, Matt, og takk, Eric. Bare for å bekrefte, kan dere alle se skjermen min nå?
Eric Kavanagh: Ja, ja.
Bill Ellis: Så vi skal snakke om IDERAs produkt Precise for PeopleSoft og synligheten de kan gi for å hjelpe deg å lykkes med å administrere den komplekse applikasjonsstabelen. En måte å plassere vanskeligheten på er at én applikasjon, minimum seks teknologier, mange sluttbrukere, og det gjør det veldig vanskelig å svare på selv enkle spørsmål. Har en sluttbruker et problem? Hvem er sluttbrukeren, hva gjør de, hva er årsaken?
Det vi vanligvis ser er denne situasjonen - og dette kan gjelde for PeopleSoft så vel som andre applikasjoner eller PeopleSoft som samhandler med andre applikasjoner - er innenfor datasettene, eller det kan være skyen i disse dager, en sluttbruker bryr seg ikke egentlig om den kompleksiteten. De vil bare fullføre transaksjonen, tilnærminger, lageroppslag, rapporteringstidskort, de typer ting. Hvis ting er tregt eller ikke tilgjengelig, er vanligvis alle disse intelligente, velmenende menneskene uvitende til sluttbrukeren klager.
Det er et slags synlighetsgap akkurat der, og det som kan skje er at det kan starte en tidkrevende og frustrerende prosess der folk kan åpne et verktøy og de ser på, dessverre, bare en undergruppe av applikasjonsstabelen. Så slags vanskeligheter med å svare på de grunnleggende spørsmålene gjenstår.
Og mange ganger kan det være et problem, og du vil gå til WebLogic-administratoren og han vil si: “Vel, hukommelsen, søppelsamlingene ser alle bra ut. Jeg tror virkelig ikke det er WebLogic. ”Du går til DBA-administratoren og de sier:“ Vel, databasen, den kjører akkurat som den var i går. De ti beste ser bra ut. Kanskje lagringsadministratoren slo deg med noen beregninger som I / Os per sekund eller gjennomstrømning, som er ramme-nivåmålinger og kanskje ikke reflekterer over den aktuelle applikasjonen din, mye mindre databasen eller en bestemt prosess. "
Og så har de alle disse beregningene som ser ut til å vise at problemet er andre steder, men likevel har denne sluttbrukeren et problem eller har rapportert et problem, men hvordan kan vi løse dette problemet på en bedre måte? Og den bedre måten, den nøyaktige måten - eller dette er en måte vi tilbyr - er å måle brukertransaksjoner som starter i nettleseren gjennom nettverket, på webserveren, i Java Jolt, i Tuxedo, i databasen inkludert DB2 og så til slutt til lagring.
Og hva dette viser er at den totale tiden sier: "Vel, hvem har et problem?" Og så kan vi identifisere sluttbrukeren etter hvordan de logget på PeopleSoft, og vi kan også fange via Tuxedo-oversettelsen hva PeopleSoft-panelene kjører.
Tidspunktene blir så ført inn i et historisk depot som vi kaller performance management-databasen, og dette blir et enkelt stykke musikk som i stor grad forenkler hvem, hva, når, hvor, hvorfor. Precise inkluderer også anbefalinger. Trolig er det viktigste fordi vi fanger opp all informasjonen hele tiden - både på teknisk IT-stabsnivå - du kan måle før og etter. Så du kan ta med måling ved måling eller Six Sigma til hele ytelsen.
Så la oss ta en titt på “en dag i livet.” For det første kan det hende du åpner opp skjermbildet Presis varsling, og det er her du kommer til å varsle om tidlig. Det aller beste varselet er at du har aktivitetsvarsler. Så det er brukere som utøver transaksjoner, og vi oppfyller i utgangspunktet ikke våre SLA-er. På samme måte har vi en status når tilgjengelighet - og dette sier i utgangspunktet at en del av applikasjonsinfrastrukturen vår er utilgjengelig - slik at vi kan bore inn og vi kan faktisk se hvordan Tuxedo forekommer i formen, og du kan faktisk se at en av forekomster er nede. All aktivitet blir presset til denne ene forekomsten, og den må håndtere det. Vi har i utgangspunktet laget en flaskehals.
Nå, bare som en ting, for aktiviteten som kjører på dette, kan du faktisk begynne å komme inn i funn som, selv om vi har dette overordnede infrastrukturproblemet, det er måter å forbedre prosesseringseffektiviteten innenfor akkurat denne JVM for WebLogic. Og det er her det virkelig er en viktig ting: Mange ganger beveger folk seg som en sky, og de sier: "Hvor mye CPU og hvor mye minne trenger du?"
Vel, den andre siden av den mynten kjent som kapasitet er prosesseringseffektivitet. Hvis jeg bruker mindre minne, hvis jeg bruker mindre CPU, trenger jeg rett og slett ikke så mye. Og slik som Matt sa tidligere, er alt slags beslektet. Det jeg kan gjøre er nå å åpne PeopleSoft-transaksjonsskjermen, og på skjermen er y-aksen responstid, x-aksen er tiden over dagen.
Vi har en stapeldiagram som viser klienttid. Det er faktisk nettleseren, webserveren. Den grønne er Java-tid, den typen rosa er smoking, den mørkeblå er databasetid. Denne profilen skjedde ikke av seg selv; det skjedde på grunn av de spesielle PeopleSoft-panelene - de hadde blitt henrettet, og de blir presentert for deg ved svartid. Det er faktisk en timing for hvert trinn i applikasjonen, så vel som en stabelstangdiagram som viser applikasjonen her panel for panel. Jeg kan også gå inn og finne en bestemt bruker eller rangere brukerne mine.
Denne skjermen lar meg spesifisere en bestemt bruker ved påloggingsnavn. Tenk på hvor bemerkelsesverdig eller hvor kraftig dette er. Mange ganger handler det ikke bare om infrastrukturen og hvordan den er satt opp, det er hvordan sluttbrukere bruker systemet. Det kan hende du har en ny utleie, eller noen har en ny jobbfunksjon: Den vet kanskje ikke hvordan du bruker applikasjonen riktig. Dette kan faktisk bidra til å identifisere treningsmuligheter.
Den andre siden av mynten er hvis jeg kan fokusere på en bestemt bruker - her ser jeg på den brukeren i de spesielle transaksjonene og responstiden de opplevde - jeg kan adressere brukeropplevelsen til en bestemt bruker direkte bruker. Det handler ikke lenger om generiske beregninger på systemnivå, det handler om sluttbrukeropplevelsen og det er veldig kraftig. Deler av miljøet ditt vil sikkert være interne, HR osv. Det kan være andre deler som kunden står overfor. Uansett vil du gi den beste og mest produktive kundeopplevelsen som mulig.
Nå for et bestemt panel, kan jeg gå inn og bore inn for å svare på spørsmål. Så dette er en slags dypdykk som vi kan gjøre for å avdekke hva som skjer, og du kan gjøre dette dypdykket før du ringer en sluttbruker, eller hvis en sluttbruker hadde ringt deg, ville du kunne sette i gang en prosess for å si: "Vel, hvor er egentlig årsaken?" Og det kommer ikke til å være som en CPU-bruk og en overstyring, det kommer til å være den applikasjonskoden de bruker.
La oss gå inn og se på den innholdsstyringen, og du kan faktisk se en analyse av den transaksjonen: å starte nettleseren, inngangspunktet til webserveren i Java Jolt, og vi viser faktisk kode som kjøres ned i Tuxedo-panel, til slutt til SQL-setningen der Precise avslører teksten til SQL-setningen som utføres av dette bestemte PeopleSoft-panelet.
Alle som vi snakker med har verktøy, men det de ikke har er kontekst. Å koble punktene eller følge transaksjonen fra nettleseren helt til SQL-setningen er kontekst. Hva dette gjør for, som DBA, er snarere enn å se på ting på et forekomst eller et databasenivå, kan jeg nå undersøke på et SQL-utsagnsnivå.
Så jeg kan si: "Vel, hva er flaskehalsene for en individuell SQL-setning, " og dette er ekstremt kraftig. Vær oppmerksom på at denne transaksjonen ikke kan løpe raskere enn SQL-setningen, og at alle viktige forretningstransaksjoner samhandler med journalsystemet. Databasen, som den eller ikke, er grunnlaget for ytelse, og hvis jeg kan være så kornete at jeg fokuserer på individuelle SQL-setninger som er viktige for en forretningstransaksjon, kan jeg virkelig ta spillet mitt til neste nivå.
En annen ting du kanskje legger merke til her, er at det er en beregning av prosentvis bidrag som Precise gir. Nettleseren i seg selv er faktisk en betydelig del av applikasjonsbunken. Du har JavaScript-utførelse, du har gjengitt tid, du har sidekomponenter, GIF-er, JPEG-er. Og du opplever faktisk at applikasjonen din kan oppføre seg veldig annerledes under Chrome versus IE og forskjellige versjoner. Precise vil kunne vise det også for deg, og det kan være tider hvor det faktisk er en flaskehals eller en stridighet i nettleseren som kan forårsake slike ting som skjermen fryser.
Å være i stand til å identifisere som gjør at IT ikke kan bjeffe opp feil tre, men å adressere grunnleggende årsak til forskjellige problemer som kan komme opp. Det jeg nå kan gjøre er for en bestemt SQL-setning. Jeg kan deretter analysere nøyaktig hva som skjer på det SQL-utsagnet. Så her har vi falt til databasen ekspertvisning.
Noe av det som skiller Precise på databasenivå, er at vi prøver på sub-sekund basis. Dette i sammenligning med våre konkurrenter som bare ser en gang hvert 10., hvert 15. minutt. Slik at nivået av granularitet, oppløsningsnivået er størrelsesorden bedre enn våre konkurrenter.
Og igjen, siden databasen er en del av grunnlaget vårt, vil vi la din DBA virkelig ta ytelse til neste nivå. Så jeg kan se at denne SQL-setningen faktisk brukte 50 prosent hvis det var tid til å øve på å få tilgang til det lagrede delsystemet, 50 prosent av tiden med å bruke CPU. Klikk på tune-knappen, så kan jeg gå inn og bore ned på utførelsesplaner og nøyaktig hva som drev det bruksmønsteret.
Nå er et pristilbud fra en av våre kunder - hvis de ikke var i Oracle Shop, brukte de et Oracle-verktøy som heter OEM og OEM er virkelig slags database eller forekomstfokusert - er det DBAs som stadig ser på hva er topp 10-listen? Men med Precise er vi i stand til å koble prikkene til de individuelle SQL-setningene og slik at granularitet gjør at DBA virkelig kan stille seg på transaksjonsnivået og ikke bare på det mye høyere databasenivået.
Det andre poenget som var veldig viktig for denne kunden er at Precise, ved å oversette det som er en komplisert URL-adresse til et PeopleSoft-panelnavn - hvis jeg er i IT og jeg kan snakke om tree manager, content manager, en bestemt HR-side, på den måten vet den personen jeg prøver å hjelpe, at jeg faktisk ser og forstår hva de ser på fordi det ikke lenger er disse hieroglyfene, det er navnet de er kjent med.
Et av spørsmålene vi blir stilt - det virker som om det hele tiden er, så jeg trodde jeg bare ville slags proaktivt svare på spørsmålene - hvordan i all verden fanger du den PeopleSoft bruker-IDen? La meg slags gå gjennom trinnene. Her er en PeopleSoft påloggingsskjerm. For å få tilgang til den, måtte jeg navigere til webserveren min, og dette skjermbildet vises. Når applikasjonen er instrumentert med Precise, inneholder denne skjermen faktisk et Precise script og jeg kan avsløre ved å gjøre et høyreklikk, se kildekode. Og dette vil faktisk vise meg koden som utgjør den underliggende siden og her oppe i siderammen er faktisk det nøyaktige for webkoden, og dette lar meg fange påmeldingsskjermen, IP-adressen, nettlesertypen, en helhet haug med informasjon om gjengivelse og ekte sluttbrukeropplevelse. Og så når jeg legger inn brukernavnet og klikker på, kan Precise måle det jeg gjør.
Jeg åpner opp, går til tresjefen, jeg vil gjøre en søkeoperasjon, fyll ut feltet og jeg klikker på søk. Et resultatsett blir presentert for meg, så jeg har tydelig krysset hele applikasjonsbunken helt ned til databasen. Hvordan viser Precise dette? La oss ta en titt. Åpne opp Presis, jeg går inn, jeg kan se aktiviteten, jeg kan klikke på aktivitetsfanen som kommer til å få frem dette skjermbildet. Dette er de ikke oversatte nettadressene. Jeg kan vise brukerne, og her er bruker-IDen min som jeg nettopp logget på, og her er min aktivitet.
Du kunne se at jeg brukte Firefox versjon 45 for å få dette opp. Jeg utøvde applikasjonen 12 ganger og forlater er i utgangspunktet når noen forlater en webside før det fullstendig gjengis, noe som antyder et forretningsspørsmål. Så det var slik vi klarte å hente sluttbruker-IDen. Det er veldig hyggelig, folk setter veldig pris på når du vet nøyaktig hva som foregikk.
Nå vil vi skifte gir litt rart. Vi så på transaksjonen senere. Vi gjorde et dypt dykk på en bestemt transaksjon og så på SQL-setningene. Nå vil jeg skifte gir og se på noen av de andre teknologiene i PeopleSoft-applikasjonsstabelen som starter med WebLogic.
Og her er en WebLogic forekomst, og du kan se aktiviteten over tid. Du har en økonomirapport. Det forteller meg rett utenfor flaggermusen, minnet brukes nesten maksimalt. Noe av det vi finner er at folk flest kjører hele applikasjonsbunken, eller i det minste en del, under et delt miljø, veldig ofte er det VMware. Du må liksom balansere hvor mye ressurser du ber om og hvor mye du trenger. Du vil ikke være en ressurshog. På samme måte vil du ikke sette en behandlingsbegrensning ved å ikke be om nok minne i dette tilfellet.
Konfigurasjonen er også viktig for ytelsesstyring. Så vi kan faktisk komme inn i minnesøppelsamlingen og alle JMX WebLogic-tellere slik at jeg vet nøyaktig helsen til WebLogic-formen min.
Nå inn i smoking. Tuxedo i mange butikker er en slags svart eske, og det er en veldig viktig del av PeopleSoft. Det er slags lim som holder alt sammen, og derfor tenker jeg nesten på det som en utvidelse av operativsystemet. Det er noe du bruker og konfigurerer veldig nøye. Forresten - dette er en liten sidebeskjed - i åpningskommentarene hadde Eric nevnt “the tyranny of urgency”, og jeg tror at det virkelig kommer til spille når PeopleSoft-butikker vurderer å flytte fra det klassiske brukergrensesnittet til det flytende brukergrensesnittet fordi du oppdage at du er bak kurven på grunn av måten væske-brukergrensesnittet utøver PeopleSoft-miljøet.
Nå har du problemer på WebLogic, på Tuxedo, i databasen og på lagringen her bare fordi HTML5 gjør en enorm mengde meldinger. Det er sannsynligvis minst 10 ganger hva det klassiske brukergrensesnittet gjør, og at ekstra meldinger betyr ekstra trafikk. Så konfigurasjonen av Tuxedo må endres for å imøtekomme den ekstra trafikken. Et par ting med dette skjermbildet er over på høyre side. Vi har overtidsgrafer for vektet responstid, gjennomsnittlig responstid og utførelsesantall.
Her over har vi informasjon om alle Tuxedo-domenene i miljøet. Vi delte ut tjenester, brukere, serverprosesser samt IP-er. Jeg kan flytte dette til utførelsestelling og presentere de i synkende rekkefølge, slik at jeg kan se hva som blir henrettet flest ganger. Jeg kan også bla ned for å avsløre domenene; de fleste har flere domener i omgivelsene sine, for i utgangspunktet å spre aktiviteten, og jeg er i stand til å angi SLA-overholdelse, derfor varsler Tuxedo-laget.
Hvis du står i kø, har du forskjellige problemer som oppstår på grunn av konfigurasjonen. Du typisk - fordi det er globalt av påvirkning - vil du vanligvis ikke gjøre endringer mens du er på farten. Du ønsker å gradvis øke systemet som en del av QA-prosessen som spretter tilbake til et punkt som Matt tidligere hadde gjort om å adressere ytelsesproblemer tidlig i prosessen. Det er mye bedre å ha konfigurasjonen riktig når du går til produksjon fremfor å gå til produksjon og finne ut at konfigurasjonen ikke samsvarer med bruksmønstrene. Jeg liker virkelig introduksjonen som Eric og Matt hadde gitt i dag. Jeg trodde at de virkelig var i mål når det gjelder utfordringene du står overfor å styre og utvikle PeopleSoft-miljøet.
Nå, jeg sa dette en gang før - jeg tror det er verdt å si igjen: Hver vesentlig forretningstransaksjon samhandler med databasen. La oss undersøke hvordan Precise kan gi tilleggsinformasjon. Her inne er en spesiell Oracle-forekomst. Den samme nøyaktige tilnærmingen som vi så - y-aksen er utførelsestid, x-aksen er tid over hele dagen, men nå er stapellstavediagrammer utførelsestilstander i Oracle. Dette viser oss hva som er behandlingsbegrensningene på systemet. Her nede er det faktisk en funnrapport som forteller meg at du har denne høye redo-loggbufferen.
Jeg ser også på denne utvalgte versjonen fra PSVersion. Det bruker faktisk mye ressurser. Forresten, fordi vi tar prøver og gir dette høye oppløsningsbildet av hva som faktisk skjer på systemet, kan du kanskje bli overrasket over hva som er de sanne ressursforbrukere på systemet ditt, fordi hvis du bare ser hvert 10. minutt, er det ikke kommer til å vise deg hva de ressursforbrukere er. Ved å vite hva den sanne ressursforbrukerne er, kan du faktisk adressere den sanne behandlingen på flaskehalser eller på systemet.
Nå har vi hoppet over til aktivitetsfanen, og dette er aktiviteten. Du kan se at vi ser på CPU, lagringsundersystem, applikasjonslåser, OS-venting, RAC, commit, Oracle-server, kommunikasjon og internt aggregat sammen. Dette er y-aksen, dette er den totale utførelsestiden.
Her nede er SQL-setningene som kjørte denne profilen, og en av tingene du ser er disse lave latenstidene - to millisekunder, men med nesten 4500 henrettelser betyr at SQL-setningen faktisk er den viktigste ressursforbrukeren på systemet ditt, og det er bra å vet. Den venter heller ikke på en lås eller venter. Den bruker CPU 100% av tiden. Det betyr ikke at det ikke er ting jeg ikke kan gjøre med det. Det er mange ting jeg kan gjøre med det hvis jeg vet hvilke SQL-setninger og objekter som nås. Og så er dette noen av måtene vi kan hjelpe.
Nå her nede er det denne drill-down, og dette kan sette oss i sammenheng med de individuelle PeopleSoft-programmene, og hvert av disse programmene tjener slags et annet formål innen PeopleSoft. Du kan faktisk begynne å adressere på databasenivå hvordan applikasjonen brukes.
Og hvis jeg velger et bestemt program, kan jeg deretter isolere SQL-setningene som det programmet sendte inn, slik at jeg kan være veldig applikasjonsfokusert snarere enn databaseteknologifokusert når jeg i utgangspunktet ser og ser på databaseoptimalisering og database konfigurasjon. Jeg vil bare gjøre dette oppmerksom på deg. Ofte er mange store organisasjoner delt inn i infrastruktur-DBA-er og applikasjons-DBA-er. Presis, ved å vise applikasjonen så vel som ressursforbruket, er vi faktisk i stand til å bygge bro over gapet, og denne løsningen er nyttig for begge typer opp-DBA-er på systemet.
Nå, denne delen virkelig er vår vise frem hva vi kan gjøre på databasenivå. Og det som skjedde her er at vi hadde en skjermfrysing, det var et valg fra PS_Prod, og det vi gjorde var å klikke på denne innstillingsknappen, og hva dette gjør er at den bringer oss inn i dette SQL-arbeidsområdet. Nå, for dere mennesker som ikke er DBA-er, kan dette ikke se veldig spennende ut. For folk som er DBA-er, kan du synes dette er ganske spennende. Det vi viser her, er varigheten av denne spesielle SQL-setningen kontra endringer i systemet. Og dette viser onsdag, torsdag, fredag, varigheten er omtrent 2/10 av et sekund. Lørdag og søndag fungerer ikke dette selskapet - heldige dem. Kommende mandag skjedde det en endring: Tilgangsplanen endret. Den nye tilgangsplanen er plutselig her oppe. Det er faktisk treg nok, det resulterer i en skjermfrysing.
Hvis jeg nå er en DBA, trenger jeg tilleggsinformasjon for å vite den virkelige grunnårsaken. Jeg trenger å vite hvilke valg av databaser som er laget. Så Precise tilbyr denne sammenligningen som viser utførelsesplanen som var rask og effektiv når ting kjørte bra, samt utførelsesplanen som var treg og ineffektiv. Dette filterforbindelsen er vanlig for DBAer som kjører PeopleSoft. Det filteret gjør er at det ser ut for hver rad i ett bord, det ser på hver enkelt rad i sammenføyningstabellen - som tar mye CPU. Det er ekstremt ineffektivt fordi det ikke er noen filtrering av å bare se på delmengden av rader som er nødvendig, men av SQL-setningen og at ineffektiviteten resulterer i tregere utføringstid. Derfor bremser de til slutt PeopleSoft-panelet i skjermfrysing og Precise klarte å komme til den sanne grunnårsaken som du aldri ville vite om med mindre du hadde et verktøy som avslører applikasjonskoden, SQL-setningene og så videre.
Det var liksom et dypt dykk. Vi skal nå trekke utsikten opp til 10.000 kvadratmeter utsikt over instrumentpaneler. I Precise er dashboards egentlig ikke for det tekniske teamet - det er virkelig for deg å bruke til å dele informasjon med operasjoner, kanskje med applikasjonsteamet, kanskje med kommandoskjeden din. Og ett sett med dashboards kan vise PeopleSoft-paneler og klienttiden, slik at du vet hva sluttbrukeropplevelsen er. Et annet dashbord kan ha blitt konfigurert for operasjoner, og dette dashbordet kan se på har det vært noen varsler fryser? Vi har faktisk varsler på OS, nettet, WebLogic, smoking og databasenivåene. Ingen varsler her, gjennomsnittlig responstid. Du kan se at vi løper omtrent en tredjedel av sekundet. Her kan jeg faktisk se på infrastrukturen min, vise meg alle VM-ene i miljøet mitt, og jeg kan begynne å komme i prosessering, belastningsbalansering, og jeg kan også se på Tuxedo-domenene mine. Dette bestemte miljøet har seks forskjellige domener, og så kan jeg se disse domenene, og jeg kan faktisk komme inn på nettbalansering.
Nå er Precises historiske depot som PMDB, databasen for ytelsesstyring, har mange metrikker. Og noen ganger vil noen vite om tilgangstallet for nettleseren, eller du kan gjøre tilgangstall etter nettlesertypen eller ytelsen etter nettlesertypen. Det er en hel haug med ting som kan gjøres for å gi ytterligere synlighet på systemet ditt.
Her, denne, ser vi faktisk på WebLogic minnebruk, og du ser dette fine sagtannmønsteret, minnebruken. Der er søppelsamlingen, den henter un-referanser. Den går opp igjen og så dette er et veldig fint mønster som du liker å se. Så dette er på en måte å se på PeopleSoft-miljøet som en samling av undersystemer, og dette vil være passende for operasjoner. Det mest grunnleggende spørsmålet er: "Vel, hva skjer på serveren?" Det nøyaktige har alt dette synlig. Det gir også servermålingene. Og her kan du faktisk måle CPU, minne, I / O, server, brukere på systemet, og så har du den fulle synligheten. Og det er en måte - som kombinert med langsiktig trending - er hvordan folk bruker Precise til kapasitetsplanlegging.
Og jeg vil bare kaste en liten lapp der. Vanligvis vil en butikk ha så mye budsjett for maskinvare, for server, så mye budsjett for ansatte. Hvordan skal du investere, hvor skal du plassere innsatsene dine? Ved å bruke Precise får du en fordel fordi du ser hvordan lagringsundersystemet brukes. Hvis du gjør mye tilfeldig I / O, vil Precise vise deg det. Det vil bidra til å rettferdiggjøre investeringen i solid state-lagring. Det kan være viktigere for butikken din enn å kjøpe ekstra CPU hvis CPU-bruken tilfeldigvis er lav.
Du vil investere der den virkelige behandlingen av flaskehalser er, hvor du faktisk kan ha en utbetaling. And by Precise addressing everything from application coding processing efficiency all the way down to capacity, we allow you to assess and document where those needs are with numbers.
Now the last piece is alerting and the alerting is actually the way this started. Remember that? We saw an alert that there was a performance SLA and we saw that a WebLogic instance was down. So let's take a look at the alerting interface. And once again, what's happening? One of the things I want to point out on this view is that Precise not only has these performance alerts and status alerts about availability, we also have trending alerts. The reason that trending alerts are important is that if your system is idle or has one or two users, probably things run great. It's not until you start to add users and they start to do more and more activity that you start to contend for data, for resources at the Tuxedo level, at the WebLogic level, at the network level, at the database level. And that contention results in performance degradation and then finally you might cross a line and that's a performance alert, and that's basically you're not meeting the SLA goals for the organization. And so these sets of alerts are very nice.
The web tier, over on the left-hand side, the web tier actually measures the end-user experience and then you get into the technologies within the underlying application stack. This is kind of our architecture screen of how do we do all of this. Ideally you would like to have a Precise server that's independent of the monitored environment or environments. One Precise server can handle numerous applications.
For PeopleSoft and for the Oracle and DB2 database, we do require a local agent. If your PeopleSoft environment is back-ended by SQL Server, there is an option to do agentless. We also have agentless for Sybase. The heart of our security model is that data is collected over here, whereas users of Precise authenticate into Precise. It's totally separate processes, separate credentials, separate authentication, and so that's part of our security model. And there's additional details.
I think that this is enough of an introduction to the architecture for now. If there are any burning questions, please do ask them, as Eric had mentioned.
Just as a quick recap, this solution is designed for 24 by 7 in production. It's highly recommended that you use us in QA. If you do in-house development, start using us in development. We're going to translate the complicated URL, URI into a PeopleSoft panel name. When I talk about production, we're extremely low overhead so you have visibility, you always know what's happening, you're identifying the end user.
I did not have to go in and define these transactions – there's just natural connection points from the browser, the URL, the entry points, the web server connection into WebLogic, the invitation context down to the which provides the SQL statement. Then we're able to capture the SQL statement and what it is doing. Precise is database intelligent and I think that this is a distinguishing factor for us and it allows your DBA to collaborate, enhance application visibility.
The final point is because we're always on, we're always collecting, you can always measure before and after and quantify the improvement or, in the rare case you may have changed the performance, you would know that and you could roll it back immediately. Most of our competitors, what they do is if you need to see additional information, you have to turn on additional visibility and typically that additional visibility imposes a lot of overhead. With Precise, you always have visibility and you can always solve the problem. So if you're to go to the Precise website, please check any of the Precise products, whether it's Precise for Oracle. We're listed as Precise Application Performance Platform and there is a button there to request a demo.
Actually, if I share my screen I think I might just navigate there to show you what that looks like just so you can see this right upfront. Here's the IDERA website. You go to products. I can choose any of these Precise components and I just want to see it in action. This will kick off our process for sharing additional information that might be important to your site. Or if you would like to know more about migrating to the fluid UI, you are welcome to contact us.
And which that, Eric, I'd like to pass the baton back to you.
Eric Kavanagh: OK, god avtale. Jeg må si det igjen - en ganske omfattende og imponerende presentasjon der, Bill. Du nevnte en hel haug ting jeg vil spørre om. Vi har ikke mye tid - omtrent ni minutter - og jeg vil at Matt også skal få en sjanse til å stille et par spørsmål, og ha minst en eller to fra publikum.
Men du nevnte noe jeg syntes som var veldig, veldig interessant med hensyn til hvordan Precise kan hjelpe til med anskaffelser for IT-teamet fordi du kan påpeke, du kan lage en sak for hvem som tar den avgjørelsen at det du trenger er mer solid-state lagring, for eksempel, eller det du trenger er forbedringer av nettverket eller hva tilfellet måtte være. Men det er en stor avtale. Ser du ofte selskaper som erkjenner det og bruker det, eller prøver du å evangelisere noe mer?
Bill Ellis: Vel, faktisk begge deler, og saken er at bruksmønstre, selv for et pakkeprogram som PeopleSoft, er bruksmønstrene forskjellige på hvert nettsted. Jeg hadde formuen å gjøre en PeopleSoft-migrasjon i en bank, og banker bruker hovedboksystemet veldig annerledes enn de fleste organisasjoner. Du kan faktisk ha individuelle transaksjoner som ble gjort i en filial, de alle poster til hovedboken.
Og i stedet for å legge ut titalls eller hundrevis av hovedbøker, legger du faktisk ut hundretusener. Og det var slik jeg engasjerte meg i Precise, på grunn av bruksmønstrene og det gjorde det mulig for oss å adressere, men applikasjonens behov både på et kodenivå, et konfigurasjonsnivå og på infrastrukturnivå. Så absolutt jeg er en stor troende, og jeg vil evangelisere det også fordi du ikke burde ta beslutninger om maskinvare ganske enkelt basert på bruk. Du bør basere det på miljøets behov.
Eric Kavanagh: Og det er et spørsmål fra en deltaker, og da, Matt, så overlater jeg det til deg for et spørsmål eller to. Vel, dette er bra, og det er morsomt fordi det er et stort, langt svar du kan gi. Deltakeren spør: "Hvordan samler du resultatmåling ved brukers slutt etter distribusjon og under testing?"
Jeg synes du gjorde en ganske god jobb med å dykke ned i hvor dypt og rikt disse resultatmålingene er. Du snakket om enda et sekund for noen av disse tingene sammenlignet med hvert femte minutt eller tiende minutt. Det er da du skal få det detaljnivået som er nødvendig for å finne svarene dine, ikke sant?
Bill Ellis: Ja, så det avgjørende er at de enkelte samlerne av ytelsesinformasjonen er teknologibasert. Så når vi gjør en distribusjon, må vi vite om hvordan applikasjonsstabelen din er bygget, starter med operativsystemet, dets versjon, hvilken versjon av Tuxedo, WebLogic, hvilken versjon av People-verktøyene du kjører.
Og det er virkelig designet til de agentene som gjør det, datainnsamlingen som gjør at vi kan avsløre at nivået av synlighet Precise gir. Og den synligheten, tror jeg, noen ganger kan være litt skremmende for folk. Men hvis målet ditt er å virkelig komme deg inn og forbedre ting og ta ytelsen til 11, er det virkelig synlighetsnivået du vil ha. Og hvis Precise kan gi det og det er lite overhead, er spørsmålet hvorfor ikke? Så jeg synes det er et flott spørsmål, og ta kontakt med oss hvis du vil diskutere det videre.
Eric Kavanagh: OK, bra. Og Matt, hadde du noen spørsmål?
Matt Sarrel: Jeg tror jeg er OK. Jeg mener, jeg har hatt det med WebEx å krasje her.
Eric Kavanagh: Å nei. Vi trenger presis for å forstå nøyaktig hvorfor.
Matt Sarrel: Ja, jeg antar at spørsmålet som jeg hadde tenkt på mens du snakket, Bill, var om du kunne diskutere litt om hvordan flere lag kan komme på samme side når du feilsøker ytelsesproblemer, fordi jeg vet at det er noe som kommer opp igjen og igjen er hvem som er ansvarlig for hva og hvordan kan alle samarbeide for å levere den beste kvaliteten til de ansatte.
Bill Ellis: Ja, så IT-ansatte har en tendens til å bli dyre. I de fleste butikker er du delt inn i team basert på teknologi, gitt teknologiens kompleksitet. Noe av det store som skjer er at det er et ytelsesproblem, og det er mange ganger konflikten, samles krigsrommet. Og det er her alle har beregningene for på en eller annen måte å gjøre fri fra nivået fordi de ikke har sammenhengen. De ser på hva som skjer på WebLogic-nivå i stedet for hva som skjer på transaksjonskodenivå. Eller de ser på databasenivå i stedet for transaksjonens individuelle SQL-setning.
Og ved å kunne identifisere problemnivået og problemkoden i det nivået, hva det gjør er at det frigjør de andre lagene til ikke å gå eller bruke tid på ressurser på jakt etter et problem som ikke er innenfor deres område. Hvis det er et databaseproblem, kan du gå til DBA med informasjonen de trenger for å løse problemet. De vil gjerne gjøre det.
Men ikke kast bort Tuxedo, WebLogic assistentteamet med fokus på problemene i databasen. På samme måte, hvis problemet skjer i WebLogic-konfigurasjon, ikke ta DBAs tid i et slags krigsrom å prøve å forsvare seg. Bare gå løs på problemet i WebLogic.
Vi opplever at IT-ansatte setter pris på presis på grunn av tidsbesparelsen, fordi typisk er ikke krigsrommene budsjettert med tidsplanen for hver FTE-organisasjon. Det er litt som ekstra tid. Og det er virkelig viktig å kunne håndtere disse spørsmålene mer effektivt. Og for organisasjonen som rullet ut det flytende brukergrensesnittet, var det veldig viktig ikke for individuelle medarbeidere eller team, men faktisk for IT-ledelse generelt fordi det hadde vært dårlige nyheter for å kunne skalere produksjonen og løse problemene de faktisk opplever i produksjonen. hvis de måtte rulle tilbake. Så, flott spørsmål, fordi det ikke bare er teknologien. Det handler egentlig alltid om menneskene.
Matt Sarrel: Rett, det er menneskene og prosessene. Ja, det var det eneste spørsmålet som kom opp for meg under demonstrasjonen. Hvis det er noen andre fra publikum?
Eric Kavanagh: Ja, jeg vil bare kaste en siste til deg, Bill, og Matt snakket om dette kort i presentasjonen sin. Vi har begynt å se denne avlingen. Det er fremdeles veldig fremtidsrettet, men containere og bruk av containerisering og Docker og ting av den art, hvor stort av en kurveball kaster det dere?
Bill Ellis: Så ordet betyr forskjellige ting, avhengig av forskjellige teknologier. Så vi utvikler produktene våre til å ta vare på containere på databasenivå og på applikasjonsnivå. Og som en del av det, er det slags hele miljøet med bevegelsene, skyen, og vi opererer innenfor skyen. Men det er en oppdagelsesprosess, og så avhengig av hvordan disse applikasjonene - inkludert PeopleSoft - utvikler seg, utvikler vi vår overvåkningsløsning slik at vi kan gi et dybdenivå som har vært så verdifullt i fortiden.
Eric Kavanagh: Ja. Og jeg må si, hver gang jeg ser disse demonstrasjonene er jeg bare overrasket over kortheten du har, og det er det du trenger for å kunne sammenfatte en forståelse, og du trenger å ha litt utdanning rundt hva som er den normale situasjonen, hva er standard.
Og dere mennesker tilbyr mye innhold rundt det - å hjelpe folk med å identifisere hva som er normalt, hva som ikke er normalt. Du snakket om trenderingsvarsler, for eksempel, dette er alle mekanismer du kan bruke for å bedre forstå at noe er galt, er noe ikke galt, og da må du selvfølgelig derfra bore ned for å finne det, men du har alle dataene.
Bill Ellis: Ja, og det er en veldig viktig ting; Jeg tror Matt hadde snakket om det. Hva er normalt? Ulike miljøer har et annet normalt nivå. Hvis du kjører med avansert maskinvare, Oracle-logikk og data, er det som er normalt i butikken eller det som er oppnåelig i butikken, annerledes enn hvis du kjørte under en mindre kraftig infrastruktur. Så det første er å finne ut hva som er normalt, begynne å beregne den grunnlinjen og på den måten kan du begynne å gjøre forbedringer derfra.
Eric Kavanagh: OK, det er et godt poeng. Vi har et siste spørsmål, det ser ut. Bare et siste spørsmål jeg vil kaste til deg, Bill. Er det noen forskjell mellom SQL og databaseytelsesovervåking fra systemnivå og applikasjonsnivå data? Hva er forskjellen mellom å overvåke SQL og databaseytelse fra ditt perspektiv?
Bill Ellis : Vel, ingenting skjer i en database før SQL-setningen kjøres. SQL-setningens påstand er hva - kontroller låsing, venting, påstanden om ressurser på datanivå og på SQL Server-nivå. Og så hvis jeg kan se driveren av SQL-setningen og dens innvirkning på systemet, har jeg forårsaket en effekt; Jeg kan koble det applikasjonen DBA bryr seg om med infrastrukturen DBA bryr seg om til jeg virkelig kan få mest mulig ut av det presise verktøyet.
Hvis jeg er en infrastruktur-DBA og ser på ting som utnyttelse, er jeg veldig form for administrasjon med en bred børste kontra hvis jeg er i stand til å se på et individuelt SQL-utsagn, og jeg er i stand til å faktisk minimere ressursen forbruk - enten det er CPU, minne, I / O - Jeg er i stand til å adressere begge sider av den samme mynten.
Eric Kavanagh: OK, folkens. Vi brant gjennom litt over en time. Stor, stor takk til vennene våre på IDERA. En stor takk til Matt Sarrel for at han ble med oss i dag. Vi arkiverer alle disse webcastene for senere visning, så kom gjerne tilbake og vanligvis på bare et par timer arkivet går opp. Så sjekk ut, og alt jeg har å si er at jeg elsker disse tingene, jeg elsker presis, jeg elsker å kunne komme i ugresset. Og jeg kjenner ikke noe annet verktøy som lar deg grave deg rundt i alle de forskjellige delene og delene av applikasjonsbunken enn hva folk har på IDERA med Precise.
Med det tar vi farvel, folkens. Takk igjen, vi snakker med deg neste gang.
