Av Techopedia Staff, 31 augusti 2016
Takeaway: Host Rebecca Jozwiak diskuterar felsökning och effektivitetsdatabaser med analytiker Eric Kavanagh och Dez Blanchfield samt Bill Ellis från IDERA.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Rebecca Jozwiak: Mina damer och herrar, hej och välkommen till Hot Technologies 2016. Dagens ämne, "Ansökan går långsamt? Dags att bli exakt." Och vet vi inte alla för väl de problem som kan hända när saker går långsamt? Det här är Rebecca Jozwiak, jag fyller på för Eric som gör en ny roll här, idag. Ja, det här året är varmt och, du vet, när det gäller teknik, som jag sa, det enda du verkligen inte vill ha är att göra något långsamt, någon del av ditt system. Och bara för att använda ett konsumentexempel, menar jag om du har en restaurang, spelar det ingen roll hur bra maten är, om tjänsten är långsam, kommer du förmodligen inte att hamna tillbaka. Nu är det lätt, typ av, på en restaurang att ta reda på varför något går långsamt. Kanske är köket kort bemannat eller så fanns det något fel med utrustning, eller kanske är servicepersonalen lite lat, och det är lite lätt att identifiera och fixa det.
Men när du tänker på ett datacenter är det en helt annan historia. Det kan vara ett nätverksproblem, en dålig fråga som fastnar saker, applikationsprestanda eller en felaktig kabel kan till och med orsaka problem. Och felsökning med den typen av komplexitet kan vara, du vet, svårt i bästa fall. Det är typ av det vi ska prata om idag. Och vi har som sagt Eric Kavanagh chimat in som analytiker idag. Vi har fått Dez Blanchfield till vår datavetare och vi har Bill Ellis från IDERA, som kommer att prata om sitt företags lösning som hjälper till med hantering av applikationsprestanda. Och med det ska jag överföra bollen till Eric. Eric, golvet är ditt.
Eric Kavanagh: Okej, låter bra, folkens. Och det var faktiskt en fantastisk analogi, för att du talade till svårigheterna eller lättheten med felsökning som kan utföras och du kommer till det. Prestandaproblem härrör alltid från ett slags problem som finns i nätverket. Jag menar, det kan vara så enkelt som till exempel gammal hårdvara, men i slutändan är det alla situationer som kräver felsökning. Det är vad jag ska prata om idag. Och låt oss gå vidare och hoppa på bilderna här.
Här kommer trubbel. Felsökning - det är kul för människor som gillar det, det är det coola. Om du hittar någon som gillar att göra felsökning, håll fast vid den personen, få dem några verktyg för att få jobbet gjort, för riktigt bra grejer om du kan hitta någon som kan komma till botten av något och få saker gjort. Men i slutändan är att felsökning är problematisk och det har alltid varit och det kommer alltid att vara, och om du börjar prata om felsökning, är det du verkligen får på grund av analysen av orsakerna. Vad orsakar problemet?
Tja, om du bara luta dig tillbaka och tänka en sekund till och med på stordatordagarna, fanns det alla typer av problem som kunde uppstå. Och då var du tvungen att ha människor som verkligen visste sina saker eftersom det inte ens fanns bra verktyg för felsökning, så du måste verkligen känna din kommandotolk, och vi kommer att prata om det på en sekund. Och jag glömde faktiskt att lägga in en av mina favoritbilder, jag letar efter det medan vi är på showen idag, kanske under Dezs presentation. Men jag ville visa, för alla som inte har sett det, en av de roligaste brittiska TV-programmen någonsin, det heter "IT-folkmassan." Och när det gäller felsökning är den irländska mannen, som är en av två IT-personer i hela företaget, säger alltid samma sak varje gång ett samtal börjar, "Har du försökt stänga av och slå på den igen?" Så försök att stänga av och slå på den igen. Du skulle bli förvånad över hur ofta den enkla saken kan lösa vissa problem.
De av er som har gjort felsökning hemma kanske med dina föräldrar eller vänner, förmodligen inte med dina barn eftersom de tenderar att veta vad de ska göra, stäng av och slå på den igen. Men oavsett, felsökning är inte lätt, det kommer aldrig att bli lätt, men vi kommer att prata idag om några av de saker du kan göra för att göra det lättare. Så kommandoprompten - ja, jag är verkligen gammal nog för att komma ihåg de första dagarna av datorn när allt du hade var kommandotolken att göra DIR, Enter. Det är vad det skulle se, katalog med filer och känna sig positiva att det faktiskt fick något kommando gjort, eller hur? Dez, naturligtvis, vår datavetare, han vet hur han använder kommandotolken. Och om du kan använda kommandotolken är det bra saker eftersom de flesta av oss bara dödliga använder någon form av ett GUI, ett grafiskt användargränssnitt, men det finns alltid något, det finns alltid någon koppling mellan GUI och kommandoraden under. Och bara för att ge dig ett slumpmässigt exempel, om du vill veta hur mycket kod som några av de grundläggande programmen som finns bakom i dokument i dag, gå till den senaste versionen av Microsoft Word, skriv "hej värld" och sedan "spara som HTML. ”Och öppna sedan det resulterande dokumentet i en textredigerare, och du kommer förmodligen att se sidor och sidor med taggar. Det kallas koduppblåsning, och koduppblåsning är inte riktigt bra för felsökning, bara för att vara trubbig.
Naturligtvis kom klient-server med och det var bra grejer. Och på ett sätt går vi lite tillbaka i den riktningen, men tänk bara på komplexiteten som följde med situationen, nu är problemet, är det på klienten, är det på servern, är det nätverket? Var är det? Dessa webbplatser som bara tänker på virus, och när ett virus kan komma in i ett i ett nätverk, vad kan hända? Det kan gå var som helst. Dataöverträdelser är galen i dag. De orsakar prestandaproblem. Vi har haft ryska hackare som vi kan identifiera med IP-adressen. Vi är ganska säkra på att de är ryska, eller att de är väldigt nära, eller att de är väldigt snygga ukrainare eller polska eller till och med amerikaner som använder proxyer. Men vi har haft hackare som kommer in på vår lilla gamla webbplats, Inside Analys, genom åren och orsakar alla typer av problem. Saker slutar bara fungera, du kan inte få saker gjorda. Saker som brukade fungera fungerar inte. Hur vet du? Hur vet du vad det är? Precis som ett annat exempel här är en mycket komplex miljö, det är väldigt svårt att komma in i ogräset och verkligen förstå hur saker och ting fungerar för oss, särskilt om du får en hel massa plug-ins. Saker kan bli ganska ganska snabbt. Jag går sällan inför mig själv.
Jag kastade in här, var alltid försiktig med uppgraderingen. Uppgraderingar skrämmer alltid dagsljuset ur mig. Visst operativsystem. Jag minns de dagar då Microsoft faktiskt skulle föreslå att, ja, du kan uppgradera ditt operativsystem från den här versionen till den versionen. Jag försökte några gånger, och det har aldrig fungerat. Kom bara ihåg att ju större, desto mer komplex en miljö är, desto svårare kommer situationen att bli. Och sedan finns virtualisering. Tänk på vad VMware gjorde mot IT. Det revolutionerade IT, men det skapade också detta lager av abstraktioner. Om du har en abstraktion i lager på den grundläggande nivån är det ett helt nytt bollspel, det är en helt ny vaxboll och du måste verkligen ompröva vad du gör och alla gamla verktyg måste ändras. Och nu är det naturligtvis molnet, eller hur? För kunden är molnet bra, eftersom det är väldigt enkelt, användargränssnittet är ganska enkelt, men självklart har du inte så mycket kontroll över molnet. Men för de människor som är bakom kulisserna finns det en hel del saker som de behöver veta och förstå dessa dagar. Miljön har blivit mycket, mycket mer komplex. Och verkligen med e-handel, och du tänker på alla pengar som handlar hand i dessa dagar. Det är därför du inte kommer att hitta mig till förmån för ett kontantlöst samhälle när som helst snart. I första hand här är att situationen blir mer problematisk med dagen.
Och att hålla prestandan optimal kommer alltid att innebära något element i felsökning. Jag bryr mig inte om vad någon säger till dig, det finns inget perfekt verktyg, det finns ingen silverkula och det kommer aldrig att bero på - i ett annat intressant perspektiv här - vi lär oss fortfarande att tala silikon. Vi lär oss fortfarande att förstå hur till och med nätverk fungerar på den skitna nivån. Om du tittar på systemhanteringsprogramvara blir det ganska bra i dag. Men ändå, du tittar på linjer som går upp och ner och du tittar på representationer av verkligheten, det kommer att ta en person som vet vad som händer för att passa ihop ledtrådarna som du kan stirra på optimala verktyg för att kunna förstå vad som fungerar och vad som inte är det och det är mycket test och fel, bara för att vara trubbiga. Med det ska jag överlämna det till Dez Blanchfield och sedan får vi höra från Bill Ellis från IDERA, som kommer att skämma oss med hans kunskap. Med det, Dez, ta bort det.
Dez Blanchfield: Hej, tack Eric. Tack. Ledde fint in i mitt lilla segment. Min titel, "Performance Art", tycker jag är oerhört lämplig i samband med det vi pratar om idag, eftersom vi på många sätt tänker på performancekonst, vi tänker på dans och musik och andra kreativa saker. Och ärligt talat oftare än inte, om vi löser problem och i mycket storskaliga IT-miljöer och affärssystem finns det verkligen ett element av konst och ofta svart konst, eftersom situationen enligt min erfarenhet under några år plus är att moderna appstackar ökar mycket snabbt komplexiteten i en takt som vi aldrig har sett förut. Och vi kämpar uppriktigtvis för att hålla jämna steg och det finns organisationer som till exempel Uber, och vad som helst, och Pokémon Go-utvecklingsgruppen, jag menar att de upplever tillväxt och komplexitet och ökad komplexitet i hastigheter som bara är astronomiska. Det finns inte ens böcker skrivna om det eftersom vi inte hade tänkt den tillväxtnivån. Min uppfattning är att kärndefinitionen av en applikationsstapel har förändrats exponentiellt och jag kommer att förklara varför jag tror att så är fallet och sedan leda in i utmaningen till hands att mina goda vänner på IDERA verkar ha en lösning att lösa .
Mycket kort, vi vet alla dessa men bara för att sammanfatta dem, du vet, under de första dagarna hade vi det jag kallar, applikationsarkitektur, version 1.0. Det var en serverdator, i detta fall stordatorn med en massa terminaler anslutna, det var relativt enkelt att diagnostisera problem om du inte såg saker på terminalen - du kunde spåra kabeln mellan terminalen och sedan serverdatorn, och det var antingen nollkabel eller en kontakt eller något problem om det inte var relaterat till terminalen, och du ser saker på skärmen, det var ganska lätt att räkna ut att de saker som orsakade problemen var i maskinen själv. Och du kunde sakta diagnostisera var i stacken som var från hårdvaran hela vägen upp till programvaruskiktet och användargränssnittet. I det jag kallar version 1.1 gjorde vi den lite mer komplex. Vi placerade enheter i mitten så att vi kunde sätta fler terminaler på plats. Och de var en sorts kommunikationsenhet och ofta var de muxes eller multiplexers och de skulle antingen köra över dedikerad linje eller en uppringd linje och så hade du en mainframe på en avlägsen plats - det kan vara mellanstatliga eller internationellt - och någon enhet ansluten via en SMA-länk eller någon slags WAN-anslutning och dessa terminaler fungerar fortfarande på samma sätt. Men du hade lite mer komplexitet eftersom du var tvungen att ta reda på om problemet stod mellan terminalerna och kommando-enheten eller kommando-enheten och stordatorn. Men stacken förblev relativt lika i stordatorn.
Version 1.2, lite mer komplex igen eftersom nu har vi lagt till fler enheter, vi lagt till skrivare och andra saker, och vi grupperade dessa saker, och jag tänker på en front-end-processor som skulle hantera alla problem med enheterna lokalt, skrivare och terminaler och så vidare med stordatorn den avlägsna änden. Lite mer komplexitet. Men återigen var det konsekventa temat för stordatorn apparna som körs lokalt, så att problemlösningen förblev ganska lika inuti applikationsstacken. Och sedan hade vi människor med färdigheter som körde ut problem med terminaler och skrivare och klusterkontroller. Men sedan komplicerade vi saker och vi byggde nätverk och plötsligt introducerar samma typ av arkitektur ett nätverkslager. Helt plötsligt hade vi en nätverksomkopplare, och arbetsstationer var mycket mer komplexa. Och den här versionen av arkitektur hade vi ofta grafiskt användargränssnittsappar på arbetsstationen. Inte bara hade vi en server som kör appstacken, men vi hade också en annan bunt med applikationer som körs lokalt, och naturligtvis samma grundmodell för enheter som ansluter till en server. Sedan tog vi ett kvantesprång till den nyare modellen för det jag kallar 2.1, där vi tog app-stacken och vi gjorde det mycket mer komplex, mycket svårare att diagnostisera. Och vi introducerade mycket fler enheter i front-end, på webbläsare och datorer och mobila enheter, så vidare. Och här började applikationsbunten sedan dyka lite djupare in i integrationen som operativsystemet och hypervisorn.
Den här bilden här på höger sida har vi hela stacken inklusive nätverksinfrastruktur, lagringsservrar, virtuella maskiner, operativsystemet och sedan de traditionella tre nivåerna av databasmetallverksapplikationer etc., framtill till höger. Att diagnostisera applikationsproblem och prestandaproblem på den här modellen blev bara mycket svårare. Det finns så många fler rörliga delar och att försöka borra ner igenom den stacken var bara, du vet, blev en mardröm och du var tvungen att involvera ytterligare kompetensuppsättningar och organisation för att hantera det. Det var inte bara ditt applikationsteam längre, plötsligt hade du nu infrastrukturfolk, du hade databasspecialister, rent bara arbetade med databaser och ingenting annat - i motsats till en systemprogrammerare som visste sig vägen runt databaser. Nu har vi ett scenario där IT-avdelningar måste hantera en betydligt bredare komplexitet av "som en tjänst" och det där världen just exploderade och våra problemlösningsutmaningar blev, gick från att vara en mardröm till bara något som nästan är oacceptabelt på vissa sätt.
Och detta kom till som en lösningsbar skala, vi försöker leverera tjänster kl. Version 3 av vad jag betraktar applikationsstacken - den har introducerat detta som en servicemodell, där traditionell modell på vänster sida, företagets IT-stack, där allt måste hanteras i slutändan som konsument och leverantör av tjänster - från applikationssäkerhetsdatabas, operativsystem, lagring av virtualiseringsservicetjänster, nätverksdatacenter - vi var tvungna att hantera allt, men vi hade tillgång till allt och så vi kunde utskala våra förmågor och tekniska kompetensuppsättningar och vi kunde borra ner genom den stacken och vi kunde hitta saker. Men när infrastrukturtjänsten och plattformstjänsten och mjukvarutjänstmodellen kom med, plötsligt blev vår åtkomst till back-end-infrastrukturen, vår åtkomst till plattformarna och verktyget vi levererade tjänster från tagna från oss. När vi började konsumera infrastrukturtjänster hade vi bara de fyra bästa delarna från operativsystemet, databasen, säkerhetsmiljöapplikationsstacken och ovan, tillgängliga för oss. Allt under det var svart magi. Och det blir ännu mer intressant när du flyttar till plattformstjänsten eftersom du bara hanterar applikationsbunten.
När du kommer till programvara som en tjänst, och en traditionell modell av detta är webbmail eller internetbank, är allt du har tillgång till en webbläsare, så att försöka diagnostisera vad som ligger bakom det är oacceptabelt, definitivt. Och jag har uppdelat detta i tidszoner, i tidsperioder eller tidsområden om du gillar eller generationer, i att från vänster till höger har vi gått från en sorts pre-2000-tal och den traditionella stacken där vi hade tillgång till hela miljön och vi kunde borra ner genom det. Men med tiden blev det mer och mer komplex. Till början av 2000-talet till mitten av 2000, till slutet av 2000 till dagens dag, där vi har gått från infrastrukturtjänst, plattformservice, mjukvarutjänst, till nu hänvisar vi i huvudsak till en företagstjänst. Och komplexiteten har ökat dramatiskt. Det finns så många fler rörliga delar. Men tillgången på färdigheter blir svårare och svårare och mer och svårare att utnyttja. Att hitta personer med rätt kompetensuppsättningar med rätt tillgång till rätt verktyg för att komma och dyka in i denna stack och ta reda på var är det som går långsamt. Är det min bärbara dator eller mitt skrivbord, är det min telefon eller min surfplatta, är det min anslutning över 3 eller 4G eller min dedikerade länk med ADSL eller ISDN vad det än skulle vara? Eller till och med uppringning, även om det är mindre och mindre fallet idag. Är webbservern slut, är det något inne på webbservern? Är det appservern? Är det något kring minnet och disken med CPU och nätverksprestanda på applikationsservern? Kör databasen där inne?
Och du kan föreställa dig, du ritar den här bilden mycket snabbt av komplexiteten som börjar expanderas på samma sätt som en big bang-bild, av denna ständigt ökande bubbla som vi försöker få våra armar runt och har färdigheter att dyka in i och kunskapen och därmed att dissekera och dra isär. Och vi är väldigt mycket nu i den era där, du vet, människor inte kan hantera den fysiska skalan, även om du har förmågan att dra databasmiljön isär och dra den databasen isär och dyka in i detalj i databasen. Antalet databaser du måste hantera nu växer snabbt. Allt drivs nu av en databas. Mycket få applikationer i dag drivs inte av en databas. Och typerna av databaser växer också snabbt. Det är inte bara de traditionella SQL-databaserna, ibland dess SQL, ibland dess icke-SQL, ibland är det en grafdatabas, ibland är det en dokumentdatabas. Och det finns alla dessa olika typer av funktioner som dessa olika typer av databaser har och som ett resultat av var och en av dem har olika prestandautmaningar och olika prestandakriterier. Loggningsdatabaser och dokumentdatabaser fungerar mycket, mycket annorlunda och utför en annan funktion än en traditionell ACID-kompatibel, ANSI 92-kompatibel SQL-databas. Och de typer av saker som vi lagrade där inne.
Vi är på en punkt, i mitt sinne, där - och jag tror Eric hänvisade till detta - att människor kämpar för att hålla jämna steg med komplexiteten i det vi bygger och den hastighet som vi bygger, och vi Vi är nu vid den punkt där det enda sättet för oss att hantera denna infrastruktur, och det enda sättet att övervaka och fördjupa de problem vi står inför, är med verktyg och rätt verktygstyper. Och sedan alltid rätt generation verktyg. Verktyg som faktiskt förstår back-end infrastrukturen. Det är inte OK längre bara att kasta en SQL-bildskärm eller ett SQL-frågaverktyg på något och börja dra isär en fråga och se vad som får den att fungera. Vi behöver faktiskt ett verktyg som förstår bildandet av frågor och lämpligt sätt att skapa frågor, och de lämpliga sätten för frågor att prata med infrastrukturen i slutändan, och hur de presterar när de gör det. Och att titta på tidpunkten för dessa interaktioner och i vilken ordning de sker.
Och det är en mycket mer komplex utmaning och det leder mig till min frågeställning för roundup, och det är att när komplexiteten i app-staplarna vi utvecklar ökar, behöver prestationsverktygen och de verktyg som vi använder för att hantera dessa, nödvändigtvis behöva att bli allt smartare och mycket mer kapabla att titta på fler saker. Men också mycket smartare på hur de fördjupar vad som körs i slutet och vad de kan upptäcka om det och eventuellt till och med någon form av analys som utförs för att förstå att interaktioner och prestanda, levereras och varför den presterar långsammare eller snabbare.
Och med det kommer jag att skicka till vår kära vän från IDERA, Bill Ellis, och se vad han har att säga idag om hur de löser problemet. Bill, över till dig.
Bill Ellis: Okej. Jag heter Bill Ellis och mycket tack. Vi ska prata om att min ansökan går långsamt, det är dags att bli exakt. Låt oss se vad Precise, en IDERA-produkt, kan göra och hur det kan hjälpa dig. Många gånger ser du bara att det har uppstått ett prestandaproblem eftersom en slutanvändare har ringt dig, och det är verkligen ett stort problem i sig själv. Av alla inom IT visste ingen förrän telefonen ringde. Nu är nästa stora problem hur vi hjälper just den enskilda individen och det är verkligen inte ett triviellt problem. Det finns en takeaway härifrån. Det är utöver denna bild, det är utöver de andra. Och jag vill att du ska se om du kan få det som det är. Men som vi nämnde, en applikation kräver, förlitar sig på många olika tekniker, applikationsstacken är lång och växer. Och många får åtkomst till en applikation via en webbläsare, och överraskande är det mer och mer bearbetning som händer i webbläsaren med skript etc., och sedan har du naturligtvis nätverket, webbservern, företagslogikkoden och databasen. Vad jag vill att du ska överväga är att varje betydande affärstransaktion interagerar med databasen, oavsett om det är tidskortrapportering, lageruppslag, en inköpsorder, databasen håller på att uppdateras. Och så blir databasen verkligen grunden för prestanda. Och databasen kan naturligtvis slå på eller förlita sig på nedströms lagring. Var och en av dessa tekniker är tätt kopplade och kan se vad som händer. Du måste veta vad som händer för att kunna mäta är avgörande.
En sak som vi finner är att många av våra kunder har ett verktyg och de har ett verktyg för varje teknik, men det de inte har är kontext. Och sammanhanget är i grunden förmågan att ansluta prickarna mellan varje nivå i applikationsbunten, och detta är faktiskt relativt enkelt. Vi brukade ha en begränsning på tolv nivåer, men ändrade i princip den, vi har obegränsade nivåer och vi stöder blandade miljöer så att vi i princip kan bli extremt komplicerade med en exakt lösning.
Nu, på en hög nivå, är detta hur vi löser problemet och det fokuserar på transaktionen, slutanvändartransaktionen från klick till disk, berättar vilka som går långsamt, vilka som konsumerar resurser, men nyckeln är detta - Vi tillåter dig att hämta och användar-ID deras plats och inte bara hela transaktionstiden, men hur mycket tid som läggs vid varje enskilt steg. Tid är prestationsvalutan och den visar också var resurserna förbrukas. Vi vet inte i förväg var problemet kommer att vara, så vi måste ha tillräckliga mätvärden och analyser på var och en av nivåerna för att kunna diagnostisera problemet, var problemet kan vara.
Nu, i dagens presentation kommer jag att fokusera på det här området, jag vill att du ska vara säker på att vi i princip ger samma synlighet på varje nivå i applikationsstacken och det avgörande är att detta kommer att säga oss, vad, var och sedan denna del, detta kommer att berätta varför. Och det är verkligen varför det är helt avgörande för att lösa problem, inte bara veta om dem. Det andra som kom mycket tydligt fram i presentationen var att det är omöjligt att göra detta. Du behöver automatisering. Och automatisering innebär att du har varning, du har något som säger till dig, förhoppningsvis innan slutanvändargemenskapen, att du har en pågående trend, byggt upp avvikelse från trendalarmering. Och sedan erbjuder vi också en linje i sanden, du bryter faktiskt mot SLA. Nu erbjuder du mycket olika information - inte alla behöver konsumera buffén, vissa människor vill bara ha ett lätt mellanmål, det här är sallad och så med det att vi erbjuder en portal kan vi ladda upp information, den behöver bara en viss användare eller ett visst samhälls informationsbehov om prestanda. Programmet kör långsamt, det är dags att få exakt. Vi kommer verkligen att fokusera på fyra saker. Den ena är platsen, ange slutanvändaren. Återigen visar det sammanhanget som kopplar samman prickar och den tredje delen av forskningen att nästan 90 procent applikationsproblem finns i databasen och så det är verkligen ett slags travesty att de flesta prestandalösningar kan berätta ett SQL-uttalande. Men de säger inte varför det SQL-uttalandet kör långsamt.
Och så, varför är alltid det avgörande och Precise är utmärkt att visa varför, för varje nivå och i synnerhet databasen, och bara för att dela lite om vår supportmatris med dig, som vi stöder SQL Server, Sybase, DB2 och / eller bulk. Utseendet och lösningen på lösningen är mycket lik, så om du tittar på flera applikationer, men lite annorlunda arkitekturer. Informationen jag delar här har utseendet och känslan, tillvägagångssättet, det är samma oavsett vilken underliggande teknik som används råkar vara. Exakt är webbaktiverat. Vi kommer in, vi verifierar Precise, och med det går vi in och det första vi kanske vill titta på är prestanda efter plats. Och så kan du faktiskt se de olika platserna där människor faktiskt har åtkomst till avrättningarna. Du kan se om någon övergav en sida innan den återgivits helt, eller om det finns fel.
En sak med dessa applikationer är nu nätverket eller avståndet från applikationsservern gör annorlunda. Det är väldigt lätt att se här att det finns en viss nivå av nätverk. Jag kan se när människor blev upptagna, och sedan en annan intressant sak, vi pratade om hur det finns behandling i webbläsaren, de märker faktiskt att vissa av de olika webbläsartyperna ger en bättre miljö för snabb bearbetning. Och så att du vet om människor får tillgång till via Chrome eller IE, eller vad det än händer, kan du faktiskt hitta ofta att en inversion av webbläsartyp är överlägsen en annan. Nu, ibland har du offentligt möter, du kontrollerar inte webbläsaren, ibland är applikationerna invändiga, där du kan rekommendera människor en webbläsartyp till din slutanvändargemenskap, och så är dessa typer av djupdykbarhet och analys som Precise kan ge. Nu undersöker vi en applikation.
Jag är inte säker på om ni kan se min pekare, men jag ville beskriva er toppgrafen. Y-axeln visar genomsnittlig responstid. X-axeln är tiden över en dag. Och det finns faktiskt ett staplat stapeldiagram och det staplade stapeldiagrammet, det totala visar dig vad prestandan är och sedan visar det en nivå av hur mycket tid som spenderas i varje enskilt steg eller varje individuell nivå i applikationen. Från klienten, via webbservern, är det gröna Java, den här platsen använder vi Tuxedo och ner i databasen. Nu visar den nedre halvan av skärmen de olika webbmenyerna som nås och vi har sedan blandat med bara en liten grön pil som pekar nedåt. Det är i fallande ordning, och det bubblar upp till toppen, webbmenyn börjar visa den. Vi visar faktiskt exekveringstiden, responstiden för varje enskild teknik och sedan finns det faktiskt ett stapeldiagram för var och en av dessa webbmenyer och så får vi börja få en uppfattning om vad som händer. Kom ihåg att vi sorterade allt med en slutanvändare som skulle ringa, men hur hittar jag slutanvändaren? Jag kommer in här, jag öppnar en meny som gör det möjligt för mig att filtrera på en viss användare, så jag ställer den användaren till Alex Net, klickar på OK och sedan fokuserar vi på bara aktiviteten från Alex Net. Vad det nu gör är att det gör det möjligt för IT- och IT-hantering att vara direkt lyhörda för en slutanvändare och särskilt att de tittade på innehållshantering som hade sex avrättningar med en svarstid på drygt tre sekunder. Tja sekunder är ganska bra, det är inte hemskt, men det kanske är långsammare.
Vad jag kan göra med detta är att jag kan skära och tärja denna information på olika sätt. Jag kan säga, är den här transaktionen långsam för alla? Är det långsammare idag för Alex än det hade varit igår? Är det långsamt för alla användare på en viss plats? Eller, och vad det gör är att det tillåter mig att typ av skiva och tärningar och få en uppfattning om vad som händer, hur universellt problemet är och det är väldigt viktigt att kunna identifiera slutanvändaren, eftersom det inte bara handlar om mjukvaran, infrastrukturen, det handlar också om hur slutanvändarna utövar applikationen. Ofta kan du ha en ny anställd eller någon med en ny jobbfunktion, och de känner inte till vissa SAP-skärmar eller vissa PeopleSoft-paneler och de behöver lite pekare, kanske lämnar de fält tomma eller sätter in jokertecken och de " tvingar stora resultat att returneras från databasen. Men med användar-ID kan du faktiskt ringa dem innan de ringer dig. Den andra saken som vi finner är att när användargemenskapen är medveten om att IT vet vad de gör, är det många gånger att de blir bättre uppförde och många problem, många saker som hade varit problem, bara slags förångas, eftersom människor beter sig, fungerar bara lite mer försiktigt. De använder systemet med större omsorg.
Slutanvändaridentifieringen är avgörande. I slutändan är det viktigt att IT kan hjälpa en viss slutanvändare. Vad vi nu har gjort här är att vi har gått till fliken "Flow". Du kan se det i det övre vänstra hörnet. Och vi har fokuserat på en viss komponent på webbmenyn. Och på höger sida är en analys av den specifika transaktionen, och så överst är det faktiskt webbläsaren och sedan Visa, bara för att bli bekant med lite av ikonerna i GUI är för webbservern, så vi kan se attributpunkten. Och då är "J" för Java och "T" är för smoking och "Q" är naturligtvis SQL. Det kontanta värdet identifierar i princip ett visst SQL-uttalande. Tänk på vad det här gör. Vi har identifierat en användare till en transaktion, till den underliggande applikationskoden, inklusive de enskilda SQL-satserna. När jag nu tittar på de enskilda SQL-uttalandena kan jag se att den totala responstiden är ansvarig för cirka sex procent, och när de lägger till de fyra bästa SQL-uttalandena, tog de ungefär en fjärdedel av transaktionen tid.
Ofta är databasen den enklaste att manipulera. Det är oftast lättast att få en billig och mycket överlägsen prestanda. Nu måste jag gå lite djupare för att ta reda på vad som händer och vad, jag vill att exemplet kan göra är att faktiskt avslöja det enskilda SQL-uttalandet, och du vet att jag nästan kan garantera dig bara genom varje skott på linjen hade något slags databasverktyg och vad databasverktyget gör men bara titta på en teknik isolerat, är att du tittar på, fokuserar på den teknologins hälsa. Och många gånger tittar folk på en topp tio lista. Nu är detta SQL-uttalande ganska snabbt, det kommer inte att vara på topp-tio-listan, men det är SQL-uttalandet som denna transaktion är beroende av. Och så det jag kan göra tillbaka vid det ordet, sammanhanget, är nu att jag kan föra detta till djupblickens uppmärksamhet men i samband med det enskilda SQL-uttalandet.
Nu kan den personen öppna upp Precise i samband med det enskilda SQL-uttalandet, och Precise fångar den verkliga exekveringsplanen som den använder, exekveringstiden detta är viktiga saker för DBA, kommer faktiskt att visa, du kan se att 50 procent av tiden läggs på att vänta på lagring. Femtio procent av tiden används i CPU, så du börjar få idéer om var tiden går, hur jag kan vinkla den tiden ner, och tanken är att ge människor alternativ, eftersom olika svar har olika kostnader och risker förknippade . Helst är vi ute efter den lågriskiga och billiga lösningen på ett problem. Nu när SQL-uttalandet spåras av ett hashvärde och det finns i den vänstra typen av mitten av skärmen den lilla "Tune" -knappen, och vad det kommer att göra, är att det tar dig till en SQL-uppgift. Och den här SQL-uppgiften är en typ av en förbyggd arbetsbänk och vad det här gör, är det att jag verkligen kan analysera specifikt vad som påverkar SQL-uttalandet utifrån exekveringsplanen. Exekveringsplanen väljs av optimeringsprogrammet när uttalandet analyseras, det - tillbaka till matanalogin, det är receptet som följs för att lösa SQL-uttalandet.
Och vissa recept är mer komplicerade än andra, och därför ger vi resultat. Och det kommer faktiskt att visas här, hej, mycket tid det gör sekventiell I / O på ett visst index. Och se nu när du går tillbaka till syre och följer detta index. Har indexet defragmenterats nyligen, vad är hälsan med om? Vilket bordsutrymme bor det i? Är tabellutrymmet segregerat från tabellen det refererar till? Och så det börjar ge dig alla typer av idéer om hur du kan lösa problemet. Nu uppenbarligen, du vet, vi bygger i ett index. Det är mycket lägre risk, mycket lättare än kanske att flytta ett index från ett tabellutrymme till ett annat bordutrymme, så det vi vill göra är typ av uppbyggnadsalternativ, så att vi kan använda lägsta kostnad, lägsta riskalternativ för att lösa problemet.
Exakt kan också göra saker som fånga bindvariabler som kastas till en SQL-sats. Uppenbarligen kommer variablerna som kastas att kontrollera storleken på de uppsatta resultaten. Och det kommer att kontrollera hur lång tid det tar SQL-uttalandet att köra och hur mycket data som måste skickas och behandlas av applikationen via Java, via .NET, till webbserversamlingen plus nätverket, som slutligen återges i slutanvändarens webbläsare . Vad som händer i databasen påverkar direkt den webbläsartiden. Och så kommer det att vara avgörande att ha denna synlighet så att vi kan veta exakt vad som händer och ge DBA flest alternativ så att de kan välja vilken som är mest meningsfull, med tanke på en viss situation.
Nu är det några av offerterna och de råkar vara från en PeopleSoft-butik som har global distribution. Precise stöder PeopleSoft och SAP, Siebel, Oracle, E-Business Suite, hemodlade Java- och .NET-applikationer. Vi stöder så om du ringer webbtjänster till flera JVM: er från Java till .NET tillbaka till Java, kan vi spåra allt detta. Det kan vara i början, det kan vara i molnet. Det avgörande är att saker måste instrumenteras.
Och så, bara ett par citat från en av våra kunder. "Innan Precise använde våra DBA: er OEM, " - det är ett verktyg som endast är databas, och de sade i princip, "Hej, instanserna ser bra ut." Men de kunde hjälpa till att berätta eller adressera ett problem med en viss transaktion. Exakt förutsatt att det var synligt att göra det. Och så att ha den informationen om SQL-uttalanden var avgörande för att ge DBA: s synlighet att fullständigt pressa prestanda ur databasen. Och så det var riktigt trevligt. Typ av utöver några av de verktyg som du kanske tittar på.
Och då älskade IT-förvaltningen verkligen det faktum att Precise kunde översätta en komplex URL till ett panelnamn. Och på det sättet om en slutanvändare ringer upp och säger "Hej jag har problem med det här" kan du isolera och se vem som är den användaren, vad kör de, vilken typ av prestanda, de mäter faktiskt rendering tid i slutanvändarens webbläsare. Det är ett riktigt mått på slutanvändarupplevelsen. Och det är också helt nödvändigt att ha det användar-ID för att hjälpa en viss person som ringer.
Hur gör Precise detta? Och så skulle vi vilja dela med oss av vår arkitektur. Precise ska leva på sin egen server och leva i en VM, det kan leva i molnet. I frontändet är Precise webbaktiverat, oavsett om du använder instrumentpaneler, varningsgränssnittet eller expertgränssnittet. På datainsamlingssidan kan vi faktiskt göra agentlösa för flera olika tekniker. Ofta kräver vi emellertid en agent, och det finns plus och minus för att ha en agent. Ett stort plus är att de data som samlas in kan förbehandlas innan de skickas över ditt LAN. Och så betyder det att vi kan minimera den totala effekten av övervakningslösningen på målmiljön.
Betrakta nu bara som ett alternativ, om du har "agent utan", finns det fortfarande en datainsamlare, det är bara en fråga om var den bor, och det ringer samtal och skickar rå data om målapplikationen över ditt LAN. Och det är faktiskt ganska dyrt. Och så genom att förbereda kan vi faktiskt minimera fotavtrycket. Du kan övervaka både fysiska och virtuella. Och en sak som jag ville säga om virtuell teknologi är att verkligen fokuserar på är användning. Vad Precise fokuserar på är stridighet. När minimerar VMware-tekniken resurserna till din gäst-VM? Och så blir det riktigt enkelt. Om du bara tittar på en gäst-VM har du bara en del av bilden. För att automatiskt kunna upptäcka och varna om strid är det väldigt viktigt.
Precise kan övervaka upp till 500 instanser, så mycket stora distributioner har i princip flera exakta servrar. Och för en global distribution är det vanligtvis en exakt server i varje datacenter. Förresten, för de allra största distributionerna kan du faktiskt förena dessa tillsammans så att du kan se företagets breda på vad som händer och kunna erbjuda rapportering, etc. Nu har jag, som jag nämnt, en hel del teknisk analys. Inte alla behöver gå in i expertgränssnittet, så vi erbjuder en anpassningsbar instrumentpanel. Och var och en av dessa portlets eller widgets, alla är valfria. Och någon kanske bara vill gå, ”Hej, hur kan du få en varning på alla nivåer i vår miljö? Hur går det med slutanvändningsgrupperna ur ett prestationsperspektiv? ”Eller kanske du har en fråga om infrastrukturen, kanske till och med Tuxedo-prestanda. Eller till och med lastbalansering. Det är lite intressant här i den här lastbalanseringsdelen. Jag tittar på portleten i mitten på vänster sida. Du kan se att antalet avrättningar är mycket lika mellan var och en av webbservrarna. Men responstiden är mycket annorlunda på den översta. Du kan faktiskt borra in och ta reda på exakt varför svarstiden på den webbservern var mycket långsammare än de andra.
En sak om lastbalansering, detta är mycket viktigt, och lastbalanseringspolicyer, du vet, inte varje lastbalanseringspolicy är lämplig för varje applikation. Det är verkligen bra att bekräfta din lastbalanseringspolicy. Vi ser faktiskt med vissa applikationer som det nya PeopleSoft Fluid GUI, där faktiskt vissa webbservrar går offline. Och så det är något som är riktigt kritiskt. Om du använder PeopleSoft Fluid GUI, vänligen kontakta oss. Vi kan ge dig mycket insikt och mycket kunskap om vad andra kunder har mött det. Var och en av dessa portlets kan vara ganska detaljerade. Liksom mitten till höger, med det blå och gröna, faktiskt visar svärdets spetsmönster, det visar på ett sätt att din sopsamling inom WebLogic-nivån fungerar som du förväntar dig att den ska köras. Var och en av dessa portlets kan vara mycket fokuserad eller kan vara mycket hög. Och anledningen till att det är viktigt, eller kan vara viktigt, är många gånger att det inte är tillräckligt bra för att bara ha denna information inom IT, ibland måste du dela denna information med applikationens ägare och ibland med den högsta ledningen, om vad som händer .
Jag ville dela med dig ett par berättelser, typ av "Framgång i datacenteret." Och dessa är databasfokuserade och jag har andra historier som är fokuserade på mellanliggande nivåer. Men för idag vill jag verkligen fokusera på databasnivån. Låt oss ta en titt på skärmen fryser. Vad som hände här är nu att den här butiken hade en affärs-SLA, att om en beställning tas emot klockan 15 skickas ordern den dagen. Och så är lagret extremt upptaget under den tidsramen. Och sedan med att få skärmen fryser var det väldigt frustrerande. Och så är handledaren - det här är ett mindre företag - handledaren gick faktiskt in på IT och går givetvis upp till DBA och säger: "Nu, vad händer?" Och så vad vi gjorde, kunde vi visa exakt vad som hände. Nu är detta JD Edwards, en applikation i flera nivåer, detta är skärmen för försäljningsorder. Du kan få en uppfattning om vad verksamheten var, i princip en just-in-time inventering, och så tittar du i princip på lagerapplikationer. Och nu levererar du i princip till ett antal olika kundwebbplatser, olika butiker. Och vad vi gjorde är att vi öppnade upp Precise.
Nu i det här fallet, innan vi tittade på Oracle, här tittar vi på SQL Server, och nu visar den övre halvan oss en staplad stapeldiagram över där SQL-uttalandena spenderar sin tid medan de körs. Varje svagt tillstånd redovisas i y-axeln. X-axeln om naturligtvis över tiden och du kan se att det staplade stapeldiagrammet ändras från tidsskivan beroende på vad som körs och hur det använder systemet. I detta specifika fall fokuserade vi nu på den tredje SQL-sekvensen uppifrån. Det är textat VÄLJ FRÅN PS_PROD och du kan se i den kolumnen att vi har fångat den verkliga exekveringsplanen. Och du kan se hela antalet avrättningar. Det faktum att det specifika SQL-uttalandet var ansvarigt för 9, 77 procent av resursförbrukningen under denna tidsram som vi tittar på - och det är en viktig punkt, tidsramen, Precise håller en rullande historia - och så kan jag i princip ringa in och ta reda på vad som hände vid en viss tidpunkt eller över tid. Jag kan se trend.
Nu detta SQL-uttalande, ser du det staplade stapeldiagrammet där, det är mörkblått. Det säger att vi använder alla CPU. Låt oss gå vidare och fokusera genom att klicka på denna "TUNE" -knapp på det specifika SQL-uttalandet. Vad vi gör är att vi tar det med till den verkstaden, den förbyggda verkstaden som är utformad för att säga: "Vad är det DBA kommer att veta om just detta SQL-uttalande?" Och du kan se till höger om det finns en flik som heter " Historik ”som har valts. Och vad jag vill att du ska göra nu är en typ av övergång till vänster sida där det står "Ändringar mot varaktighet genomsnitt", genomsnittlig varaktighet. Och var och en av dessa barer representerar händelser om dagen.
Du kan se på onsdag, torsdag, fredag, verkställningstiden var, jag ska runda till punkt två. Y-axeln visar punkt fyra sekunder, så punkt två. Mycket få skärmar fryser, operationerna går bra, i SLA. Tyvärr den 27 februari verkställande planen ändrades och det orsakade en omedelbar förändring av utförandetiden. Plötsligt går exekveringstiden, fyra X, kanske fem X, och saker går riktigt dåligt. Nu exakt, i dess förvaringsdagbok faktiskt tidskrifter alla förändringar som kan påverka beteende. Och du kan se att vi faktiskt har tagit upp axelförändringar. Den i mitten säger "Tabellvolym förändras." Och så växer tabellerna och vi har rätt på cusp, när SQL-uttalandet har analyserats väljer optimeringsprogrammet en exekveringsplan eller en annan exekveringsplan.
Nu lyckligtvis, den här veckan här på måndag flippade det, så det var på en bra tid. Tyvärr vänder det igen, och du vet vad, slutanvändarna börjar förvänta sig att skärmen fryser och de börjar skicka tillbaka den skärmen och de skjuter exekveringsräkningen upp och upp och upp. Vi har en enorm mängd detaljer, men för att lösa detta problem och sedan undvika det i framtiden behöver vi ytterligare en bit information. Och det visas för mig under jämförelsen av de verkställande planerna. Den 5 mars när det var snabbt och effektivt, på vänster sida visar den verkställande planen. När det var långsamt och ineffektivt den 12 mars, kan du se att det gör en filterkoppling. Filterkopplingen tvingar bara mycket mer CPU-konsumtion och gör mycket mer arbete. Resultatet är identiskt, det gör bara mycket mer arbete. Det är som du går och skaffar dina varor en ingrediens i taget, snarare än att gå till skafferi och få alla ingredienserna på en gång. Och så finns det den här typen av ett mer effektivt sätt att göra detta. Nu vanligtvis veta detta, DBA kunde använda frågeformulär för att undvika denna långsamma utförande plan och låsa in snabb, hög prestanda.
Nu är nästa typ av krigshistoria ”Rapporter är sent.” Jag tror att många kan identifiera sig med detta scenario. Du kanske har ad hoc-rapportering, du kan använda ett verktyg som NVISION, du kanske har ett tredjeparts rapporteringsverktyg. Och vad som händer är att verktyget utvecklar SQL. Och ofta är SQL inte riktigt kodad så bra. Och detta kan också gälla för en situation där, du vet, du har någon tredjepartsapplikation, rätt, där SQL inte var internt skriven, och så som en DBA: "Jag kontrollerar inte SQL, vad ska jag göra åt det? ”Tja Precise ger något som jag inte känner till något annat databasverktyg som är en objektvy. Kombinerat med rekommendationer och modellering. Och så kan vi faktiskt vända synlighet på huvudet. Istället för att bara titta på aktivitet, låt oss undersöka, vilket objekt är tyngst på systemet? Och i form av den nedre delen av skärmen kan du se ordningslinjen SQL och du kan se kolumnen "i MS-SQL". Och orderradtabellen är tio gånger mer upptagna än något annat bord i systemet. Jag tror att vad du också kommer att märka under den övre halvan, tilldelningen av utrymme växer och du kan också titta på specifikationerna på servern vilken version av programvara vi kör. Precise kommer faktiskt att kontrollera spårade ändringar av de primära inställningarna. Återigen, orsak och effekt.
Nu kan jag, med fokus på orderstabellstabellen, vad jag kan göra med mitt detaljerade historiska arkiv korrelera SQL-uttalanden som strider mot ordningslinjetabellen. Och du kan börja titta på var-klausulen i dessa SQL-uttalanden. Och du börjar märka att var-klausulen är ganska lik mellan de olika SQL-uttalandena. Och jag föreslår att du i ditt inspelningssystem hittar samma sak. Eftersom affärsanvändarna kommer affärsanalytikerna att vilja göra saker som aggregerad affärsaktivitet under den sista dagen, den senaste veckan, den sista månaden, det sista kvartalet, det senaste året. Du kommer att se mycket liknande där klausuler, ordning efter, gruppera efter, och det betyder att det kommer att finnas vissa index som är vettiga för dessa SQL-uttalanden.
Och så har Precise en rekommendationsmotor, du kan se det i det övre högra hörnet, och vad vi kan göra är att få rekommendationer. Säg, "Hej, jag kör alla SQL-uttalanden, vilka index skulle adressera dem?" Indexen presenteras för dig och du kan faktiskt se DBL. Nu är Precise endast skrivskyddad, det ger inte möjligheten att klicka på en knapp och skapa indexet, men det är tillräckligt enkelt att göra utanför Precise. Men här är det avgörande: Precise låter dig utvärdera och modellera förändringarna, så det finns den här utvärderingsknappen i det nedre vänstra hörnet på skärmen. Och vad det gör är att det visar SQL-uttalanden i före och efter.
Låt oss titta på dessa SQL-uttalanden. Ser du denna kolumn här som säger "i MS-SQL", och det står en timme, fyra minuter? Det bästa SQL-uttalandet kör eller förbrukar cirka 64 minuters värde. Och den beräknade förbättringen är 98 procent. Dessa ändringar kommer att spara timmars bearbetning. Nästa SQL-uttalande är 27 minuter och kommer i princip att spara en tredjedel. Det är ungefär tio minuters behandling. Sammanfattat kommer du faktiskt att spara timmar och timmar i bearbetning med dessa föreslagna ändringar. Och så att kunna veta detta på framsidan, kunna modellera detta. Du kan också använda "what-if" -funktionen för att säga: "Tja, jag vill inte göra det index, eller vad händer om jag ändrar kolumnens ordning?" Och så kan jag använda den här modelleringsfunktionen för att ta reda på exakt vad som kommer att hända.
Det andra som är avgörande är att när jag gör förändringen kan jag faktiskt mäta för ett enskilt SQL-uttalande. Du såg SQL-uttalningshistoriken i föregående exempel, och jag kan faktiskt verifiera om jag har uppnått de besparingar som modellerades. Och så att feedback, fullföljande av återkopplingsslingan är helt avgörande.
Okej, här är det sista exemplet jag skulle ha för dig. Detta är en SAP-butik och, du vet, de hade gått till en stor uppgradering, de gjorde några saker med anpassade transaktioner, och i princip var en slutanvändare inte nöjd med prestandan. Och det vi gjorde är att vi kunde fokusera på vad den slutanvändaren upplevde. Och du kan se överst på listan, "VÄLJA" och responstiden är drygt 61 sekunder. Det här tar en minut att köra. Nu kan du se att vi har en staplad stapeldiagram som är inriktad på SAP. På höger sida visar det klienttid, kötid. Det blå är applikationstid och i en SAP-miljö, det är ABAP-kod och sedan databasen. Och så databasen, du vet, den kan vara Oracle, den kan vara SQL, den kan vara HANA. Vi kan i princip visa det.
Vad vi gör med Precise är nu att vi fokuserar, för den transaktionen och den användaren, vilka SQL-uttalanden som kom ut. Återigen, det sammanhanget för att ansluta prickarna. Nu detta topp SQL-uttalande, kan du se att det är runt, det körs på två millisekunder. Du kan verkligen inte skylla på databasen om den körs så snabbt. Antalet utförande är mycket högt. Vi kan faktiskt gå tillbaka till ABAP-kodaren och säga: "Hej, vad händer?" Vi fann faktiskt att koden i databasen placerades på fel plats, häckte på fel plats i slingan, gjorde att ändra och sedan kan vi mäta efter. Du kan faktiskt se vad resultatet är efter. Inte bara på SQL-satsnivån utan också på den anpassade kodnivån. Och så kunde de leva med en körning på fyra och en halv sekund. Och så detta är bara några exempel på hur Precise kan utnyttjas, du kan utnyttja det. Precis som en snabb sammanfattning visar Precise prestanda efter plats, med slutanvändar-ID, det ger kontext genom applikationsstacken. Du kan borra in på grundorsaken. Och jag tror att en av de stora differentierarna är att kunna veta, inte bara SQL-uttalandet, utan varför SQL-uttalandet kör långsamt, och kunna identifiera striden och i princip erbjuda fler alternativ för att lösa problem. Detta är vad Precise har att erbjuda och du kan konsumera oss, du vet, på ett lätt sätt eller om du har mycket djupa, mycket utmanande problem, vi älskar att ta på dem också.
Eric Kavanagh: Okej, jag måste säga att det var en hel del fantastiska detaljer, Bill. Tack för att du visar alla dessa skärmdumpar. Och ur mitt perspektiv uppfyllde du verkligen det jag förklarade lite högst upp på timmen, som är, nummer ett, du måste ha rätt verktyg. Du måste ha ett verktyg som låter dig mängden sammanhang som krävs för att identifiera alla element i ekvationen, som någon sa i en film en gång, det var lite roligt. Men låt mig gå vidare och överlämna den till Dez eftersom jag slår vad om att han har några frågor till dig och jag vill driva en av dessa bilder bara för visuell godis, om du vill. Jag är faktiskt, vänta, låt mig ta tillbaka detta. Men Dez, jag är säker på att du har några frågor, ta bort det.
Dez Blanchfield: Ja, det gör jag, wow. Det här verktyget har kommit långt sedan jag ursprungligen visste det, och jag var inte medveten om att du faktiskt hade kommit ganska så djupt i bunten nu. Det är bara ganska förbluffande. Bara riktigt snabbt, ett par saker. Distributionsmodellen, kan du bara riktigt snabbt, på en minut eller två, bara beskriva den traditionella eller typiska implementeringsmodellen. Du nämnde att det fanns tillgängligt som en virtuell maskin. Det kan köras i molnet. Och jag antar att en av frågorna som förmodligen kommer att uppstå och jag tror att det fanns ett par frågor som kom igenom i frågan om frågor och svar. Bara för att sammanfatta dem i sammanfattning, så att den normala distributionsmodellen och vilken typ av axel som krävs, är den traditionellt distribuerad på plats eller värd eller i molnet? Vilka typer av distributionsmodeller ser du normalt? Och vilken typ av axel krävs för att få det att fungera? Måste vi ändra saker på säkerhetsnivå kring nätverksåtkomst, och så vidare? Eller kan det bara fungera som slutanvändare?
Bill Ellis: Ja, så för närvarande är majoriteten av installationerna på plats. Fler och fler människor lägger delar av applikationsstacken i molnet så att vi också kan hantera det. Den distribution vi behöver en server att köra på, den kommer att uppfylla vissa specifikationer. Vi måste ha en databas för att lagra det historiska arkivet, så att uppfylla dessa förutsättningar är typ av det första steget. Nästa sak är att vi definitivt måste ha lite kunskap om själva applikationen och installationen drivs av guiden och i princip fylla i tomma ämnen. På grund av djupet av information vi får, du vet, från en webbprocessnivå till den kod som körs, måste vi ha några privilegier. Vi har en säker datamodell, eller säkerhetsmodell, jag måste säga, eftersom agenterna körs med referenser som är helt åtskilda från personer som använder metadata om transaktionerna, etc.? Precise kommunicerar via TCP via IP och därför kräver vi att vissa portar är öppna. Som ett snabbt exempel, som vår standardport är 2702. Den typen av detaljerade saker är något om människor är intresserade, vi kan komma in på det mer detaljerat. Men vanligtvis är vi mycket snabba tid-till-värde. Om någon står inför ett stort problem kan vi ofta få saken installerad och tända ett starkt ljus på en situation inom några timmar.
Dez Blanchfield: Ja, det kände jag definitivt också. I distributionsmodellen talade du om en mycket stor skala och upp till 500 fall och hur det skulle kunna förenas. På själva inträdesnivån, hur ser det ut om någon vill - för jag vet att IDERA är väldigt stort på att ge tillgång till gratis prövningar, gratis demonstrationer, och jag minns att jag såg på webbplatsen nästan allt kan spelas med. För folk här, och jag tror att jag missade det tidigare, men jag tror att det var en fråga som kom upp hur ser en typisk webbplats ut och hur får folk tillgång till detta och börjar spela med det och få den typen av erfarenhet där de kan se om de har fått ett sätt att ta itu med vissa prestationsproblem? Kan de ladda ner ett ODS och snurra upp det på sin hypervisor, Hyper-V eller laptop eller behöver de en dedikerad maskin för att köra den på? Du redogjorde för arkitekturen innan men bara mycket kort, på en minut eller två, hur ser det ut för startnivån bara för att göra ett bevis på koncept till exempel?
Bill Ellis: Ja, så vår modell är lite annorlunda än IDERA-verktygen. Vi passar mer in i Embarcadero-scenariot där du vill kontakta en av våra säljare. Vi vill bara diskutera med dig vad som är utmaningarna och då skulle vi, vanligtvis, en av SE: erna tilldelas och i princip fungera genom installationen med någon. Vanligtvis skulle du inte köra Precise på din bärbara dator. Du vill ha en VM eller en server i datacentret där applikationen bor, för att göra samlingarna. Men vi skulle hjälpa dig genom varje steg i det. Om någon är intresserad av att fortsätta det, vill du definitivt kontakta IDERA.
Dez Blanchfield: En av de andra sakerna som slog mig var att jag menar att mycket av det vi har täckt idag är att reagera på prestationsfrågor. Men det verkade för mig att, och på levande miljöer som människor använder dem så, som ditt första bildspel, plockar någon upp telefonen och säger: "Applikationen går långsamt, hjälp." Men det slog mig att under förutsläpp av applikationer eller uppgraderingar eller nya korrigeringar och korrigeringar, kan du gå igenom en massa kapacitetsplanering och stresstestning och få exakt tittar på hela miljön och faktiskt hitta problem innan du ens sätter slutanvändare på miljön. Är det ett användningsfall som du har sett tidigare, eller är det människor som gör det också, eller är det inte ett typiskt fall?
Bill Ellis: Absolut, vi skulle vilja använda Precise under hela applikationsutvecklingscykeln eller uppgraderingslivscykeln också. Precise erbjuder en skalbarhetsvy, det visar antalet avrättningar som är överlagrade med responstiden. Uppenbarligen, om både antalet avrättningar och responstiden växer tillsammans, skalar du inte och du behöver göra något. Den typen av saker har hjälpt enormt. Jag tror att det är lite mindre sant nu, men när folk började sätta produktionsapplikationer på VMware var de lite tveksamma och det var som, du vet, vid det första de skulle vara, "Åh vi måste flytta det till fysiskt. ”Och vad vi faktiskt kan göra är att visa vad resursförbrukningen är så att du kan göra applikationen effektivare. Vid varje steg i applikationens livscykel vill du definitivt använda Precise. Men jag måste säga att produktion verkligen är där prestanda är viktigast och Precise är inriktad på 24/7 produktionsövervakning och så att du verkligen inte vill köra dina produktionsapplikationer utan synlighet.
Dez Blanchfield: Absolut. En annan snabb fråga bara om det speciella djuptestet, invandring, UAT och så vidare - jag menar, det är fantastiskt att ha det här verktyget och jag föreställer mig att apputvecklare absolut skulle vilja ha tillgång till detta genom livscykeln i utvecklingslivscykeln . Med de mer komplexa arkitekturer du ser nu, så vi har flyttat från dedicerad tjänst till virtualiseringar och virtualisering, vi flyttar nu till en slags, du vet, antagande av outsource till molnhosting och vi ser också en övergång till containerisering. Har du sett många människor distribuera detta och modellera den typ av regioner eller zoner, så någon kanske har - och i Australien har vi en mycket stor fråga kring integritet och jag vet att i Europa är det samma sak och jag tror att det blir mer ett fall i USA där data som kan identifiera mig personligen ofta måste vara i en säkrare miljö för det faktiska applikationslagret till webblagret. Och så har vi dessa distributioner nu där människor kan behålla sin databas och sina applikationsmaterial internt, men de kan sätta sitt webblager och deras leverans slut och applikation och så vidare i en molnleverantör som Azure eller Amazon Web Services och programvara . Hur fungerar det med din vanliga distribution? Är det så att du just har fått en annan uppsättning samlare i regionen och de samlar bara lite mer? Hur ser det ut i den exakta världen i dagens slags bimodala strategi för att köra IT av gamla äldre saker på ett ställe och dina varor är ibland i molnet?
Bill Ellis: Ja, så vi stöder en blandad miljö. En sak att tänka på är att det finns olika kontrakt med molnleverantörerna. Vissa av dem tillåter inte någon form av agent eller någon form av extern övervakning i molnet. För att installera och övervaka med Precise måste du ha en typ av kontrakt som tillåter den typen av åtkomst. Det finns definitivt några begränsningar som vi ibland måste genomföra och så det är viktiga typer av kriterier som du tänker på när du, antar jag, först undertecknar dessa kontrakt och sedan och / eller om du behöver implementera Precise.
Dez Blanchfield: Ja, jag har sett ett antal fall där även med traditionell databasmiljö om du anskaffar det som en del av tjänsten, särskilt med sådana som Azure, eftersom du anskaffar sådana som HDInsight eller SQL som en service, som plattform kan dina vanliga verktyg bara dyka så djupt eftersom de inte riktigt är så angelägna för dig att titta på vad som är under huven. Och så hamnar du typ med en viss nivå eller djup som du kan övervaka till och plötsligt kan du bara inte se bakom den magiska gardinen. Är självbetjäning en sak? Är detta traditionellt något som skulle köras i ett nätverksoperationscenter där det tekniska teamet, folket under CIO bara skulle få tillgång till, eller är det också något som du kan ge en åtkomstnivå för slutanvändare? Kanske inte nödvändigtvis receptionen och traditionella HR- och finansfolk, men mer kunniga användare som gör, du känner, till exempel datavetare, aktuarier, statistiker, människor som verkligen gör stora arbetsbelastningar. Är det så att de kan få tillgång till någon form av självbetjäningstillgång för att se vad som händer när de kör dessa tunga frågor och där smärtan kommer så att de kan sortera hur deras arbetsbelastning går?
Bill Ellis: Det finns ganska bra säkerhet inom Precise så att du kan ställa in användare som har olika åtkomstnivåer. På mycket grundläggande nivåer ger bara instrumentpanelerna övervakning. Och sedan inom, vet du, om någon ville gå in i expertgränssnittet kan du på något sätt begränsa vad de kan se och vad de kan göra. Och typ av cirkla tillbaka till din tidigare fråga som du vet att du inom hälso-och sjukvård har alla HIPAA-lagar och så det finns definitivt några överväganden och det finns faktiskt några distributionsalternativ så att vi kan arbeta med det i båda miljöerna. En sak att tänka på med de data som du har sett i denna presentation är att det är alla metadata om prestanda, inte innehållet i tabellerna, du vet, och så det är verkligen, det kommer inte att komma in i, typ av, dessa typer av integritetsfrågor.
Dez Blanchfield: Ja, jag gillade det. Jag hade ett eureka-ögonblick om din fjärde eller femte bild på skärmen snaps och jag insåg att du bara drar prestanda, inte bara, men du drar prestandadata, du drar saker, som sagt, metadata ur de olika nivåerna i stacken, du tittar faktiskt inte på innehållet. Och jag tycker att detta är en intressant sak eftersom det är ett av de verktygen där du antingen kan distribuera det på kort sikt och titta på vad som händer i miljön, men du behöver inte ha tillgång till själva uppgifterna. Du kan till och med titta på hur besättningarna drivs. Det sista, antar jag, bara snabbt, och sedan kommer jag att lämna tillbaka till Eric så om du har en fråga, så få Rebecca att slå in sig, nämnde du tidigare att överheaden är nominell, det är ett fall att det är till och med en märkbar omkostnad från övervakningssidan av saker och bara titta på bakgrunden eller är det en så obetydlig mängd omkostnader att det bara inte är värt att överväga?
Bill Ellis: Ja, så jag tror att databasnivån, varje teknik är lite annorlunda. På databasnivån är Precise ganska välkänt för att slå det lägsta omkostnaden. På mittnivån finns det, du vet, det finns en slags balans, du vet, det är inte bara exakt, det gällde alla, vad gäller synlighet och omkostnader. Och så är en av sakerna att vi erbjuder ett antal sofistikerade verktyg för att kontrollera vad omkostningen är. Vi är designade för produktion och, du vet, det är definitivt användbart att kluta så många problem i knoppen med utveckling och QA, men, du vet, det finns inget som att veta vad som händer i produktionen.
Dez Blanchfield: Eric, till dig, har du några sista frågor?
Eric Kavanagh: Ja, jag ska bara säga att jag tycker att du gjorde ett bra jobb med att påpeka att sammanhang verkligen är nyckeln och det är nästan som om vi går mot denna era av tingenes internet, du vill ha allt instrumenterat. Och jag tror att standarden nu inom tillverkningen är att göra det, vilket är goda nyheter, eller hur? Eftersom du vill kunna dra information från alla dessa olika miljöer och sy samman allt. Men jag antar att jag bara kommer att överlämna det till dig för några uppföljningskommentarer. Det är vad ni är fokuserade på är att tillhandahålla ett visuellt gränssnitt genom vilket en del analytiker, en IT-analytiker i huvudsak, kan övervaka och analysera vad som händer i denna komplexa miljö och sedan ta reda på vad som ska ändras. För det är inte bara ett verktyg. Du måste ha verktyget men du behöver den personen som kommer att gräva i den detalj och hitta svaren, eller hur?
Bill Ellis: Ja, jag ser det som att det kokar upp till toppen och prioriterar var är det mest återköpet, vet du? Om det visar sig är det en annan situation eftersom inte alla problem finns i databasen. Om databasen är, vet du, saker körs på en tiondel av en sekund men i applikationsnivån tar saker tre sekunder, det är där det mest återköpet är. Och så typ av att kunna isolera problemnivån och sedan vad som händer inom nivån för att verkligen fokusera på var återköpet är. Det påskyndar verkligen upplösningen och optimeringen av applikationen och det är så mycket snabbare och så mycket bättre och så mycket roligare än människor som samlades in i ett konferensrum som går, "Det är inte jag, det måste vara någon annan."
Eric Kavanagh: Det stämmer. Jag såg en fantastisk meme häromdagen som sa något som "Bli informerad, inte bara åsikt." Du går in i ett möte, du har informationen, du kan peka på uppgifterna. Det är nyckeln och vi kommer dit, tack och lov. Okej folkens vi kommer att gå vidare och packa upp, men vi arkiverar alla dessa webbsändningar för senare visning. Kolla gärna det när som helst. Vi listar alla våra webbsändningar nu, Hot Tech-serien och Briefing Room-serien på Techopedia.com, så hopp online och kolla in dessa. Med det kommer vi att ta farväl. Tack för din tid idag, Bill. Tack vare dig och allt ditt hårda arbete, Dez. Och vi pratar med dig nästa gång, folkens. Ta hand om dig. Hejdå.
