Av Techopedia Staff, 2 november 2016
Takeaway: Host Eric Kavanagh diskuterar applikationsprestanda och hur man kan förbättra effektiviteten med Dr. Robin Bloor, Dez Blanchfield och IDERAs Bill Ellis.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Mina damer och herrar, hej och välkomna återigen till Hot Technologies. Ja verkligen! Jag heter Eric Kavanagh, jag kommer att vara din värd för en annan webcast i dag i denna riktigt roliga, spännande serie som vi har som en komplimang till vår Briefing Room-serie. Titeln är "Application Acceleration: Snabbare prestanda för slutanvändare." Kom igen folk, vem vill inte ha det? Om jag är killen där ute och hjälper din ansökan att springa snabbare, tänker jag att jag är killen som köper öl till mig i baren efter jobbet. Det måste vara en ganska cool sak att gå in och påskynda någons ansökan.
Det finns en bild om din verkligen, slå mig upp på Twitter @Eric_Kavanagh. Jag försöker alltid följa tillbaka och jag twittrar alltid om du nämner mig, så känn dig fri att nämna mig.
Hela syftet med denna show är att fokusera på olika aspekter av företagsteknologi och verkligen hjälpa till att definiera vissa discipliner eller vissa ansikten, om du vill. Många gånger kommer leverantörer att hämta upp vissa marknadsföringsvillkor och prata om hur de gör det här eller det eller någon annan sak. Denna show var verkligen utformad för att hjälpa vår publik förstå vad ett programvaruverktyg behöver ha för att vara ledande inom sitt rymd. Formatet för detta är två analytiker. Var och en går först, till skillnad från Briefing Room där säljaren går först. Var och en tar sitt tag på vad de tycker är viktigt för dig att veta om en viss typ av teknik.
Idag talar vi om acceleration av applikationer. Vi kommer att höra från Dez Blanchfield och även doktor Robin Bloor - vi är över hela världen idag - och då ringer Bill Ellis in från större Virginia-området. Med det ska jag överlämna det till vår första presentatör, Dr Bloor. Vi tweetade hashtaggen för #podcast förresten, så känn dig fri att tweeta. Ta bort det.
Dr. Robin Bloor: Okej, tack för den introduktionen. Applikationsprestanda och servicenivåer - det här är ett slags område, jag har gjort mycket arbete inom detta område under åren, i den meningen att jag faktiskt har gjort mycket hemskt arbete med att övervaka prestanda och träna i sätt eller annat, hur man försöker beräkna dessa nivåer. Det måste sägas att fram till - vi brukade ha den här eran, för ett tag sedan, där människor byggde system i silor. I grund och botten är mängden arbete de faktiskt måste göra för att ett system ska fungera rimligt bra om det var i en silo faktiskt inte var för hårt eftersom det finns väldigt lite, mycket liten mängd variabler du måste ta hänsyn till. Så snart vi fått ordentligt nätverk kom interaktiv och serviceorientering i ekvationen. Det blev lite svårt. Prestanda kan vara en-dimensionell. Om du bara tänker på en applikation som kör en viss kodväg upprepade gånger, känns det som en endimensionell sak på ett rimligt sätt i tid. Så snart du börjar prata om servicenivåer, pratar du faktiskt om flera saker som konkurrerar om datorresurs. Det blir multidimensionellt mycket snabbt. Om du börjar prata om affärsprocesser kan affärsprocesser kopplas ihop från flera applikationer. Om du pratar om serviceorienterad arkitektur, kan en viss applikation faktiskt få tillgång till flera applikations funktioner. Då blir det en mycket komplicerad sak.
Jag tittade på - för länge sedan ritade jag detta diagram. Detta diagram är minst 20 år gammalt. I princip kallar jag det Diagram över allt eftersom det är ett sätt att titta på allt som finns i IT-miljön. Det är egentligen bara fyra delar: användare, data, programvara och hårdvara. Naturligtvis förändras de med tiden, men du inser faktiskt när du tittar på detta att det finns en hierarkisk explosion av var och en av dessa bitar. En hårdvara ja, en hårdvara kan vara en server men en server består av eventuellt flera CPU: er, nätverksteknologi och minne, och det här, ett slags fruktansvärt antal styrenheter, som det händer. Om du faktiskt tittar på detta, bryts allt upp i bitar. Om du faktiskt funderar på att försöka orkestrera allt detta, med avseende på data som ändras, mjukvarans prestanda ändras, eftersom hårdvaran ändras och så vidare, så tittar du faktiskt på en oerhört svår situation med flera varianter. Detta är komplexitetskurvan. Naturligtvis är det komplexitetskurva för nästan allt, men jag har sett den dras gång på gång när jag pratar om datorer. I grund och botten, om du sätter noder på en axel och de viktiga anslutningarna på den andra axeln, slutar du med en komplexitetskurva. Det spelar nästan ingen roll vad noderna och anslutningarna är och det kommer att göra om du vill visa en volymökning i telefonnätet.
I själva verket, när du pratar om noder i datormiljön, pratar du om enskilda saker som bryr sig om varandra. Det visar sig vara komplexitet, en fråga om olika strukturer och de olika begränsningarna som du försöker följa. Också siffrorna. När siffrorna ökar blir de galen. Jag hade en intressant chatt igår, jag pratade med någon - jag kan inte nämna vem han var, men det spelar egentligen ingen roll - de pratade om en webbplats som hade 40 000 - det är fyra noll, 40 000 - instanser av databaser på webbplatsen. Tänk bara på det - 40 000 olika databaser. Naturligtvis var det enda vi hade - de hade uppenbarligen många, många tusentals applikationer. Vi pratar om en mycket stor organisation, men jag kan inte nämna det. Du tittar faktiskt på det och du försöker faktiskt på ett eller annat sätt få servicenivåer som kommer att vara tillräckliga över hela linjen för flera användare, med flera olika, om du vill, förväntningar. Det är en komplex situation, och att allt jag verkligen säger är att det här är komplex. Siffrorna ökar alltid. Begränsningarna bestäms av affärsprocesser och affärsmål. Du kommer att ha märkt att förväntningarna förändras.
Jag kommer ihåg så snart Gmail, Yahoo mail och Hotmail, alla dessa postsystem kom upp, folk började förvänta sig att deras interna postsystem inom organisationen skulle förtjänar servicenivåerna för dessa enorma verksamheter med stora serverfarmer utanför organisationen och började bli pressad för att få alla sådana saker att hända. Faktum är att serviceavtal är en sak, men förväntningarna är en annan sak och de kämpar mot varandra inom en organisation, en besvärlig sak. Här är bara ett affärsperspektiv. I vissa system är den optimala responstiden en tiondel av en sekund av människans responstid. En tiondel av en sekund är tiden det tar en kobra att bita dig. Om du står framför en kobra och beslutar att bita dig, det är för sent, kommer det att du inte kan svara på en tiondel av en sekund. En tiondel av en sekund handlar om den tid det tar för bollen att lämna köns hand för att nå killen med bat. I grund och botten, när han ser bollen kastad, måste han svara på exakt den tidpunkten. Mänskligt svar, typ av en intressant sak. Programvara till programvara kan uppenbarligen ha högre förväntningar.
Då kommer du in i vissa situationer som jag tror är de marknadssituationer, där att vara först är där affärsvärdet är. Det här är som om du vill sälja en viss aktie på aktiemarknaden är förmodligen mindre, till exempel eftersom du tror att det går ner och många andra tycker att det går ner, får du det bästa priset om du kommer till marknaden först. Det finns många situationer, annonsvisning och liknande saker, mycket liknande situation. Du har denna rörelse när det gäller förväntningar på servicenivå. Du har en sak som är ett slags glasstak för mänskligt svar. När det är en mjukvara-till-programvara, om du har den här taksituationen, finns det ingen bästa servicenivå. Snabbare än alla andra är bäst.
Okej, det här är, tror jag, den sista bilden som jag gjorde, men det här är bara för att ge dig en stor bild av komplexiteten, när du faktiskt tittar på en organisations krav, tjänsten. Du har, genom att gå upp till vänster här, har du systemhantering, som är en uppsättning programvara som tjänar till servicestyrning, som försöker hantera en servicenivå. Ovanför har du företagsledning. Sedan om du tittar ner i botten här, området för servicehanteringsautomation, har du fragmenterade tjänster som utvecklas till standardiserade tjänster, om du faktiskt bryr dig att investera i den här typen av saker, som utvecklas till integrerade tjänster, som utvecklas till optimerade tjänster . Det som människor gjort mest är bara i det nedre vänstra hörnet av detta. Kanske lite servicehantering. Business performance management, mycket sällsynt. Fragmenterad, nästan allt. En perfekt värld skulle fylla det nätet. Instrumentation - Jag nämnde ett suboptimeringsproblem. Du kan optimera delar av ett system och det är inte bra för hela systemet. Om du gör hjärtat optimalt, kan ditt blod cirkulera för snabbt för resten av dina organ. Det är ett problem med stora organisationer och servicenivåer. Det är uppenbart att ingenting kommer att uppnås utan sofistikerade verktyg eftersom variablerna just har fått - det finns för många variabler för att försöka optimera.
Med det sagt kommer jag att vidarebefordra till Dez som förhoppningsvis kommer att prata om något annat.
Dez Blanchfield: Tack, Robin. Liksom Dr. Robin Bloor har jag spenderat alltför många år med att tänka på prestanda för mycket komplexa system i mycket stor skala. Förmodligen inte riktigt samma skala som Robin, men prestanda är ett dagligt ämne och det är en del av vårt DNA att vilja prestanda, för att få ut det bästa av allt. Faktum är att jag har använt en bild av en av mina favorit saker i världen, Formel I bilracing, där hela planeten sitter still ett tag och ser bilar gå runt i cirklar mycket snabbt. Varje enskild aspekt, det finns ingen aspekt av Formel I som inte specifikt handlar om att få prestanda. Många människor poo-poo sporten eftersom de tycker att det är slöseri med pengar. Det visar sig att bilen vi kör varje dag för att släppa barnen på fotboll på helgerna och i skolan de andra dagarna, härrör från prestationsbaserad utveckling och forskning. Det är ett slags liv i Formel I-bilracing. Vardagsteknologi, vardagsvetenskap, kommer ofta från sådant som har fokuserat enbart på hög prestanda.
Verkligheten är dock att vår nya "alltid på" värld, som kräver 100 procent drifttid - som Robin nämnde tidigare - med saker som införandet av webbmail och andra tjänster vi tar för givet i kontinuerligt utrymme, och vi förväntar oss nu att vårt företag och arbetsmiljö. Verkligheten är att att vara uppe betyder inte alltid att du uppfyller ditt servicenivåavtal. Jag har tagit på mig behovet av att hantera applikationsprestanda och avtal om tillgänglighet på servicenivå har genomgått en grundläggande förändring under det senaste decenniet. Vi försöker inte bara oroa dig för ett systems prestanda längre. När världen var lite enklare kan vi ha en situation där en enda server som kör flera tjänster kan övervakas live och det var relativt enkelt att stödja. Vi kunde - och här är mina lilla, saker som vi brukade oroa oss för när jag var systemadministratör till exempel för många år sedan - vi skulle titta omkring, är tjänsten vanligtvis upp och svarar? Kan jag till exempel logga in på en terminal? Svarar operativsystemet och kan jag skriva kommandon? Är applikationerna igång? Kan jag se processer och minne i att göra saker och I / O över hela nätverket och så vidare? Under mainframe-dagarna kunde du höra band på zip-zip-zip och papper falla ur dem.
Svarar apparna och kan vi logga in och göra saker på dem? Kan användarna ansluta till några av dessa servrar? Det går på. De är ganska grundläggande, du vet. Sedan några roliga - är helpdesken grön? För om inte, så går allt bra, och vem kommer att få munkar? Livet var verkligen enkelt i de dagar. Till och med i dessa dagar, och sedan pratar jag med för 20–30 år sedan, var komplexiteten fortfarande riktigt hög. Vi kunde på ett relativt enkelt sätt hantera serviceavtal och hålla ett öga på prestanda. Vi kan inte göra det för hand längre, som Robin talade om. Utmaningen är för stor. Faktum är den tiden då några bra appar, administratörer, systemnätverk och databas, administratörer kan övervaka och möta SLA: s prestanda. SLA: er är så långt borta nu att jag kämpade i går kväll när jag satte mina slutanmärkningar för att till och med tänka på året då jag senast lyckades titta på ett system med en mycket komplex bunt, och förstå det och till och med förstå vad som händer under huven, och jag kommer från en djupt teknisk bakgrund. Jag kan inte föreställa mig hur det är att möta det dagligen nu på ett administrativt sätt.
Vad hände? År 1996 transformerades databasdrivna appar med internetboomen. Många av oss har gått igenom det. Även om du inte var runt internetbom kan du enkelt bara se dig omkring och inse att i vardagen, att vi ansluter allt till internet nu. Jag tror att vi har en brödrost som uppenbarligen kommer med möjligheten att komma på Wi-Fi vilket är löjligt, eftersom jag inte behöver min brödrost ansluten till internet. På 2000-talet, särskilt i början av 2000-talet, var vi tvungna att ta itu med denna enorma tillväxt i komplexitetsrundan som levererade serviceprestanda i dot-com boom. Då ytterligare en löjlig besvärlig gnista i webb 2.0, där smartphones kom till och nu var applikationer i våra händer dygnet runt och var alltid på-läge.
Det är 2016 nu, vi står inför en annan quagmire i form av moln och big data och mobilitet. Det här är system som är så stora att de ofta är svåra att förstå och sätta på vanligt engelska. När vi tänker på det faktum att några av de stora enhörningarna som vi pratar om har tiotus hundratals petabyt data. Detta är hela golvet i skivutrymme och lagring bara för att hålla din e-post, bilder och sociala medier. Eller i vissa fall, inom transport- och fraktlogistik, är det allt inom banker, det är där dina pengar är, eller där ditt inlägg är, eller ditt, där det du köpte på eBay är. Nästa stora våg vi ska möta är denna mycket tunga utmaning med tingenes internet.
Om detta inte var tillräckligt dåligt, är vi på väg att bygga konstgjord intelligens och kognitiv databehandling till nästan allt. Vi pratar med Siri och Google-motorer idag. Jag vet att Amazon har en egen. Baidu har en av dessa enheter där du kan prata med, de konverterar den till text som går in i ett normalt system, databasen gör en fråga och kommer tillbaka och vänder processen. Tänk på komplexiteten som går in i det. Verkligheten är att komplexiteten i dagens standardapplikationsstack är långt bortom mänskliga förmågor. När du tänker på allt som händer när du trycker på en knapp på din smartphoneenhet eller din surfplatta, talar du till den, konverterar det till text, kör det hela vägen till internet till ett backend-system, en front-end får som konverterar den till en fråga, kör frågan genom en applikationsstack, går igenom en databas, träffar skiva, kommer ut igen, och i mitten finns det ett transportnätverk, det finns ett lokalt nätverksstatuscenter. Komplexiteten är arg.
Vi hävdar effektivt detta som hyperskala. Komplexiteten och hastigheten för överkalkning är bara ögonvattning. Applikationer och databaser har blivit så stora och så komplexa att hantera prestanda i själva verket är en vetenskap i sig. Många hänvisar till det som en raketvetenskap. Vi har teknik på plats, vi har offsite-teknik, vi har en rad alternativ för datacenter; fysiska och virtuella. Vi har fysiska och virtuella servrar, vi har moln, vi har infrastruktur som en tjänst och plattform som en tjänst och programvara eftersom en tjänst är en sak som vi nu tar för givet. Det senare, programvara som tjänst, blev skrämmande för ett tag för några år sedan när ekonomidirektörer och delar av organisationen insåg att de kunde hämta sitt kreditkort och bara köpa saker själva och gå runt CIO och effektivt kallade vi denna "skugga IT ”och CIO: erna försöker nu linda tillbaka denna och bryta kontrollen över.
I infrastruktur har vi mjukvarudefinerat nätverk, virtualiserad nätverksfunktion, under det vi har, förmodligen över, nu har vi mikrotjänster och appar av aktiva tjänster. När du klickar på en URL finns det ett gäng affärslogik som ligger i slutet av URL: en som beskriver vad den behöver för att faktiskt leverera den. Det har inte nödvändigtvis förbyggd logik som väntar på det. Vi har traditionella databaser på ena sidan som skalar mycket, väldigt stora. Vi har sådana som Hadoop-infrastruktur och ekosystem i det andra spektrumet som är bara så stora att, som sagt, du vet, folk pratar om hundratals petabyte data nu. Vi har komplexitet rörlighet så långt som enheter som bär runt, bärbara datorer och telefoner och surfplattor.
Vi har BYOD i vissa slutna miljöer och allt mer nu, sedan de erfarna människorna från Gen Y tar med sina egna enheter. Vi låter dem bara prata med dem om webbgränssnitt. Antingen via internet eller via Wi-Fi, vi har en gratis Wi-Fi i caféet nedervåningen när de dricker kaffe. Eller vår interna Wi-Fi. Maskin-till-maskin är ständigt närvarande nu. Det är inte direkt en del av tingenes internet, men det är också relaterat. Tingenens internet är ett helt nytt spel med en komplexitet som är förvirrad. Konstgjord intelligens, och om du tror att det vi leker med nu, med alla Siri och andra relaterade enheter vi pratar med är komplexa, vänta tills du kommer till en situation där du ser något som kallas Olli som är en 3-D tryckt buss som tar cirka sex personer och kan köra sig själv runt staden och du kan prata vanligt engelska till den, och den kommer att tala tillbaka till dig. Om den träffar trafiken kommer den att besluta att svänga åt vänster eller höger från huvudområdet där det finns trafik. När det svänger och du blir orolig över varför den vänster eller höger utanför huvudvägen kommer den att säga till dig: "Oroa dig inte, jag håller på att svänga åt vänster. Det finns trafik framåt och jag kommer att gå runt det. ”
Att hantera prestandan för alla system där och all komplexitet, spåra var dessa data går, oavsett om de går in i databasen, alla sammankopplingar och alla relevanta bitar är bara att tänka. Verkligheten är att hantering av prestanda och SLA med dagens hastighet och skal kräver verktyg och system, och som standard är detta inte längre något där man bara skulle tro att det skulle vara trevligt att ha ett verktyg - det är en förutsättning; det är bara absolut nödvändigt. Här är något som ett litet exempel, en lista med högnivåapplikationsdesigndiagram för OpenStack, öppet programvarudefinierat moln. Det här är bara en stor bit. Detta är inte bara servrar och databas. Det är här som varje liten blå klump representerar kluster av saker. I vissa fall körs filer och servrar eller hundratals databaser eller naturligtvis inte mer än tiotusentals små bitar av applikationslogik. Det är en liten version. Det är verkligen ganska obehagligt när du börjar tänka på komplexiteten som uppstår i detta. Idag lägger jag bara några stora skärmdumpar av bara varumärken, till och med i bara stora datautrymmen. När du tänker på alla bitar som vi måste hantera här, pratar vi inte bara om ett märke nödvändigtvis, det är alla märken i big data-landskapet och toppmärket, inte bara varje liten liten eller öppen källa. Du ser ut och du tycker att det är ganska ett förväxlande diagram.
Låt oss bara titta på ett par vertikaler. Låt oss ta till exempel marknadsföring. Här är ett liknande diagram men från teknologibackarna som finns tillgängliga endast i marknadsföringsteknologi. Detta är grafen för 2011. Här är 2016-versionen. Tänk bara på, det här är bara antalet märken av produkter du kan använda för teknik med avseende på marknadsföringsteknik. Inte komplexiteten i systemen där inne, inte den olika appen och webb och utveckling och nätverk och allt annat. Bara varumärket. Det är förut, för fem år sedan och här är idag. Det kommer bara att bli värre. Vi är just nu där verkligheten är, människor kan helt enkelt inte säkerställa alla serviceavtal. Vi kan inte dyka tillräckligt med detaljer, tillräckligt snabbt och i den skala vi behöver. Här är ett exempel på hur en övervakningskonsol ser ut nu. Det här är som nästan tjugo udda skärmar limmade ihop och låtsas vara en stor, stor projicerad skärm som övervakar varje litet stycke. Nu är det intressant här, jag kommer inte att nämna varumärket, men denna övervakningsplattform övervakar en enda applikation i en logistik- och sjöfartsmiljö. Bara en app. Om du tänker på vad Robin talade om där organisationer kan ha 40 000 databaser nu i produktionsmiljöer. Kan du bara visualisera hur 40 000 versioner av denna samling skärmar som övervakar en applikation kan vara? Det är en väldigt modig värld vi lever i. Som Robin sa och jag kommer absolut, 100 procent att återspegla att utan rätt verktyg, utan rätt stöd och folk på bordet med dessa verktyg, är applikationsprestanda ett förlorat spel för människorna och det måste göras med verktyg och programvara.
Med det kommer jag att överföra till våra vänner i IDERA.
Eric Kavanagh: Okej, Bill.
Bill Ellis: Tack. Dela ut min skärm här. Jag antar att någon kan bekräfta att du kan se min skärm?
Dr. Robin Bloor: Ja.
Eric Kavanagh: Det ser bra ut.
Bill Ellis: Tack. Det enda han hänvisade till var att jag verkligen inte kan vänta på var den självkörande bilen. Det enda jag inte hört någon prata om är vad som händer när det snöar? Jag undrar lite om ingenjörerna i Kalifornien insåg att det i andra delar av landet snöar ganska mycket.
Dez Blanchfield: Jag gillar det, jag kommer ihåg den.
Eric Kavanagh: En typisk mil en timme.
Bill Ellis: Vi är här för att prata om applikationsprestationshantering i en komplex miljö. En sak jag gillar att prata om är många människor, när de pratar om prestanda, reaktionens natur är, hej fler servrar, mer CPU, mer minne etc. Den andra sidan av det myntet är bearbetningseffektivitet. Det är verkligen två sidor till samma mynt och vi ska titta på båda. Det slutliga målet är att uppfylla servicenivåavtalen för affärstransaktionerna. I slutändan existerar all denna teknik för verksamheten. Vi pratade om att ha en bransch-första resultathanteringsdatabas. Idealet med det är att passa in i den perfekta formen för prestanda och hantera den från början av applikationens livscykel.
Ämnen kokar verkligen ner till fyra stycken; en är processen för att hantera prestanda. Vi pratade med alla, och alla har verktyg. Om de inte har verktyg har de skript eller kommandon, men vad de saknar är kontext. Context är helt enkelt att ansluta punkterna över applikationsstackarna. Dessa applikationer för - är webbläsarbaserade. De är mycket tätt kopplade från nivå till nivå. Hur nivåerna interagerar är också viktigt. Sedan pratar vi om affärstransaktionen. Vi kommer att ge synligheten inte bara för de tekniska personerna, utan också för applikationsägarna och driftscheferna.
Jag har ett par fallstudier för att bara dela med dig hur kunderna har använt dem. Detta är en mycket praktisk del av presentationen här. Låt oss ta en titt på vad som vanligtvis händer. Jag gillar att diagram - det var precis som en otrolig collage av teknik. Antalet teknologier i datacentret har precis vuxit och vuxit och vuxit. Under tiden bryr sig slutanvändaren inte om det och är omedveten om det. De vill bara utöva transaktionen, ha den tillgänglig, ha den slutförd snabbt. Vad som normalt händer är att proffsen inom IT inte är medvetna om att slutanvändarna till och med hade problem tills de själv rapporterar. Det inleder en typ av tidskrävande, långsam process och ofta frustrerande. Vad som händer är att människor öppnar upp sina verktyg och tittar på en delmängd av deras applikationsbunt. Med den delmängden blir det mycket svårt att svara på den enklaste frågan. Är det vanligt att du har problemet? Vilken transaktion är det? Var i applikationsbunten ligger flaskhalsen? Genom att spendera hela denna tid, titta på nivå efter nivå, inte kunna svara på dessa frågor, slutar du med att spendera mycket tid och energi, mycket personal, medel och energislag för att ta reda på det.
För att lösa detta, för att ge ett bättre sätt, vad Precise gör är att faktiskt ta slutanvändarspårstransaktionen, fångar metadata om det, följer transaktionen genom nätverket, in på webbservern, i affärslogiknivån och Vi stöder .NET och ABAP och PeopleCode och E-Business Suite i multitierapplikationer som i slutändan alla transaktioner kommer att interagera med journalsystemet. Oavsett om det är en inventering av inventarier, rapporterad tid fungerade, interagerar de alltid med databasen. Databasen blir grunden för affärsresultat. Databasen förlitar sig i sin tur på lagring. Vad metadata om transaktionerna svarar, vem, vilken transaktion, var i applikationsbunten, och sedan har vi djup synlighet på kodnivån för att visa dig vad som kör. Den här informationen fångas kontinuerligt, läggs i databasen för prestationshantering - som blir ett enda musikblad för alla att se vad som händer. Det finns olika människor och organisationer som bryr sig om vad som händer: de tekniska experterna, applikationsägarna, i slutändan själva företaget. När ett problem uppstår, vill du kunna extrahera information om transaktionen.
Innan vi tittar på investeringstransaktionen vill jag visa er hur det kan se ut för olika personer i organisationen. På en förvaltningsnivå kanske du vill ha en översikt över flera applikationer. Du kanske vill veta om hälsan som beräknas av SLA-efterlevnad och tillgänglighet. Att hälsan inte betyder att allt fungerar perfekt. Det finns utrymme i det här fallet att du kan se att investeringstransaktionen är i varningsstatus. Nu, lite djupare, kanske inom branschen, vill du ha ytterligare detaljer om enskilda transaktioner, när de bryter mot SLA, transaktion räknas, etc. Verksamhetsgruppen vill bli meddelad om detta genom en varning från vissa sortera. Vi har inbyggda prestandavarningar. Vi mäter faktiskt prestandan i slutanvändarens webbläsare. Oavsett om det är Internet Explorer, Chrome, Firefox osv. Som vi kan upptäcka, svarar det på den första frågan: har en slutanvändare problem?
Låt oss dyka in och se vad vi annars kan visa om det. De människor som är intresserade av prestanda skulle öppna upp Precise. De skulle utvärdera transaktionerna. De skulle titta på SLA-kolumnen för att identifiera transaktioner som inte var SLA-kompatibla. De skulle kunna se slutanvändarna som påverkades såväl som vad transaktionen gjorde när den flödade över applikationen. Det sätt som du dechiffrerar dessa hieroglyfer är, detta är webbläsaren, URL: en, U är för URL, det är ingångspunkten i JVM. Nu gör just denna JVM en webbserver att ropa till den andra JVM som sedan kör SQL-uttalandet. Detta är helt klart en databasfråga eftersom detta SQL-uttalande svarade för 72 procent av responstiden. Vi är fokuserade på tiden. Tid är prestandans valuta. Det är hur slutanvändare upplever om saker går långsamt eller inte, och det är ett mått på resursförbrukning. Det är mycket praktiskt; det är typ av en enda metrisk som är viktigast för att utvärdera prestanda. När detta problem överlämnas till DBA är det inte bara ett databasproblem, det är detta SQL-uttalande. Det här är det sammanhang jag pratade om.
Nu beväpnad med denna information kan jag gå in och analysera vad som hände. Jag kan först och främst se, y-axeln är tiden över dagen. Ursäkta, y-axeln är responstid, x-axeln är tid över dagen. Jag kan se att det finns en databasproblem, det finns två händelser, gå tillbaka till det flödet, plocka upp det SQL-uttalandet och gå in i expertvyn, där Precise kan visa dig vad som händer, dess kontroller, hur lång tid den koden tar att Kör. I databasnivån är det exekveringsplanen. Du kommer att notera att Precise valde ut den verkliga exekveringsplanen som användes vid exekveringstiden, som skiljer sig från den uppskattade planen, som skulle vara när planen gavs och inte under utförandetiden. Det kan kanske eller inte återspegla att databasen faktiskt gjorde det.
Nu här nedan är en svarstidsanalys för SQL-uttalandet. Nittio procent av tiden för lagring; tio procent användes i CPU. Jag kan se texten till SQL-uttalandet såväl som fyndrapporten. SQL-satsens text börjar avslöja vissa kodproblem. Det är vald stjärna; som returnerar alla rader - ursäkta mig, alla kolumner från raderna som returnerades. Vi vänder tillbaka ytterligare kolumner som applikationen kanske behöver eller inte behöver. Dessa kolumner förbrukar utrymme och resurser att bearbeta. Om du kör SAP, är en av de stora förändringarna, eftersom HANA-databasen är kolumner, det som i grund och botten skriver om SAP för att inte välja utvalda stjärnor så att de kraftigt kan minska resursförbrukningen. Detta är i princip något som händer mycket tid även i hemodlade applikationer, vare sig Java, .NET, etc.
Den skärmen visar detta vem, vad, när, var och varför. Varför kommer till, som SQL-uttalande och exekveringsplan som låter dig lösa problem. Eftersom Precise körs kontinuerligt kan du faktiskt mäta före och efter, på SQL-uttalningsnivå, på transaktionsnivå, så antingen kan du mäta för dig själv, såväl som genom applikationsägarna och för hantering, att du har löst problemet . Denna dokumentation är verkligen bra. Det finns mycket komplexitet i den här applikationsbunten. Av många applikationer kör faktiskt alla vi har pratat med åtminstone en del av applikationsbunten under VMware. I det här fallet tittar de på kundserviceapplikationen, de tittar på transaktionstid och korrelerar det med avmattningen är en virtualiseringshändelse. Exakt spårar alla virtualiseringshändelser. Vi har ett plug-in till vCenter för att hämta det.
Vi kan också upptäcka stridighet. Stridighet är annorlunda än användning. Visar faktiskt när kanske en bullrig granne påverkar din gäst-VM, i samband med kundserverens applikation. Nu kan jag borra in och få information och jag kan faktiskt se de två VM: er som strider, i det här fallet, för CPU-resurser. Detta tillåter mig att ha synlighet så att jag kan titta på schemaläggning. Jag kan sätta en gäst-VM på en annan fysisk server. Alla dessa typer av saker som du kanske svarar på och sedan, utöver det, kan jag faktiskt titta på kodeffektiviteten för att kanske låta den använda mindre CPU. Jag tror att jag har ett ganska bra exempel i den här presentationen av hur någon kunde minska CPU-förbrukningen med storleksordrar.
Det var VMware. Låt oss gå in i själva koden, programkoden. Precise kommer att kunna visa dig vad som händer inom Java, .NET, ABAP-koden, E-Business, PeopleCode, etc. Dessa är ingångspunkterna till, i detta fall, i WebLogic. Här nedan finns en rapport om resultaten som säger att det är dessa EJB: er som du behöver titta på, och kommer att säga att du också fick låsning på det här systemet. Återigen borrar du ner i affärslogiknivån för att visa vad som händer. I det här fallet tittar jag på speciella fall; Jag stöder också kluster. Om du har flera JVM: er som kör, kan du antingen titta på klustret som helhet eller titta på flaskhalsar inom den enskilda JVM.
När du får låsning kan jag få undantag. Undantag är lite annorlunda än ett prestandaproblem. Vanligtvis körs undantag mycket snabbt. Eftersom det finns ett logikfel och när du träffar det logiska felet slutar det. Vi kunde fånga ett stackspår i undantagsfallet, det kan spara mycket tid eftersom det går igenom att försöka ta reda på vad som händer, du har bara stackspåret just där. Vi kan också fånga minnesläckor också. Lösningen inkluderar också databasnivån, jag kan gå in, jag kan utvärdera databasinstansen. Återigen är y-axeln där tiden tillbringades, x-axeln är tiden över dagen. Det finns en resultatrapport som bara automatiskt berättar vad som händer i systemet och vad jag kan titta på.
En av sakerna med Precises fyndrapport, den tittar inte bara på loggar eller väntetillstånd - den tittar på alla exekveringslägen inklusive CPU, samt returnerar information från lagring. Lagring är en mycket viktig del av applikationsbunten, särskilt med tillstånd av fast tillstånd. Att ha information längs dessa linjer kan vara till stor hjälp. För vissa lagringsenheter kan vi faktiskt borra ner och visa vad som händer på den enskilda enhetsnivån. Den typen av information - återigen är det djup synlighet; det är brett i omfattning - för att ge dig tillräckligt med information för att få mer hävstång att dra som en applikationsprestandeprofessionell, så att du kan optimera dina applikationer från en ende till en annan basis för att möta dessa affärstransaktioner.
Jag har ett par fallstudier som jag ville dela med dig. Vi kryssar ganska snabbt; Jag hoppas att jag går i okej. Pratar om lagring, alla över tiden byter hårdvara. Det finns en maskinvaregaranti. Levererade det verkligen vad säljaren sa till dig? Du kan utvärdera det med Precise. Du kommer in, och vad som hände här, lägger de i grunden in en ny lagringsenhet, men när lagringsadministratörerna tittade bara på lagringsenhetsnivån såg de mycket strid och de trodde att det kan vara ett problem med den nya lagringsenheten . Att titta på mer från ett slut-till-slut-perspektiv, precis för att visa var det faktiskt skulle hända. De gick faktiskt från en kapacitet på cirka 400 meg per sekund, där lagringen svarade för 38 procent av responstiden, så det är ganska högt. Med den nya lagringsenheten stötte vi faktiskt upp kapaciteten till sex, sju hundra megs per sekund, så i princip dubbelt, och vi kan minska bidraget från lagringsnivån till transaktionstiden i halva. Jag kan faktiskt kartlägga det tidigare, det här är en övergångsperiod och sedan efteråt.
Så än en gång, dokumentation för att bevisa att hårdvarufinvesteringen var värt det och de levererade som den säljaren hade förväntat sig. Det finns allt, på grund av komplexiteten, antalet saker, det finns alla typer av saker som kan hända. I det här fallet hade de faktiskt en situation där alla skyllade DBA, DBA var som "Tja, inte så snabbt." Här tittar vi faktiskt på en SAP-applikation, jag tror att den här typen av scenarier är ganska vanligt . Det som hände var att de utvecklade en anpassad transaktion för en användare. Användaren är som, "Det här är så långsamt." ABAP-kodaren - det är programmeringsspråket i SAP - sa: "Detta är en databasfråga." De slutade med att öppna Precise; de mätte slutanvändaren 60 sekunder, så väl över en minut. Femton-tre sekunder tillbringades i backend. De borrade i baksidan och de kunde faktiskt avslöja SQL-uttalandet som presenterades i fallande ordning.
Detta topp SQL-uttalande som svarar för 25 procent av resursförbrukningen, dess genomsnittliga körningstid är två millisekunder. Du kan inte skylla på databasen. Du vet, hej, inte så snabbt, kille. Frågan är, varför finns det så många avrättningar? Jo, de studsade tillbaka till ABAP, han gick in, tittade in i boet på slingan, fick reda på att de kallade databasen på fel plats, de gjorde i princip ändringen, testade ändringen och nu är den nya responstiden fem sekunder. Lite långsam, men de kunde leva med det. Mycket bättre än 60 sekunder. Ibland är det bara applikationskoden, är det databasen, är det lagring? Det är de områden där Precise, genom att ha sammanhanget med de slutliga transaktionerna, är det där Precise kommer in. Du slutar i princip dessa saker.
Jag tittar på tiden, ser ut som att vi fortfarande har lite tid att gå igenom ett par fler av dessa. Jag strömmar igenom dessa. Denna ansökan var under utveckling under över ett år. När de gick till QA såg de att webbservrarna var maxade ut 100 procent och det såg ut som att applikationen inte kunde köras under VMware. Det första som alla sa var: ”Sätt på det fysiska; det kan inte köras under VMware. ”Precise erbjöd dem faktiskt ytterligare sätt att lösa problemet. Vi tittade på transaktionerna, vi såg ett webbserversamtal, det kommer in som en ASMX i IIS.NET. Det avslöjade faktiskt den underliggande koden. Ser du det där jag pekar? Detta är 23 dagar, 11 timmar. Wow, hur är det möjligt? Tja, varje anrop tar 9, 4 sekunder och den här saken åberopas 215 000 gånger. För varje anrop använder den 6 sekunder CPU. Detta är anledningen, den här koden är anledningen till att den här saken aldrig skulle kunna skala. I själva verket kunde det inte skalas i fysiskt.
Vad de gjorde, är att de gick tillbaka till sina utvecklare och de sa: "Kan någon göra en förändring?" De hade en tävling, och de testade ut de olika förslagen och de kom med ett förslag som kunde köra mycket mer effektivt. Den nya avslutade en poäng, lite mindre än två sekunder, med tvåhunderdels sekund i CPU. Nu kan det skala och det kan köras på VMware-gården. Vi kunde i princip dokumentera det på såväl kodnivå som transaktionsnivå. Detta är typ av förut och sedan efter. Nu när du kan se här i stapeldiagrammet som visar webb, .NET och databas, interagerar du nu med databasen. Detta är en profil du kan förvänta dig att se för en applikation som körs mer normalt.
Okej, jag väljer och väljer i termer av ytterligare saker jag kan visa dig. Många gillar detta eftersom det här bländar många butiker. Om du inte kan möta ett SLA-företag, och alla är som "Hjälp oss." Den här butiken hade en situation där SLA-företagen har beställningar som mottogs klockan 15, den skickas den dagen. Är verkligen viktigt att de får orderna och lagret är mycket upptaget. Denna JD Edwards försäljningsorder skärm, fryser och du kan få en mycket bra idé att detta är ett just-in-time detaljhandelslager. Tomma hyllor är oacceptabla i detaljhandeln. Måste ha varan där för att sälja den. Vad vi gjorde är att vi dök i, i det här fallet tittar vi på SQL-serverdatabasen. Utseendet är detsamma oavsett om det är SQL, Oracle, DB2 eller Sybase.
Vi identifierade valet från PS_PROD och vi kan fånga varaktigheten, det faktum att de kör så mycket. Den mörkblå matchade nyckeln som sa att de inte väntar på något väntetillstånd eller någon loggning eller till och med lagring - det här är bundet av CPU. Vi spårade SQL-uttalandet av 34301 så varje gång detta utförs ökar vi våra räknare för att hålla reda på det. Det betyder att vi har en detaljerad historik och jag kan komma åt den genom att klicka på den melodiknappen. Här är historikfliken. Den här skärmen visar genomsnittlig varaktighet kontra förändringar. Onsdag, torsdag, fredag var den genomsnittliga varaktigheten cirka två tiondelar av en sekund. Mycket få skärmar fryser, de kan möta företagets SLA. Kom 27 februari, något förändras och plötsligt är körningstiden här uppe, och det är faktiskt tillräckligt långsamt för att orsaka timeouts, vilket resulterar i skärmfrysningar. Exakt genom att hålla en detaljerad historik, inklusive exekveringsplanen och allmänna ändringar av tabellens index om den SQL används. Vi kunde upptäcka att åtkomstplanen ändrades den 27 februari. Måndag till fredags dåliga vecka. Kommande 5 mars ändrades åtkomstplanen igen. Det här är en bra vecka. Denna rosa stjärna berättar volymen uppdaterad.
Här kan du se antalet rader i de underliggande tabellerna växer och det är typiskt för ett företag. Du vill att dina bord ska växa. Saken är att uttalandena har analyserats, SQL-uttalanden kommer in, optimeringsprogrammet måste bestämma vad man ska göra och välja när exekveringsplanen är snabb, välja en annan exekveringsplan när det är långsamt, vilket orsakar skärmen fryser. På djup teknisk grund måste jag veta vad exekveringsplanen är och Precise fångar den för mig komplett med datum- och tidsstämpel. Det här är snabbt och effektivt, det här var långsamt och ineffektivt. Detta filterkoppling använder helt enkelt mycket mer CPU för att förena, för att göra just detta SQL-uttalande. De har fortfarande samma ultimata effekt, men den här har i princip ett långsammare, mindre effektivt recept för att leverera resultatset. Så vi går igenom. Hej, vi har tid till ett par till?
Eric Kavanagh: Ja, gå för det.
Bill Ellis: Okej, jag hoppar framåt. En sak jag vill att du ska notera, vi pratade om hårdvara, pratade om SAP, vi pratade om. NET, vi pratade om JD Edwards och Java-SQL Server-miljön. Det här är SAP, här över tittar vi på PeopleSoft. Precises stödmatris är bred och djup. Om du har en applikation, mer än troligt, kan vi instrumentera den för att ge denna synlighet. En av de största förändringarna som händer just nu är rörlighet. PeopleSoft introducerade mobilitet med dess Fluid UI. Fluid UI använder ett system mycket annorlunda. Denna applikation utvecklas. Fluid UI - vad det gör från ett förvaltningsperspektiv är att det tillåter slutanvändarna att använda sin telefon och det ökar produktiviteten kraftigt. Om du har hundratals eller tusentals eller ännu fler anställda, om du kan öka deras produktivitet, 1-2 procent, kan du få en enorm inverkan på lönen och allt annat. Vad som hände var att just denna butik rullade ut PeopleSoft Fluid UI. Nu när vi talar om komplexitet är detta PeopleSoft-stacken. En applikation, minst sex teknik, många slutanvändare. Hur startar du det?
Återigen kommer Precise att kunna följa dessa transaktioner. Det vi visar dig här är en staplad stapeldiagram som visar klient, webbserver, Java, Tuxedo-databas, PeopleSoft-applikationsstapel. De gröna kartorna till J2EE, som är ett snyggt sätt att säga WebLogic. Det här är övergången. Slutanvändarna börjar använda Fluid UI och responstiden går från kanske en och en halv, två sekunder, upp till cirka nio, tio sekunder. Vad den här skärmen inte visar är antalet personer som "inte svarar." De fick faktiskt skärmfrysningar i applikationen. Låt oss ta en titt på en del av synligheten som Precise kan ge denna kund.
Först och främst när jag tittar på PeopleSoft-transaktioner kan de i princip se, vi såg den här typen av saker över hela linjen. Alla transaktioner påverkades liksom alla platser. Förresten, när du tittar på detta kan du faktiskt se platser runt om i världen. Från Asien och Stilla havet, till Europa såväl som Nordamerika. Prestandaproblemet var inte beläget för en viss transaktion, eller en speciell geografisk plats, det är systembrett. Det är ett slags sätt att säga att förändringen eller hur Fluid UI var global påverkade. Här kan du se från skalbarhetssynpunkt, människor försöker göra samma typ av aktivitet, men responstiden är i princip bara försämrad och försämrad. Du kan se att saker och ting inte skalas. Det går väldigt, mycket dåligt. Här borta, när jag tittar på axelantalet och samtidiga anslutningar, ser du något som är mycket intressant när det gäller åtkomstantalet och anslutningarna. Här skalar vi bara upp till cirka 5 000 och du tittar på ungefär, detta toppar med 100 samtidiga anslutningar. Detta görs efter; detta är innan. Så vad min verkliga efterfrågan på systemet, om den här saken skulle kunna skalas, ligger inom 300 000. I gamla dagar, med det klassiska användargränssnittet, tittar du på 30 samtidiga anslutningar.
Vad det här säger er att Fluid UI använder minst 10x antal samtidiga anslutningar. Vi börjar dra tillbaka vad som händer under omslaget med PeopleSoft så att du kan börja se påverkan på webbservrarna, det faktum att SLA: er börjar bryta. Inte kommer att gå in på allt, men det som slutar hända är att de i princip förlitar sig på meddelanden. De utövar i princip WebLogic och orsakar kö i Tuxedo. Det var faktiskt ett flertal beroendeproblem som dykte upp med Fluid UI, men Precise kunde visa att vi genom en hel massa olika saker kan fokusera på vad problemet var. Det visar sig att det också fanns ett problem i själva databasen. Det finns faktiskt en meddelandeloggfil, och på grund av alla samtidiga användare låste den loggfilen. Det hade i princip saker att stämma, i varje nivå i applikationsbunten. Prata om komplexitet, här är faktiskt Tuxedo-nivån som visar dig kö och du kan se prestanda förnedrande inom detta nivå också. Jag kunde se processerna; Jag kunde se domänerna och servrarna. I Tuxedo, för att människor ska använda det, vanligtvis vad du gör är att du öppnar upp ytterligare köer, domäner och servrar, precis som i snabbköpet för att lindra överbelastningen, för att minimera kötiden. Det sista och sista alternativet, Precise visar mycket information.
Som jag nämnde tidigare interagerar varje betydande transaktion med journalsystemet. Synlighet i databasen är av största vikt. Precise visar vad som händer i databasen, inom WebLogic, inom Java, .NET, i webbläsaren, men platsen som Precise verkligen utmärker finns i databasnivån. Detta råkar vara vår konkurrents svaghet. Låt mig visa dig ett av de sätt som Precise kan hjälpa dig att gå igenom. Jag tänker inte spendera tid på triangeln för databasoptimering, men vi tittar i princip på lågkostnad, låg risk, till omfattande, hög risk, högkostnadsförändringar. Jag tweetar faktiskt ut denna bild efteråt om folk vill försöka titta på den. Det är en ganska stor guide, tror jag, för att ställa in problem. Här är expertvyn för Precise for Oracle. Överst på rapporten om resultat är 60 procent inverkan just detta SQL-uttalande. Om du öppnar upp den här aktivitetsskärmen visas den där uppe. Jag kan titta på detta utvalda uttalande, det finns en körplan. Varje körning tar en sekund - 48 000 avrättningar. Det ger upp till 48 000 timmar mer avrättningar.
Den mörkblå, återigen, är CPU. Den här saken är CPU-bunden, inte ett väntetillstånd, inte en logg. Jag betonar att eftersom några av våra konkurrenter bara tittar på väntetillstånd och loggningsevenemang men generellt sett är CPU det mest trafikerade utförande och erbjuder mest återköp. Att komma in i denna expertvy - och jag går väldigt snabbt - vad jag gjorde är att jag tittade på bordet, 100 000 rader, 37 000 block. Vi gör en fullständig tabell, men vi har sex index på den här saken. Vad händer här? Tja, när jag tittar på var-klausulen, vad detta där klausulen gör är att det faktiskt konverterar en kolumn till versaler och det säger var det är lika med versaler, hitta variabel. Det som händer är att varje gång denna sak körs måste Oracle konvertera den här kolumnen till versaler. Istället för att göra det nästan femtiotusen gånger, är det mycket effektivare att bygga det indexet i stora bokstäver av ett funktionsbaserat index och det är tillgängligt inte bara i Oracle företagets division, även standardavdelning. När du gör det, vad du då kan göra är att verifiera exekveringsplanen som utfärdar den nya indexanvändaren perm-versaler, det var bara en typ av min grej.
Sedan, från en mätning före och efter, tittar du på en sekunders exekveringstid, aggregerar upp till 9 timmar 54 minuter, med samma exakta SQL-uttalande, men har det indexet inbyggt med stora bokstäver för 58 000 exekveringar, svaret tiden sjunker till under millisekunder, sammanställs tillsammans, det kommer upp till sju sekunder. Jag sparade i princip tio timmar CPU på min server. Det här är enormt. För om jag inte ska ha en serveruppdatering kan jag leva på den servern. Jag tappar faktiskt denna serveranvändning med 20 procent och du kan faktiskt se före och efter. Det är den typen av synlighet som Precise kan ge. Det finns också några ytterligare saker som vi kan se ut, varför har du alla dessa index om de inte används? De kan följa upp det. Det finns arkitektur, och jag kommer att packa upp det eftersom vi når toppen av timmen. Jag är en sann troende i den här lösningen och vi vill att du ska vara en sann troende. Hos IDERA tror vi att en rättegång gör en kund, så om du är intresserad kan vi göra utvärderingar på din webbplats.
Med det kommer jag att gå tillbaka fyret.
Eric Kavanagh: Ja det har varit en enorm detalj som du visade där. Det är verkligen ganska fascinerande. Jag tror att jag kanske har nämnt för dig tidigare - och jag vet i några av de andra webbsändningarna som vi har gjort med IDERA, jag har nämnt det - jag har faktiskt spårat exakt sedan innan det förvärvades av IDERA, hela vägen tillbaka till 2008, tror jag, eller 2009. Jag blev fascinerad av det då. Jag är nyfiken på att veta hur mycket arbete som ligger i att hålla sig uppe på nya versioner av applikationer. Du nämnde att SAP HANA, som jag tycker var ganska imponerande att du faktiskt kan gräva in i HANA-arkitekturen och göra lite felsökning där. Hur många har du? Hur mycket av din ansträngning är det från din sida och hur mycket av det kan göras något dynamiskt, vilket innebär att när verktyget distribueras börjar du krypa runt och se olika saker? Hur mycket av det kan dynamiskt, sorteras, fastställas av verktyget, så att du kan hjälpa människor att felsöka komplexa miljöer?
Bill Ellis: Du ställde många frågor där.
Eric Kavanagh: Jag vet, ledsen.
Bill Ellis: Jag tillhandahöll mycket detaljer eftersom för dessa applikationer, när jag tittar på koden, är djävulen i detalj. Du måste ha den detaljeringsnivån för att verkligen kunna ha något som är handlingsbart. Utan handlingsvärden kan du bara veta om symtom. Du löser faktiskt inte problem. IDERA handlar om att lösa problem. Att hålla sig uppdaterad med nya utgåvor och grejer är en stor utmaning. Frågan om vad som krävs för att göra det, det är verkligen för produkthantering. Jag har inte mycket synlighet i teamet som i princip håller oss uppdaterade om saker. När det gäller HANA är det faktiskt ett nytt tillägg till IDERA: s produktlinje; det är väldigt spännande. En av sakerna med HANA är - låt mig prata om uppgiften en sekund. I uppgiften skulle SAP-butikerna göra att de skulle replikera databasen för rapporteringsändamål. Då måste du låta folk förena sig med vad som faktiskt är aktuellt. Du skulle ha dessa olika databaser och de kan inte synkroniseras på olika nivåer. Det finns bara mycket tid och ansträngning, plus hårdvaran, programvaran och människor för att upprätthålla allt detta.
Idén med HANA att ha en mycket parallell databas i minnet, för att i princip undvika behovet av duplicerade databaser. Vi har en databas, en sanningskälla, den är alltid uppdaterad, på det sättet undviker du det som behövs för att göra all den försoningen. Betydelsen av prestanda för HANA-databasen ökar - jag kommer att säga 10x eller åtminstone mer värdefullt än summan av alla andra databaser, hårdvara och resurser kan köpa. Att kunna hantera HANA, nu är den komponenten faktiskt i betatest just nu, det är något som kommer att gå GA snart. Så det är ganska spännande för IDERA och för oss att i princip stödja SAP-plattformen. Jag är inte säker på vilka andra delar av din fråga som jag har kortväxlat men -
Eric Kavanagh: Nej, det är alla bra saker där inne. Jag kastade ett helt gäng på dig på en gång, så ledsen för det. Jag är bara fascinerad, verkligen, jag menar att det här inte är en enkel applikation, eller hur? Du gräver djupt in i dessa verktyg och förstår hur de interagerar med varandra och till din mening, du måste berätta historien tillsammans i ditt huvud. Du måste kombinera bitar av information för att förstå vad som faktiskt händer och vad som orsakar problem, så att du kan gå in där och lösa dessa problem.
En deltagare frågar, hur svårt är det att implementera Precise? En annan person frågade, vem är folket - uppenbarligen DBA - men vem är några andra roller i organisationen som skulle använda dessa verktyg?
Bill Ellis: Precise är lite mer komplicerat att distribuera. Du måste ha viss kunskap om applikationsmiljön, i termer av, du vet, den här applikationen körs i den här databasen, den behöver eller - mellanliggande webbservrar, etc. Jag tror med tanke på komplexiteten hos några av dessa applikationer, det är faktiskt relativt enkelt. Om jag kan anpassa webbservern till din databas, kan jag göra det från ett till slut. Du märker att jag inte sa något om att instrumentera en slutanvändarklient och det beror på att det vi gör är att vi faktiskt inkluderar dynamiskt, så att du inte behöver ändra din kod eller något annat. En JavaScript går in i applikationssidan. Oavsett var användaren befinner sig i världen, när de kommer till URL: en från din applikation och de tar ner den sidan, kommer det instrumenterat med Precise. Det gör att vi kan välja ut användar-ID, deras IP-adress, även den första byte-återgivningstiden för varje sidkomponentens skriptkörningstid i slutanvändarwebbläsaren.
När det gäller transaktionerna behöver du inte kartlägga transaktionerna eftersom de är tätt kopplade. Denna URL blir en post till JVM och åberopas sedan det här meddelandet, vilket resulterar i en JVC fångad från databasen. Vi kan i princip fånga de naturliga anslutningspunkterna och sedan presentera dem för dig på den transaktionsskärmen som jag visade dig där vi också beräknade hur mycket tid, eller procentandelen av tiden som spenderades i varje enskilt steg. Allt detta görs automatiskt. Generellt sett tilldelar vi 90 minuter att göra - för att i princip installera den Precise kärnan och sedan börjar vi implementera applikationen. Beroende på kunskapen om applikationen kan det ta några extra sessioner för att få hela applikationen instrumenterad. Många använder bara databaskomponenten i Precise. Det är okej. Du kan i princip bryta detta, dela upp det i de komponenter som du känner att din webbplats behöver. Vi tror definitivt att sammanhanget med att ha hela applikationsbunken instrumenterad så att du kan se att nivå-till-nivåberoende faktiskt förstorar värdet av att övervaka en individuell nivå. Om någon vill utforska instrumentets applikationsstapel ytterligare, gå till vår webbplats - jag antar att det är det enklaste sättet att begära ytterligare information, och vi kommer att diskutera det lite längre.
Eric Kavanagh: Låt mig kasta en eller två snabba frågor till dig. Jag gissar att du samlar in och bygger upp ett arkiv över tid, både för enskilda kunder och som ett företag som helhet, av interaktioner mellan olika applikationer och olika databaser. Med andra ord, jag antar att det är vad jag hänvisar till. Är det så? Underhåller du faktiskt ett slags förvar med vanliga scenarier så att du kan komma med förslag till slutanvändare när vissa saker spelar in? Som den här versionen av E-Business Suite, den här versionen av denna databas, etc. - gör du mycket av det?
Bill Ellis: Tja, den typen av information är inbyggd i resultatrapporten. Resultaten rapporten säger vad är prestanda flaskhalsar, och det är baserat på körningstiden. En del av fyndrapporten är att lära sig mer och vad gör du sedan. Informationen eller erfarenheten från kunder och så vidare är i princip integrerad i det biblioteket med rekommendationer.
Eric Kavanagh: Okej, det låter bra. Tja folkens, fantastisk presentation idag. Bill, jag älskade hur mycket detalj du hade där. Jag tyckte bara att det här var riktigt fantastiskt, skitigt, kornigt uppgifter, som visade hur allt detta görs. Vid en viss tidpunkt är det nästan som svart magi, men det är det inte. Det är väldigt specifik teknik som ni sätter ihop för att förstå väldigt, mycket komplexa miljöer och göra människor lyckliga eftersom ingen gillar när applikationer kör långsamt.
Tja folkens, vi kommer att arkivera denna webcast. Du kan hoppa online till Techopedia eller insideanalysis.com och wow, tack för din tid, vi kommer att komma ikapp dig nästa gång. Var försiktig, adjö.
