Tag væk: Værten Eric Kavanagh diskuterer PeopleSoft performance management med Matt Sarrel og Bill Ellis i denne episode af Hot Technologies.
Eric Kavanagh: Okay, mine damer og herre. Hej og velkommen igen. Det er en onsdag kl. 4 øst for øst, og det er de sidste par år, det betyder i denne verden af IT og big business og data, er det tid for Hot Technologies. Ja, ja, jeg hedder Eric Kavanagh. Jeg vil være din moderator til dagens begivenhed.
Vi vil tale om de systemer, der driver forretning, folk; vi taler om PeopleSoft, hvordan man administrerer ydeevnen i komplekse miljøer. Jeg vil altid gerne nævne, at du spiller en stor rolle i disse begivenheder, så vær ikke venlig. Stil dit spørgsmål til enhver tid; du kan gøre det ved hjælp af chatvinduet eller spørgsmål og spørgsmål - uanset hvordan det kommer igennem. Jeg vil meget gerne høre, hvad du vil vide, og det er den bedste måde; du får den bedste værdi for din tid. Vi arkiverer alle disse webcasts til senere lytning, så husk bare på det.
Hvis systemer kører langsomt, skal du bare huske, hvordan livet plejede at være. Dette foto er faktisk fra 1968, høflighed af en dame ved navn Danelle, og jeg må sige, at dette virkelig er en skarp påmindelse om, hvor meget ting der har ændret sig. Verden er blevet bemærkelsesværdigt mere kompleks, og selvfølgelig har forretningsbehov og brugeroplevelse en tendens til at gå hånd i hånd. Men i disse dage er der lidt af en afbrydelse. Der er en uoverensstemmelse, som vi ofte siger, og faktum er, at forretningsfolk altid vil have ting hurtigere og hurtigere, it-teams, der skal levere, er dem, der bliver under pres for at få gjort jobbet, og det er en intens verden derude.
Jeg må sige, konkurrencen er blevet varm overalt. Hvis du bare ser på en hvilken som helst branche, kan du se, at der er en stor udvikling i disse dage - for eksempel at Amazon køber Whole Foods. Du kan være sikker på, at købmandsindustrien kigger hårdt på den.Vi ser dette overalt, så det påhviler virkelig ledere at sikre sig, at de finder ud af, hvordan man - og her er buzzword i disse dage - digitalt omdannelse, hvordan man kan bevæge sig ud over det gamle tavle til meget mere nye og robuste systemer. Det er hvad vi vil tale om i dag.
Et af de spørgsmål, som mange organisationer står overfor, især dem, der har eksisteret i et stykke tid, er disse arvssystemer. Det er en gammel IBM mainframe tilbage fra dagen. Der er gamle systemer overalt. En af vittighederne er, at et arvssystem er et system, der er i produktion, hvilket betyder det øjeblik, det går i produktion, teknisk set er det et arveanlæg. Der vil altid være nye måder at gøre ting på.
Og der er nogle meget interessante udviklinger i de sidste par år om at finde måder til praktisk talt at forene systemer til ikke nødvendigvis bare at forbedre et systems ydeevne, men at finde en måde at skabe en slags offshoot eller en off-load-taktik til at håndtere ydelse på andre måder. I dag skal vi tale mere om, hvordan man forbedrer ydelsen i et system som PeopleSoft, som selvfølgelig er utroligt kompliceret. Men når det gøres godt, når det indlæses, når det implementeres, når det styres godt, kan det gøre vidunderlige ting. Men når det ikke lykkes godt, er det, når du har alle slags problemer.
Så hvad sker der? Du skal være realistisk omkring ting og i ethvert miljø, hvis brugerne ikke får det, de vil, før eller siden går de til skyggesystemer. Det sker hele tiden. Skyggesystemer kan være meget produktive, de kan hjælpe folk med at få jobbet gjort. Men selvfølgelig er der masser af problemer. Bestemt i hele området med overholdelse og regulering er skyggesystemer et stort no-no. Men de er derude, og jeg synes, det er vigtigt at huske, at dine systemer, hvis dit hovedsystem ikke fungerer hurtigt eller ikke fungerer effektivt, før eller senere vil der komme løsninger, og disse løsninger kan være meget svære at afsløre, de kan være svære at solnedgang, fordi de ender med at være kritiske for virksomheden. De kan være svære at integrere, så bare husk, at det er derude, og det er bare en anden grund til at forbedre ydelsen.
For nylig hørte jeg om dette udtryk, og jeg er nødt til at smide det ud: "hastighedens tyranni." Jeg tror bare at høre, at du sandsynligvis ved, hvad jeg taler om, og hvad der sker i de fleste organisationer, er arbejdsbyrden når en kritisk masse , og folk gør så meget som de kan, og det bliver meget vanskeligt at ændre noget. Du ender op med at lide under ”hastighedens tyranni” - alt skal ske med det samme. Nå, opgradering af et system sker ikke med det samme.
Enhver, der nogensinde har levet gennem opgradering af en ERP fra en version til en anden version ved, at det er en relativt smertefuld proces, så vær bare opmærksom på dette: Hvis du ser det i din organisation, skal du genkende det. Forhåbentlig kan du komme igennem til nogen, eller hvis du er en senior person som en CIO eller CTO eller CEO, kan du erkende, at dette er et meget farligt scenario, fordi når du først er bag den otte bold, er det virkelig svært at komme ud bagfra otte bold.
Det er ligesom hele maratonforholdet: Hvis du vinder langt bagefter i et løb af en eller anden art, og alle er foran dig, og du stadig er løbende, bliver det virkelig svært at indhente, hvis du falder for langt bagefter. Så pas på det og husk det.
Og med det overlader jeg det til Matt Sarrel for at give os nogle indblik i, hvordan vi håndterer kompleksitet med PeopleSoft-miljøer. Matt, tag det væk.
Matt Sarrel: OK, tak, Eric. Hej allesammen. Så lad os se, jeg starter med at fortælle dig, hvorfor jeg tror, jeg er den rigtige person til at tale med dig om at styre præstationer. Så jeg har 30 års erfaring inden for teknologi. Jeg kan godt lide at sige, at jeg arbejdede mig op gennem at være en hands-on, en netværksadministrator, direktør for IT, VP for teknik ved et par nystartede virksomheder. Derefter gjorde jeg denne overgang til at blive teknisk direktør på PC Mag. Der er mit billede der, men dybest set ser jeg ud som et lille barn.
Og derefter fortsætter og være journalist ved en række forskellige publikationer som eWeek og InfoWorld, være analytiker hos Gigahome, netværk med Bloor Group og også have en konsulentvirksomhed. Og der er mig: Dette billede til venstre er, hvordan jeg ser ud nu. Dette billede i midten er slags, hvor jeg er meget glad - i et rum fuldt af ledninger og blinkende lys, og hvor det er koldt - det skal være meget koldt, og alle andre skal være ubehagelige for at jeg skal føle mig komfortabel med temperaturen. Og der er min kontaktinformation, hvis du har spørgsmål om opfølgning.
Jeg vil sætte scenen her og bare tale om performance, som Eric talte om. Vi er nu kommet ind i denne verden, hvor brugerne har denne forventning, der er indstillet af forbruger apps og websteder. Og folk plejede at være villige til at gå på arbejde og sidde der og vente på deres systemer, fordi det var det, de havde brug for, og nu er folk ikke rigtig villige til at sidde der. Så det er et spørgsmål om de vil have denne motorcykel der flyver rundt på banen. De vil sandsynligvis ikke have, at fyren kører på sin cykel og bærer sin datter i skolen. Men hvad vil du give?
Og det er svært, fordi - virkelig var jeg en slags generøs med en til tre sekunder så god - folk vil også have et øjeblikkeligt svar, og de vil have adgang overalt. At hvor som helst kan være overalt i din bygning eller på din campus, eller det kan være overalt i verden til enhver tid afhængigt af hvor godt din virksomhed fungerer. Og jeg gætter på, hvad jeg bygger op til, er, at når vi taler om ydeevne, er det vigtigt at tænke på ydeevne ud fra brugeroplevelsens vinkel.
Det er vigtigt at definere præstationsmål inden måling og indstilling. Jeg har dette billede af en tuner og derefter en tuner. Den faktiske mand, der vælger en tuner, han har brug for at vide, hvad han indstiller til, eller der er ingen mening i at lægge sine hænder på klaveret og tune det. Så at definere mål på forhånd, at slags holder det reelt i stedet for at tilpasse mål, der passer til den aktuelle situation. Det er vigtigt at overvåge målinger over tid og indse, hvordan systemer ændres med brugernes indlæsning af applikationsydelsen, hvilket påvirkes af ressursscener og brugsmønstre.
Det er altid vigtigt at sammenhænge alt dette sammen med en brugeroplevelse eller supporthændelser, etablere en baseline for den ydelse, du forventer at være i stand til at levere, og når du nærmer dig afvigelser fra den baseline, skal du have proaktive advarsler, så du kan tage handling, inden vi ramte status "fail whale". Og du ved, at det kræver evnen til at være i stand til at bestemme og løse grundårsagen til præstationsproblemet meget hurtigt og nemt. Og igen, dette er jo tidligere, jo bedre, ikke?
Vi ved fra tidligere historie at se på udviklingsindsats, jo tidligere du kan finde og løse ydelsesproblemer, jo bedre er du. Hvis du venter, indtil al din kode eller dit system er live for at starte præstationsprøvning eller for at begynde at afsløre problemer, siger jeg ikke det er for sent, men igen, nu er du den fyr, der fik en dårlig start i maraton og nu spiller du fangst -op i stedet for at hoppe lige ud og komme videre. Så hvordan gør du det? Forudser du dit gennemsnit og din maksimale belastning?
Og du går videre, og du størrelse dine fysiske servere eller dine virtuelle servere eller dine sky-forekomster eller dine containere og dine container ressourcer og derefter køre et bevis på koncept og køre en pilot? Dette er de tidspunkter, dette er slags, slutningen af, hvor du vil fange noget, selvom du stadig er bedre til at fange det i produktionen end at ignorere det i produktionen. Men virkelig, når du er i din pilot, skulle du allerede have etableret din metode og procedurer omkring kontinuerlig overvågning og forbedring.
OK, så mange virksomheder - vi taler om digital transformation. DevOps, i DevOps-revolutionen spiller en enorm rolle i den digitale transformation. Og dette er en ende til ende proces, der virkelig aldrig stopper. Så det er som de to hænder, der tegner hinanden, og dette er gode ting. Det er en uendelig løkke mellem disse to hænder på plan, kode, bygge, teste, frigive, distribuere, betjene, overvåge, tilbage til plan. Det føder sig selv, og vi automatiserer det, så det går hurtigt. Det skaber en produktionspræstationsovervågningsfeedbacksløjfe, og den bruger den til proaktivt at afsløre ydelsesproblemer og løse dem, før de påvirker hele din brugerbase.
Og en anden ting, nu hvor du har det, IT-udviklere og driftsmedarbejdere bevæger sig meget hurtigt og justeres, kan du også nemt justere denne indsats med forretningsfolk. Enterprise-softwareydelse er et komplekst dyr. Man kan måske sammenligne det med et fodboldhold, der sidder foran et tavle, der tager retning, og alt fungerer separat og alt fungerer sammen. Jeg tænker altid på det som den gamle historie om, da jeg fik min første bil, og jeg fikseret en ting. Jeg fikseret klimaanlægget, og så skete der, at resten af kølesystemet mislykkedes. Så du har dine smertepunkter og alt, der går sammen og foretager justeringer. Du er nødt til at organisere alt på en sådan måde og opbygge processerne, så når du foretager dine ændringer, forstår du, hvordan alt påvirker alt andet.
Og vær også forsigtig og dobbeltkontrol. Test, ugyldigt, implementer. Og igen kommer vi til dette spørgsmål om at opbygge kontinuerlige overvågnings- og præstationsforbedringsprogrammer. Og dette er faktisk min sidste dias. Mens vi taler om denne kompleksitet, og det er en smuk kompleksitet ligesom indersiden af dette ur, har vi så mange bevægelige stykker til PeopleSoft. Hver ting påvirker alt andet helt op og ned i stakken. Og der er så mange forskellige steder, hvor du kan kigge efter nøgler til performance-problemer, at du meget let kunne gå tabt uden det rigtige værktøj og uden den rigtige proces. Og igen på alt det, i mange tilfælde, hvad jeg tror, vi har lært, er at du kan fejlfinde infrastruktur, men den enorme variabel bliver din brugerdefinerede applikationskode. Og det at have de rigtige processer på plads til test og løbende forbedring af din applikationskode er det, der bliver vigtigt.
Og så det er slutningen af min del, og jeg overdrager dette til Bill.
Eric Kavanagh: Okay, Bill, lad mig give dig nøglerne til WebEx her. Jeg kan godt lide den smukke kompleksitet - det er en dejlig. Du havde et par virkelig gode citater der, Matt. OK, Bill, tag det væk. Gå til “hurtig start”, hvis du vil dele din skærm. Alle dig.
Bill Ellis: Tak, Matt, og tak, Eric. Bare for at bekræfte, kan I alle se min skærm nu?
Eric Kavanagh: Ja bestemt.
Bill Ellis: Så vi vil tale om IDERAs produkt Precise for PeopleSoft og den synlighed, de kan give, for at hjælpe dig med at få succes med at styre den komplekse applikationsstakke. En måde at placere vanskeligheden på er, at en applikation, mindst seks teknologier, adskillige slutbrugere, og det gør det meget vanskeligt at besvare selv enkle spørgsmål. Har en slutbruger et problem? Hvem er slutbrugeren, hvad laver de, hvad er grundårsagen?
Det, vi typisk ser, er denne situation - og det kan gælde for PeopleSoft såvel som andre applikationer eller PeopleSoft, der interagerer med andre applikationer - er inden for datasættene, eller det kan være skyen i disse dage, en slutbruger er ligeglad med den kompleksitet. De ønsker bare at gennemføre transaktionen, tilgange, opslag af lager, rapporteringstidskort, de slags ting. Hvis tingene er langsomme eller ikke tilgængelige, er alle disse intelligente, velmenende mennesker typisk uvidende, indtil slutbrugeren klager.
Det er en slags synlighedskløft lige der, og hvad der kan ske er, at det kan starte en tidskrævende og frustrerende proces, hvor folk muligvis åbner et værktøj, og de ser desværre bare på en undergruppe af applikationsstakken. Så der er stadig vanskeligheder med at besvare disse grundlæggende spørgsmål.
Og mange gange kan der være et problem, og du går til WebLogic-administratoren, og han siger: ”Nå, hukommelsen, affaldssamlingerne ser alle godt ud. Jeg tror virkelig ikke, det er WebLogic. ”Du går til DBA-administratoren, og de siger:” Nå, databasen, den kører lige som den var i går. De ti bedste ser godt ud. Måske har lagringsadministratoren ramt dig med nogle metrics som I / Os per sekund eller gennemstrømning, som er rammer på metrics og måske ikke reflekterer over din særlige applikation, meget mindre databasen eller den særlige proces. ”
Og så har de alle disse målinger, der ser ud til at vise, at problemet er andre steder, men alligevel har denne slutbruger et problem eller har rapporteret et problem, men hvordan kan vi løse dette problem på en bedre måde? Og den bedre måde, den præcise måde - eller det er en måde, vi tilbyder - er at måle brugertransaktioner, der starter i browseren gennem netværket, på webserveren, i Java Jolt, i smoking, i databasen inklusive DB2 og derefter til sidst på lager.
Og hvad dette viser, er at den samlede tid siger, ”Nå, hvem har et problem?” Og så kan vi identificere slutbrugeren ved, hvordan de loggede på PeopleSoft, og vi kan også fange via Tuxedo-oversættelsen, hvad PeopleSoft-paneler kører.
Så timingerne føres ind i et historisk arkiv, som vi kalder performance management-databasen, og dette bliver et enkelt stykke musik, der i høj grad forenkler hvem, hvad, hvornår, hvor, hvorfor. Det præcise inkluderer også anbefalinger. Den vigtigste ting er sandsynligvis fordi vi fanger al information hele tiden - både på det tekniske it-personale-niveau - du kan måle før og efter. Så du kan bringe måling ved måling eller Six Sigma til hele driften.
Og lad os så se på "en dag i livet." Først og fremmest åbner du måske skærmbilledet Præcise alarmer, og det er her, du vil få en tidlig advarsel. Den allerbedste alarm er, at du har aktivitetsadvarsler. Så det er brugere, der udøver transaktioner, og vi opfylder stort set ikke vores SLA'er. Ligeledes har vi en status når tilgængelighed - og det siger dybest set, at en del af vores applikationsinfrastruktur ikke er tilgængelig - så vi kan bore ind, og vi kan faktisk se, hvordan Tuxedo forekommer i formen, og du kan faktisk se, at en af forekomster er nede. Hele aktiviteten skubbes til denne ene instans, og den er nødt til at tackle det. Vi har dybest set oprettet en flaskehals.
Nu, lige som en ting, for den aktivitet, der kører på dette, kan du faktisk begynde at komme ind på fundet, at selvom vi har dette overordnede infrastrukturproblem, er der måder at forbedre behandlingseffektiviteten inden for denne særlige JVM for WebLogic. Og det er her, det her er virkelig en vigtig ting: Mange gange bevæger folk sig som en sky, og de siger: ”Nå, hvor meget CPU og hvor meget hukommelse har du brug for?”
Den anden side af den mønt, der er kendt som kapacitet, er behandlingseffektivitet. Hvis jeg bruger mindre hukommelse, hvis jeg bruger mindre CPU, behøver jeg bare ikke så meget. Og som Matt sagde tidligere, er alt slags relateret. Hvad jeg nu kan gøre er, at jeg kan åbne PeopleSoft-transaktionsskærmen, og på skærmen er y-aksen responstid, x-aksen er tid over dagen.
Vi har en stakstregediagram her, der viser klienttid. Det er faktisk browseren, webserveren. Den grønne er Java-tid, den slags lyserøde er smoking, den mørkeblå er databasetid. Denne profil skete ikke af sig selv; det skete på grund af de bestemte PeopleSoft-paneler - de var blevet udført, og de bliver præsenteret for dig ved svartid. Der er faktisk en timing af hvert trin i applikationen såvel som en stabelstangdiagram, der viser applikationen her panel for panel. Jeg er også i stand til at bore ind og finde en bestemt bruger eller rangere mine brugere.
Denne skærm giver mig mulighed for at specificere en bestemt bruger ved login-navn. Tænk på hvor bemærkelsesværdig eller hvor kraftfuld dette er. Mange gange handler det ikke kun om infrastrukturen og hvordan det er oprettet, det er hvordan slutbrugerne bruger systemet. Du har muligvis en ny leje, eller nogen har en ny jobfunktion: Den ved muligvis ikke, hvordan du bruger applikationen korrekt. Dette kan faktisk hjælpe med at identificere træningsmuligheder.
Den anden side af mønten er, hvis jeg kan fokusere på en bestemt bruger - her ser jeg på den bruger i deres særlige transaktioner og responstiden, som de oplevede - Jeg er i stand til direkte at adressere brugeroplevelsen for en bestemt bruger. Det handler ikke længere om generiske målinger på systemniveau, det handler om slutbrugeroplevelsen og det er meget stærkt. Dele af dit miljø vil bestemt være interne, HR osv. Der kan være andre dele, som kunden står overfor. Uanset hvad, vil du give den bedste og mest produktive kundeoplevelse som muligt.
Nu for et bestemt panel kan jeg gå ind og bore ind for at besvare spørgsmål. Så dette er en slags dyb dyk, som vi kan gøre for at afdække hvad der sker, og du kan muligvis gøre dette dybe dykk, før du ringer til en slutbruger, eller hvis en slutbruger havde ringet til dig, ville du være i stand til at starte en proces for at sige, ”Nå, hvor nøjagtigt er grundårsagen?” Og det vil ikke være som en CPU-anvendelse og en tilsidesættelse, det vil være på den applikationskode, de udøver.
Lad os bore ind og tage et kig på den indholdsstyring, og du kan faktisk se en analyse af den transaktion: start af browseren, indgangspunkt til webserveren i Java Jolt og viste faktisk kode, der udføres ned i Tuxedo-panelet, endelig til SQL-sætningen, hvor Precise afslører den af SQL-sætningen, der udføres af dette særlige PeopleSoft-panel.
Alle, vi snakker med, har værktøjer, men hvad de ikke har, er con. At forbinde prikkerne eller følge transaktionen fra browseren helt til SQL-sætningen er con. Hvad det gør for ligesom din DBA, snarere end at se på ting på et forekomst eller et databaseniveau, kan jeg nu undersøge på et SQL-sætningsniveau.
Så jeg kan sige, ”Nå, hvad er flaskehalse for en individuel SQL-sætning,” og dette er ekstremt kraftfuldt. Overvej, at denne transaktion ikke kan køre hurtigere end SQL-erklæringen, og at enhver væsentlig forretningstransaktion interagerer med postsystemet. Databasen, ligesom den eller ej, er fundamentet for ydeevne, og hvis jeg kan være så kornet at fokusere på individuelle SQL-udsagn, der er afgørende for en forretningstransaktion, kan jeg virkelig tage mit spil til det næste niveau.
En anden ting, som du måske vil bemærke her, er der en procentvis beregning af bidrag, som Precise leverer. Browseren i sig selv er faktisk en betydelig del af applikationsstakken.Du har JavaScript-udførelse, du har gengivelsestid, du har sidekomponenter, GIF'er, JPEG'er. Og du finder faktisk ud af, at din applikation muligvis opfører sig meget forskelligt under Chrome versus IE og forskellige versioner. Precise vil være i stand til at vise det også for dig, og der kan være tidspunkter, hvor der faktisk er en flaskehals eller en strid i browseren, der kan forårsage ting som skærmen fryser.
At være i stand til at identificere, der gør det muligt for IT ikke at bjælke op på det forkerte træ, men at løse grundlæggende årsag til forskellige problemer, der kan opstå. Hvad jeg nu kan gøre for en bestemt SQL-sætning, kan jeg derefter analysere nøjagtigt, hvad der sker ved den SQL-sætning. Så her er vi faldet til databaseekspertvisningen.
En af de ting, der adskiller Precise på databaseniveau, er, at vi prøver på sub-sekundbasis. Dette er i sammenligning med vores konkurrenter, der kun ser én gang hver 10. gang en gang hvert 15. minut. Så at graden af granularitet, opløsningsniveauet er størrelsesordrer bedre end vores konkurrenter.
Og endnu en gang, da databasen er en del af vores fundament, tillader vi din DBA virkelig at føre ydeevne til næste niveau. Så jeg kan se, at denne SQL-sætning faktisk brugte 50 procent, hvis det var tid til at øve sig på at få adgang til det lagrede undersystem, 50 procent af sin tid ved hjælp af CPU'en. Klik på tune-knappen, så kan jeg gå ind og udføre eksekveringsplaner, og præcis hvad der kørte det brugsmønster.
Nu er et tilbud fra en af vores kunder - hvis de ikke var i Oracle Shop, brugte de et Oracle-værktøj kaldet OEM og OEM er virkelig slags database eller forekomstfokuseret - er det DBAs, der konstant ser på, hvad er top 10-listen? Men med Precise er vi i stand til at forbinde prikkerne til de individuelle SQL-udsagn, og således at granularitet tillader DBA at virkelig indstille på transaktionsniveauet og ikke kun på det meget højere databases niveau.
Det andet punkt, der virkelig var vigtigt for denne kunde, er, at Precise ved at oversætte, hvad der er en kompliceret din URL, til et PeopleSoft-panelnavn - hvis jeg er i IT og jeg kan tale om træmanager, content manager, en bestemt HR-side, på den måde den person, jeg prøver at hjælpe, kender jeg faktisk ser og forstå, hvad de ser på, fordi det ikke længere er disse hieroglyffer, det er det navn, de er bekendt med.
Et af de spørgsmål, vi bliver stillet - det ser ud til at være hele tiden, så jeg troede, at ID bare var slags proaktivt svar på spørgsmålene - hvordan i verden fanger du det PeopleSoft bruger-ID? Lad mig slags gå gennem trinene. Her er en PeopleSoft-login-skærm. For at få adgang til den, var jeg nødt til at navigere til min webserver, og denne skærmbillede vises. Når applikationen er instrumenteret med Precise, indeholder denne skærm faktisk et præcist script, og jeg kan afsløre ved at gøre et højreklik, se kilde. Og dette vil faktisk vise mig den kode, der udgør den underliggende side og her oppe i siderammen er faktisk det præcise for webkode, og dette giver mig mulighed for at fange tilmeldingsskærmen, IP-adressen, browsertypen, en helhed en masse oplysninger om gengivelse og den sande slutbrugeroplevelse. Og så når jeg indsætter mit brugernavn og klikker på, kan Precise derefter måle, hvad jeg laver.
Jeg åbner op, går til træmanageren, jeg vil udføre en søgefunktion, udfylde feltet og jeg klikker på søgning. Et resultatsæt præsenteres for mig, så jeg har tydeligt gennemgået hele applikationsstakken helt ned til databasen. Hvordan viser Precise dette? Lad os tage et kig. Åbne op Præcis, jeg går ind, jeg kan se aktiviteten, jeg kan klikke på aktivitetsfanen, der vil få vist denne skærm. Dette er de ikke oversatte webadresser. Jeg kan vise brugerne, og her er mit bruger-ID, som jeg lige har logget på, og her er min aktivitet.
Du kunne se, at jeg brugte Firefox version 45 til at få dette op. Jeg udøvede ansøgningen 12 gange og opgiver er dybest set, når nogen forlader en webside, før den fuldstændigt gengives, hvilket antyder et forretningsspørgsmål. Så det var sådan, vi var i stand til at hente slutbruger-ID. Det er meget rart, folk værdsætter virkelig, når du ved nøjagtigt, hvad der foregik.
Nu vil vi skifte gear lidt underligt. Vi kiggede på transaktionen senere. Vi dykkede dybt i en bestemt transaktion og kiggede på dens SQL-udsagn. Nu vil jeg skifte gear og se på nogle af de andre teknologier i PeopleSoft-applikationsstakken, der starter med WebLogic.
Og her er et WebLogic-eksempel, og du kan se aktiviteten over tid. Du har en finansieringsrapport. Det fortæller mig lige fra flagermus, hukommelsen bruges næsten maksimalt. En af de ting, som vi finder, er, at de fleste mennesker kører hele applikationsstakken, eller i det mindste en del, under et delt miljø, ofte dets VMware. Du skal slags afveje, hvor mange ressourcer du anmoder om, og hvor meget du har brug for. Du ønsker ikke at være en ressource-svin. Ligeledes vil du ikke sætte en behandlingsbegrænsning ved ikke at bede om nok hukommelse i dette tilfælde.
Konfigurationen er også vigtig for performance management. Så vi kan faktisk komme ind i hukommelsespildopsamling og alle JMX WebLogic-tællere, så jeg ved nøjagtigt sundheden for min WebLogic-form.
Nu ind i smoking. Tuxedo i mange butikker er slags en sort kasse og det er en meget vigtig del af PeopleSoft. Det er den slags lim, der holder alt sammen, og derfor synes jeg næsten det som en udvidelse af operativsystemet. Det er noget, du bruger og konfigurerer meget omhyggeligt. I øvrigt - dette er en lille sidebesked - i de indledende kommentarer, Eric havde nævnt "tyranny of urgency", og jeg tror, at det virkelig kommer i spil, når PeopleSoft-butikker overvejer at flytte fra det klassiske UI til det flydende UI, fordi du finder ud af, at du er bag kurven på grund af den måde, det flydende brugergrænseflade udøver PeopleSoft-miljøet på.
Nu har du problemer på WebLogic, Tuxedo, i databasen og på lageret her, bare fordi HTML5 udfører en enorm mængde meddelelser. Det er sandsynligvis mindst 10 gange, hvad det klassiske UI gør, og at yderligere beskeder betyder ekstra trafik. Så konfigurationen af smoking skal ændres for at imødekomme den ekstra trafik. Et par ting ved denne skærm er ovre på højre side, vi har over-tid grafer for vægtet responstid, gennemsnitlig responstid samt eksekveringstælling.
Herover har vi information om alle Tuxedo-domæner i miljøet. Vi delte tjenester, brugere, serverprocesser såvel som IP'er. Jeg kan flytte dette til eksekveringstælling og præsentere dem i faldende rækkefølge, så jeg kan se, hvad der udføres mest gange. Jeg kan også rulle ned for at afsløre domænerne; de fleste mennesker har flere domæner i deres miljø, for dybest set at sprede aktiviteten, og jeg er i stand til at indstille SLA-overholdelse, derfor advarer ved Tuxedo-laget.
Hvis du står i kø, har du forskellige problemer, der opstår på grund af konfigurationen. Du typisk - fordi det er globalt med indflydelse - vil du typisk ikke foretage ændringer på farten. Du ønsker slags gradvist gradvis at øge systemet som en del af QA-processen, der springer tilbage til et punkt, som Matt tidligere havde gjort om at adressere præstationsproblemer tidligt i processen. Det er meget bedre at have konfigurationen korrekt, når du går til produktion snarere end at gå til produktion og finde ud af, at konfigurationen ikke stemmer overens med brugsmønstrene. Jeg kan virkelig godt lide den introduktion, som Eric og Matt havde givet i dag. Jeg troede, at de virkelig var i mål med hensyn til de udfordringer, du står overfor med at styre og udvikle PeopleSoft-miljøet.
Nu sagde jeg dette en gang før - jeg synes det er værd at sige igen: Hver væsentlig forretningstransaktion interagerer med databasen. Og så lad os undersøge, hvordan Precise kan give yderligere oplysninger. Her i er en bestemt Oracle-forekomst. Den samme nøjagtige tilgang, som vi så - y-aksen er udførelsestid, x-aksen er tid over dagen, men nu er stabelbjælkelisterne udførelsestilstander i Oracle. Dette viser os, hvad er behandlingsbegrænsningerne på systemet. Her nede er der faktisk en fundrapport, der fortæller mig, at du har fået denne høje forny logbuffer.
Jeg ser også på denne valgte version fra PSVersion. Det bruger faktisk mange ressourcer. I øvrigt, fordi vi sampler, og vi leverer denne opløsning i høj opløsning af, hvad der faktisk sker på systemet, vil du måske blive overrasket over, hvad er de rigtige ressourceforbrugere på dit system, for hvis du bare kigger hvert 10. minut, vil det ikke viser dig, hvad disse ressourceforbrugere er. Og så ved at vide, hvad de rigtige ressourceforbrugere er, kan du faktisk adressere den rigtige behandling på flaskehalse eller på systemet.
Nu her er vi hoppet over til aktivitetsfanen, og dette er aktiviteten. Du kan se, at vi ser på CPU, lagringsundersystem, applikationslåse, OS-ventetid, RAC, commit, Oracle-server, kommunikation og internt aggregat sammen. Dette er y-aksen, dette er den samlede udførelsestid.
Her nede er SQL-udsagnene, der kørte denne profil, og en af de ting, du ser, er denne lave latenstid - to millisekunder, men med næsten 4.500 henrettelser betyder, at SQL-udsagn faktisk er den største ressourceforbruger på dit system, og det er godt at ved godt. Det er heller ikke venter på en lås eller en ventetid. Det bruger CPU'en 100% af tiden. Det betyder ikke, at der ikke er ting, jeg ikke kan gøre med det. Der er masser af ting, jeg kan gøre ved det, hvis jeg ved, hvilke SQL-udsagn og -objekter der er adgang til. Og så dette er nogle af de måder, vi kan hjælpe.
Nu her nede er der denne drill-down, og dette kan sætte os sammen med de individuelle PeopleSoft-programmer, og hvert af disse programmer tjener slags et andet formål inden for PeopleSoft. Du kan faktisk begynde at adressere på databaseniveau, hvordan applikationen bruges.
Og hvis jeg vælger et bestemt program, kan jeg derefter isolere de SQL-udsagn, som det program indsendte, så jeg kan være meget applikationsfokuseret snarere end databaseteknologifokuseret, når jeg dybest set kigger og ser databasoptimering og databasekonfiguration. Jeg vil bare bringe dette til din opmærksomhed. Ofte er mange store organisationer opdelt i infrastruktur-DBA'er og applikations-DBA'er. Præcist, ved at vise applikationen såvel som ressourceforbruget, er vi faktisk i stand til at bygge bro over gabet, og denne løsning er nyttig for begge typer op-DBA'er på systemet.
Nu er denne del virkelig slags vores show off, hvad vi kan gøre på databaseniveau. Og hvad der skete her, var, at vi havde en skærmfrysning, der var et valg fra PS_Prod, og hvad vi gjorde, er at vi klikker på denne melodiknap, og hvad det gør, er det bringer os ind i dette SQL-arbejdsområde. Nu, for jer mennesker, der ikke er DBA, ser dette måske ikke rigtig spændende ud. For mennesker, der er DBA'er, kan du synes dette er ret spændende. Hvad der blev vist her, er varigheden af denne særlige SQL-sætning versus ændringer på systemet. Og dette viser onsdag, torsdag, fredag, varigheden er ca. 2/10 af et sekund. Lørdag og søndag fungerer dette firma ikke - heldige dem. Kommende mandag var der en ændring: Adgangsplanen blev ændret. Den nye adgangsplan er pludselig vej op her. Det er faktisk langsomt nok, hvilket resulterer i en frysning af skærmen.
Hvis jeg nu er en DBA, har jeg brug for yderligere oplysninger for at kende den rigtige grundårsag. Jeg har brug for at kende de valgte databaseaptimeringsværktøjer, der er lavet. Så præcise tilbyder denne sammenligning, der viser udførelsesplanen, der var hurtig og effektiv, når ting kørte godt, samt udførelsesplanen, der var langsom og ineffektiv. Dette filterforbindelse er almindeligt for DBA'er, der kører PeopleSoft. Hvad filter gør er det ser ud for hver række i en tabel, det ser på hver enkelt række i sammenføjningstabellen - der tager en masse CPU. Det er ekstremt ineffektivt, fordi der ikke er nogen filtrering af bare at se på den delmængde af rækker, der er nødvendige, men af SQL-sætningen og denne ineffektivitet resulterer i den langsommere udførelsestid. Derfor sænker de i sidste ende PeopleSoft-panelet i skærmfrysning, og Precise var i stand til at komme til den rigtige grundårsag, som du aldrig ville vide om, medmindre du havde et værktøj, der afslører applikationskoden, SQL-udsagnene og så videre.
Det var lidt af det dybe dykke. Vi vil nu trække udsigten op til 10.000 kvadratmeter udsigt over instrumentbræt. I Precise er dashboards virkelig ikke for det tekniske team - det er virkelig for dig at bruge til at dele information med operationer, måske med applikationsteamet, måske med din kommandokæde. Og så kan et sæt dashboards muligvis vise PeopleSoft-paneler og klienttiden, så du ved, hvad slutbrugeroplevelsen er. Et andet kontrolpanel er muligvis blevet konfigureret til operationer, og dette instrumentpanel kan måske se på, hvor der var nogen advarsler, der fryser? Vi har faktisk alarmer på operativsystemet, internettet, WebLogic, smoking og database niveauer. Ingen advarsler her, gennemsnitlig responstid. Du kan se, at der løb omkring en tredjedel af det andet. Her kan jeg faktisk se på min infrastruktur vise mig alle VM'er i mit miljø, og jeg kan begynde at komme ind i behandling, belastningsbalancering, og jeg kan også se på mine Tuxedo-domæner. Dette særlige miljø har seks forskellige domæner, så jeg kan se disse domæner, og jeg kan faktisk komme ind på webbalancering.
Nu er Precises historiske arkiv, hvor PMDB, databasen med performance management, har masser af metrics. Og sommetider vil nogen vide om browsertilgangstællingen, eller du kan gøre adgangstællinger efter browsertypen eller ydelsen efter browsertypen. Der er en hel masse ting, der kan gøres for at give yderligere synlighed på dit system.
Her, denne, ser vi faktisk på WebLogic hukommelsesanvendelse, og du kan se dette dejlige savtandmønster, hukommelsesforbruget. Der er affaldssamlingen, den henter un-referencerne. Det går op igen, og så dette er et meget flot mønster, som du kan lide at se. Så dette er slags at se på PeopleSoft-miljøet som en samling af undersystemer, og dette ville være passende til operationer. Det mest basale spørgsmål er, "Nå, hvad sker der på serveren?" Det præcise har alt dette synlighed. Det giver også servermålinger. Og her er du faktisk i stand til at måle CPU, hukommelse, I / O, server, brugere på systemet, og så har du den fulde synlighed. Og det er en måde - det kombineret med langsigtet tendens - er, hvordan folk bruger Precise til kapacitetsplanlægning.
Og jeg vil bare smide en lille note der. En butik har typisk så meget budget til hardware, til server, så meget budget for personale. Hvordan skal du investere, hvor skal du placere dine væddemål? Brug af Precise får du en fordel, fordi du ser, hvordan lagringsundersystemet bruges. Hvis du laver en masse tilfældig I / O, viser Precise dig det. Det vil hjælpe med at retfærdiggøre investeringen i faststoflagring. Det kan være mere vigtigt for din butik end at købe yderligere CPU, hvis CPU-anvendelsen tilfældigvis er lav.
Du ønsker at investere, hvor de rigtige forarbejdningsflaskehalser er, hvor du faktisk kan få en udbetaling. Og ved at præcisere alt fra applikationskodningens effektivitet helt ned til kapacitet tillader vi dig at vurdere og dokumentere, hvor disse behov er med tal.
Nu er det sidste stykke alarmerende, og alarmeringen er faktisk sådan, dette startede. Huske på, at? Vi så en advarsel om, at der var en performance-SLA, og vi så, at en WebLogic-instans var nede. Så lad os se på alarmeringsgrænsefladen. Og igen, hvad sker der? En af de ting, jeg vil påpege ved denne opfattelse, er, at Precise ikke kun har disse præstationsalarmer og statusalarmer om tilgængelighed, vi har også trendalarmer. Årsagen til, at trending-advarsler er vigtige, er, at hvis dit system er inaktiv eller har en eller to brugere, sandsynligvis fungerer tingene godt. Det er først du begynder at tilføje brugere, og de begynder at udføre mere og mere aktivitet, som du begynder at kæmpe for data, for ressourcer på Tuxedo-niveau, på WebLogic-niveau, på netværksniveau, på databaseniveau. Og den påstand resulterer i forringelse af resultater, og så kan du endelig krydse en linje, og det er en præstationsalarm, og det er dybest set, at du ikke opfylder SLA-målene for organisationen. Og så disse sæt advarsler er meget pæne.
Web-niveauet, over på venstre side, web-niveauet måler faktisk slutbrugeroplevelsen, og så kommer du ind i teknologierne i den underliggende applikationsstabel. Dette er slags vores arkitekturskærm, hvordan vi gør alt dette. Ideelt set vil du gerne have en præcis server, der er uafhængig af det overvågede miljø eller miljøer. En præcis server kan håndtere adskillige applikationer.
For PeopleSoft og Oracle og DB2-databasen kræver vi en lokal agent. Hvis dit PeopleSoft-miljø back-end af SQL Server, er der en mulighed for at gøre agentløs. Vi har også agent uden Sybase. Hjertet i vores sikkerhedsmodel er, at data indsamles herover, mens brugere af Precise autentificerer til Precise. Det er helt separate processer, separate legitimationsoplysninger, separat godkendelse og så det er en del af vores sikkerhedsmodel. Og der er yderligere detaljer.
Jeg tror, at dette er nok af en introduktion til arkitekturen for nu. Hvis der er nogle brændende spørgsmål, bedes du spørg dem, som Eric havde nævnt.
Ligesom en hurtig sammenfattning er denne løsning designet til 24 af 7 i produktion. Det anbefales stærkt, at du bruger os i QA. Hvis du laver egen udvikling, skal du begynde at bruge os i udvikling. Gik til at oversætte den komplicerede URL, URI til et PeopleSoft-panelnavn. Når jeg taler om produktion, er vi ekstremt lavt, så du har synlighed, du ved altid, hvad der sker, og identificerer slutbrugeren.
Jeg var ikke nødt til at gå ind og definere disse transaktioner - der er bare naturlige forbindelsespunkter fra browseren, URL'en, indgangspunkterne, webserverforbindelsen til WebLogic, invitationen ned til den, der indeholder SQL-sætningen. Så er vi i stand til at fange SQL-sætningen, og hvad den gør. Precise er databas intelligent, og jeg tror, at dette er en markant faktor for os, og det giver din DBA mulighed for at samarbejde, forbedre applikationssynligheden.
Det sidste punkt er, fordi der altid var tændt, vi samler altid, du kan altid måle før og efter og kvantificere forbedringen, eller i det sjældne tilfælde kan du have ændret ydeevnen, ville du vide det og du kunne rulle det tilbage med det samme . De fleste af vores konkurrenter, hvad de gør, er, hvis du har brug for at se yderligere oplysninger, du er nødt til at tænde for yderligere synlighed og typisk at yderligere synlighed medfører en hel del omkostninger.Med Precise har du altid synlighed, og du kan altid løse problemet. Så hvis du skal gå til det præcise websted, skal du tjekke et af de præcise produkter, om det er præcist for Oracle. Vi er opført som præcis applikationspræstationsplatform, og der er en knap der for at anmode om en demo.
Faktisk, hvis jeg deler min skærm, tror jeg, at jeg måske bare navigerer der for at vise dig, hvordan det ser ud, bare så du kan se dette lige på forhånd. Her er IDERA-webstedet. Du går til produkter. Jeg kan vælge en af disse præcise komponenter, og jeg vil bare se det i aktion. Dette starter vores proces til deling af yderligere oplysninger, der kan være vigtige for dit websted. Eller hvis du gerne vil vide mere om migrering til det flydende brugergrænseflade, er du velkommen til at kontakte os.
Og hvilket Eric, jeg gerne vil sende stafetten tilbage til dig.
Eric Kavanagh: OK, god handel. Jeg må sige endnu en gang - en temmelig omfattende og imponerende præsentation der, Bill. Du nævnte en hel masse ting, som jeg kunne lide at spørge om. Vi har ikke meget tid - cirka ni minutter - og jeg kan lide Matt til også at få en chance for at stille et par spørgsmål og have mindst en eller to fra publikum.
Men du nævnte noget, som jeg syntes, det var meget, meget interessant med hensyn til, hvordan Precise kan hjælpe med indkøb til IT-teamet, fordi du kan påpege, du kan gøre en sag over for hvem, der træffer den beslutning, at det, du har brug for, er mere solidt opbevaring, for eksempel, eller hvad du har brug for er forbedringer af netværket eller uanset hvad der måtte være tilfældet. Men det er en stor aftale. Ser du ofte virksomheder, der anerkender det og bruger det, eller prøver du at evangelisere noget mere?
Bill Ellis: Nå, faktisk begge dele, og tinget er, at brugsmønstre, selv for et pakkeprogram som PeopleSoft, er brugsmønstrene forskellige på hvert enkelt sted. Jeg havde formuen at udføre en PeopleSoft-migration i en bank, og banker bruger hovedbokssystemet meget anderledes end de fleste organisationer. Du kan faktisk have individuelle transaktioner, der blev foretaget i en filial, de alle posterer til hovedbogen.
Og så snarere end at placere snesevis eller hundreder af hovedbøger, poster du faktisk hundreder af tusinder. Og sådan, hvordan jeg engagerede mig i Præcis, er på grund af brugsmønstre og det gjorde det muligt for os at adressere, men applikationens behov både på et kodeniveau, et konfigurationsniveau og på infrastrukturniveau. Så absolut er jeg en stor troende, og det vil jeg også evangelisere, fordi du ikke skulle tage hardware-beslutningerne simpelthen baseret på anvendelse. Du skal basere det på dit miljøs behov.
Eric Kavanagh: Og der er et spørgsmål fra en deltager, og så, Matt, vil jeg vende det til dig for et spørgsmål eller to. Det er godt, og det er sjovt, fordi det er et stort, langt svar, du kunne give. Deltageren spørger: "Hvordan indsamler du ydelsesmetrik ved brugers slutning efter installation og under test?"
Jeg synes, du har gjort et temmelig godt stykke arbejde med at dykke ned i, hvor dyb og rig disse præstationsmål er. Du talte om endda et sekund for nogle af disse ting sammenlignet med hvert femte minut eller 10 minutter. Thats når du vil få det detaljeringsniveau, der er nødvendigt for at finde dine svar, ikke?
Regning Ellis: Ja, så det afgørende er, at de enkelte indsamlere af præstationsinformationen er teknologibaseret. Så når vi udfører en installation, er vi nødt til at vide, hvordan din applikationsstack er bygget, startende med operativsystemet, dets version, hvilken version af Tuxedo, WebLogic, hvilken version af People-værktøjer, som du kører.
Og det er virkelig designet af de agenter, der gør det, den dataindsamling, der giver os mulighed for at afsløre, at niveauet af synlighed Precise giver. Og den synlighed, tror jeg, undertiden kan være lidt skræmmende for folk. Men hvis dit mål er virkelig at komme ind og forbedre tingene og tage ydeevnen til 11, er det virkelig det synlighedsniveau, du gerne vil have. Og hvis Precise kan give det og dets lave omkostning, er spørgsmålet hvorfor ikke? Så jeg synes, det er et godt spørgsmål, og kontakt os venligst, hvis du gerne vil diskutere det yderligere.
Eric Kavanagh: Ok godt. Og Matt, havde du spørgsmål?
Matt Sarrel: Jeg tror, jeg har det godt. Jeg mener, jeg har beskæftiget mig med WebEx, der går ned her, så.
Eric Kavanagh: Åh nej. Vi har brug for præcist for at forstå nøjagtigt hvorfor.
Matt Sarrel: Ja, jeg gætte det spørgsmål, som jeg havde tænkt på, mens du talte, Bill, var, hvis du kunne diskutere lidt om, hvordan flere hold kan komme på den samme side, når fejlfinding af præstationsproblemer, fordi jeg ved, at det er noget, der kommer op og igen er hvem, der er ansvarlig for hvad og hvordan kan alle arbejde sammen for at levere den bedste kvalitet til medarbejderne.
Regning Ellis: Ja, så it-medarbejdere har en tendens til at være dyre. I de fleste butikker er du opdelt i teams baseret på teknologi i betragtning af teknologiens kompleksitet. En af de store ting, der sker, er at der er et præstationsspørgsmål, og der er mange gange konflikten, krigsrommet samles. Og det er, hvor alle har de målinger, der på en eller anden måde frigiver deres niveau, fordi de ikke har det. De ser på hvad der sker på WebLogic-niveau snarere end hvad der sker på transaktionskodeniveau. Eller de ser på databaseniveauet snarere end transaktionens individuelle SQL-sætning.
Og ved at være i stand til at præcisere problemkategorien og problemkoden inden for det niveau, hvad det gør, er det at frigøre de andre hold til ikke at gå eller bruge tid på ressourcer på udkig efter et problem, der ikke er inden for deres område. Hvis det er et databaseproblem, skal du gå til DBA med de oplysninger, de har brug for for at løse problemet. De er glade for at gøre det.
Men spild heller ikke Tuxedo, WebLogic assistance-teamet med fokus på problemerne i databasen. Ligeledes, hvis problemet tilfældigvis er i WebLogic-konfiguration, skal du ikke tage DBA's tid i et slags krigsrum, der prøver at forsvare sig selv. Bare gå og rettet problemet i WebLogic.
Vi finder ud af, at it-medarbejdere værdsætter præcise på grund af tidsbesparelser, fordi typisk disse krigsrum ikke er budgetteret i tidsplanen for hver FTE-organisation. Dens slags som ekstra tid. Og det er virkelig vigtigt at kunne håndtere disse spørgsmål mere effektivt. Og for den organisation, der rullede den flydende brugergrænseflade ud, var det meget vigtigt ikke for individuelt personale eller teams at være i stand til at skalere produktionen og løse de problemer, de faktisk oplever i produktionen, men faktisk for IT-styring generelt, fordi det ville have været rigtig dårlige nyheder hvis de skulle rulle tilbage. Så det store spørgsmål, fordi det ikke kun er teknologien. Det handler virkelig altid om folket.
Matt Sarrel: Rigtigt, det er menneskerne og processerne. Ja, det var det eneste spørgsmål, der kom op for mig under demoen. Hvis der er andre fra publikum?
Eric Kavanagh: Ja, jeg kaster bare en sidste til dig, Bill, og Matt talte om dette kort i sin præsentation. Vi er begyndt at se denne afgrøde op. Det er stadig meget fremadskuende, men containere og brugen af containerisering og Docker og ting af den art, hvor stort af en kurve kaster det det jer?
Bill Ellis: Så ordet betyder forskellige ting afhængigt af forskellige teknologier. Så vi udvikler vores produkter til at passe containere på databaseniveau og på applikationsniveau. Og som en del af det er det slags hele miljøet med bevægelser, skyen, og vi fungerer inden i skyen. Men der er en opdagelsesproces, og så afhængigt af hvordan disse applikationer - inklusive PeopleSoft - udvikler sig, udvikler vi vores overvågningsløsning, så vi kan give det dybdesniveau, der har været så værdifuldt i fortiden.
Eric Kavanagh: Ja. Og jeg må sige, hver gang jeg ser disse demoer er jeg bare forbløffet over den granularitet, du har, og det er det, du har brug for for at kunne skabe forståelse, og du har brug for en vis uddannelse omkring, hvad der er den normale situation, hvad standard.
Og jer folk tilbyder en masse indhold omkring det - at hjælpe folk med at identificere, hvad der er normalt, hvad der ikke er normalt. Du talte om tendenserende alarmer, for eksempel, dette er alle mekanismer, som du kan bruge til bedre at forstå, er noget galt, er noget ikke galt, og så er det selvfølgelig nødt til at bore ned for at finde det, men du har alle dataene.
Bill Ellis: Ja, og det er en virkelig vigtig ting; Jeg tror, Matt havde talt om det. Hvad er normalt? Forskellige miljøer har et andet niveau af normalt. Hvis du kører med avanceret hardware, Oracle-logik og data, er det, der er normalt i din butik, eller hvad der kan opnås i din butik, anderledes, end hvis du kørte under en mindre magtfuld infrastruktur. Så den første ting er at finde ud af, hvad der er normalt, begynde at beregne den baseline, og på den måde kan du begynde at gøre forbedringer derfra.
Eric Kavanagh: OK, det er et godt punkt. Vi har et sidste spørgsmål der kommer ind, det ser ud. Bare et sidste spørgsmål vil jeg kaste til dig, Bill. Er der nogen forskel mellem SQL og databasepræstationsovervågning set ud fra systemniveau og applikationsniveau data? Hvad er forskellen mellem overvågning af SQL og databasepræstation fra dit perspektiv?
Regning Ellis: Nå, der sker intet i en database, før dens SQL-sætning udføres. SQL-sætningskonkurrencen er hvad - kontroller låsning, venting, striden om ressourcer på dataniveau og på SQL Server-niveau. Og så hvis jeg kan se både driveren af SQL-erklæringen og dens indflydelse på systemet, har jeg forårsaget en effekt; Jeg kan sammenkæde, hvad applikationen DBA bekymrer sig med, hvad infrastrukturen DBA bekymrer sig om, indtil jeg virkelig kan få mest muligt ud af det præcise værktøj.
Hvis jeg er en DBA-infrastruktur, og jeg ser på ting som udnyttelse, er jeg virkelig form for styring med en bred børste versus, hvis jeg er i stand til at se på en individuel SQL-sætning, og jeg er i stand til faktisk at minimere ressource forbrug - uanset om det er CPU, hukommelse, I / O - Jeg kan adressere begge sider af den samme mønt.
Eric Kavanagh: OK, folkens. Vi brændte lidt over en time. Stor, stor tak til vores venner på IDERA. En stor tak til Matt Sarrel for at slutte sig til os i dag. Vi arkiverer alle disse webcasts til senere visning, så kom gerne tilbage og normalt på bare et par timer arkivet går op. Så tjek det ud, og alt hvad jeg har at sige er, at jeg elsker disse ting, jeg elsker præcist, jeg elsker at kunne komme ind i ukrudtet. Og jeg kender ikke noget andet værktøj, der giver dig mulighed for at grave rundt i alle disse forskellige stykker og dele af applikationsstakken end hvad folk har på IDERA med Precise.
Med det byder vi dig farvel folkens. Tak igen, vi taler til dig næste gang.