Door Techopedia Staff, 2 november 2016
Afhaalmaaltijd: gastheer Eric Kavanagh bespreekt applicatieprestaties en hoe de efficiëntie te verbeteren met Dr. Robin Bloor, Dez Blanchfield en Bill Ellis van IDERA.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: Dames en heren, hallo en weer welkom bij Hot Technologies. Ja inderdaad! Mijn naam is Eric Kavanagh, ik zal uw gastheer zijn voor een nieuwe webcast vandaag in deze echt leuke, opwindende serie die we hebben als een compliment voor onze Briefing Room-serie. De titel is "Applicatie versnelling: snellere prestaties voor eindgebruikers." Kom op mensen, wie wil dat niet? Als ik de man ben die je applicatie helpt sneller te werken, denk ik dat ik de man ben die bier voor me gekocht aan de bar na het werk. Het moet best cool zijn om binnen te komen en iemands applicatie te versnellen.
Er is echt een dia over die van jou, sla me op Twitter @Eric_Kavanagh. Ik probeer altijd terug te volgen en ik tweet altijd als je me noemt, dus voel je vrij om me te vermelden.
Het hele doel van deze show is om zich te concentreren op verschillende aspecten van bedrijfstechnologie en echt te helpen bij het definiëren van bepaalde disciplines of bepaalde gezichten, als je wilt. Vaak zullen verkopers bepaalde marketingvoorwaarden oppikken en praten over hoe ze dit of dat of iets anders doen. Deze show is echt ontworpen om ons publiek te helpen begrijpen wat een softwaretool moet hebben om een leider in zijn ruimte te zijn. De indeling hiervan is twee analisten. Elke keer als eerste, in tegenstelling tot de Briefing Room waar de verkoper als eerste gaat. Elk geeft zijn mening over wat zij belangrijk vinden voor u om te weten over een bepaald soort technologie.
Vandaag hebben we het over app-versnelling. We gaan het horen van Dez Blanchfield en ook Doctor Robin Bloor - we zijn vandaag over de hele wereld - en dan belt Bill Ellis vanuit de regio Virginia. Daarmee ga ik het overhandigen aan onze eerste presentator, Dr. Bloor. We hebben trouwens de hashtag van #podcast getweet, dus voel je vrij om te tweeten. Haal het weg.
Dr. Robin Bloor: Oké, bedankt voor die introductie. Applicatieprestaties en serviceniveaus - dit is een soort van gebied, ik heb in de loop der jaren veel werk op dit gebied gedaan, in die zin dat ik eigenlijk heel veel werk heb verricht in het bewaken van prestaties en in één op een of andere manier, hoe je die niveaus probeert te berekenen. Het moet gezegd worden dat we dit tijdperk, een tijd geleden, hadden waarin mensen systemen in silo's bouwden. Kortom, de hoeveelheid werk die ze eigenlijk moeten doen om een systeem redelijk goed te laten presteren als het in een silo stond, was eigenlijk niet zo moeilijk omdat er heel weinig, heel kleine hoeveelheden variabelen waren waarmee je rekening moest houden. Zodra we een goed netwerk kregen, kwamen interactieve en servicegerichtheid in de vergelijking. Het werd een beetje moeilijk. Prestaties kunnen eendimensionaal zijn. Als u denkt aan een toepassing die herhaaldelijk een bepaald codepad uitvoert, dit redelijk en tijdig doet, voelt het als een eendimensionale zaak. Zodra je over serviceniveaus begint, heb je het eigenlijk over meerdere dingen die strijden om computerresources. Het wordt zeer snel multidimensionaal. Als u over bedrijfsprocessen begint te praten, kunnen bedrijfsprocessen vanuit meerdere applicaties aan elkaar worden gekoppeld. Als je het hebt over servicegeoriënteerde architectuur, heeft een bepaalde toepassing mogelijk toegang tot de mogelijkheden van meerdere toepassingen. Dan wordt het een zeer gecompliceerde zaak.
Ik keek naar - lang geleden heb ik dit diagram getekend. Dit diagram is minimaal 20 jaar oud. Kortom, ik noem het het Diagram van alles omdat het een manier is om naar alles te kijken wat er in de IT-omgeving bestaat. Het bestaat eigenlijk maar uit vier delen: gebruikers, data, software en hardware. Natuurlijk veranderen ze in de loop van de tijd, maar je realiseert je eigenlijk wanneer je dit bekijkt dat er een hiërarchische explosie is van elk van deze stukken. Een hardware ja, een hardware kan een server zijn, maar een server bestaat uit mogelijk meerdere CPU's, netwerktechnologie en geheugen, en dit zijn nogal wat controllers. Als je hier echt naar kijkt, valt het allemaal uiteen. Als je er echt aan denkt om dat alles te orkestreren, met betrekking tot gegevens die veranderen, verandert de prestaties van de software, omdat de hardware verandert, enzovoort, je kijkt eigenlijk naar een ongelooflijk moeilijke situatie met meerdere variabelen. Dit is de complexiteitscurve. Het is natuurlijk de complexiteitscurve voor zowat alles, maar ik heb het steeds opnieuw getekend als ik het over computers heb. Kortom, als u knooppunten op de ene as plaatst en de belangrijke verbindingen op de andere as, krijgt u een complexiteitscurve. Het maakt bijna niet uit wat de knooppunten en verbindingen zijn en dat is voldoende als u een weergave wilt van de volumegroei in het telefoonnetwerk.
Als je het over knooppunten in de computeromgeving hebt, heb je het eigenlijk over afzonderlijke dingen die om elkaar geven. Complexiteit, zo blijkt, is een kwestie van variëteitstructuur en de verschillende beperkingen die je probeert te gehoorzamen. Ook de cijfers. Wanneer de cijfers omhoog gaan, worden ze gek. Ik had gisteren een interessante chat, ik sprak met iemand - ik kan niet vermelden wie hij was, maar het maakt niet echt uit - ze hadden het over een site met 40.000 - dat is vier-nul, 40.000 - instanties van databases op de site. Denk daar maar eens over na - 40.000 verschillende databases. Natuurlijk was het enige dat we hadden - ze hadden duidelijk vele, vele duizenden toepassingen. We hebben het over een zeer grote organisatie, maar ik kan het niet noemen. Je kijkt daar eigenlijk naar, en je probeert eigenlijk op een of andere manier serviceniveaus te krijgen die over de hele linie voldoende zullen zijn voor een aantal meerdere gebruikers, met meerdere verschillende, als je wilt, verwachtingen. Het is een complexe situatie, en dat is eigenlijk het enige dat ik zeg. Het aantal neemt altijd toe. De beperkingen worden bepaald door bedrijfsprocessen en bedrijfsdoelen. U zult gemerkt hebben dat de verwachtingen veranderen.
Ik herinner me dat zodra Gmail, en Yahoo-mail en Hotmail, al die e-mailsystemen opkwamen, mensen begonnen te verwachten dat hun interne e-mailsystemen binnen de organisatie de serviceniveaus van deze enorme operaties zouden verdienen met enorme serverfarms buiten de organisatie en begon onder druk te staan om al dat soort dingen te laten gebeuren. Service-level agreements zijn eigenlijk één ding, maar verwachting is iets anders en ze vechten tegen elkaar binnen een organisatie, een ongemakkelijke zaak. Dit is slechts een zakelijk perspectief. In sommige systemen is de optimale responstijd een tiende van een seconde menselijke reactietijd. Een tiende van een seconde is de tijd die een cobra nodig heeft om je te bijten. Als je voor een cobra staat en besluit om je te bijten, is het te laat, komt het omdat je niet in een tiende van een seconde kunt reageren. Een tiende van een seconde is ongeveer de tijd die de bal nodig heeft om de hand van de werper te verlaten om de man met de knuppel te bereiken. Kortom, als hij de bal ziet gooien, moet hij precies op dat moment reageren. Menselijke reactie, nogal interessant. Software-naar-software, kan uiteraard een hogere verwachting hebben.
Dan kom je in een aantal situaties waarvan ik denk dat het die marktsituaties zijn, waarbij de eerste is waar de bedrijfswaarde is. Dit is hetzelfde als wanneer u een bepaald aandeel op de aandelenmarkt wilt verkopen, waarschijnlijk minder, omdat u denkt dat het daalt en veel andere mensen denken dat het daalt, u de beste prijs krijgt als u eerst op de markt komt. Er zijn veel situaties, advertentieweergave en dergelijke, zeer vergelijkbare situaties. Je hebt deze beweging in termen van servicelevelverwachting. Je hebt een ding dat een soort glazen plafond is voor menselijke reactie. Als het eenmaal software-naar-software is, en u hebt deze plafondsituatie, dan is er geen beste serviceniveau. Sneller dan iedereen is de beste.
Oké, dit is denk ik de laatste dia die ik aan het doen was, maar dit is alleen om je een groot beeld te geven van de complexiteit, als je eenmaal kijkt naar de vereisten van een organisatie, de service. Je hebt, hier aan de linkerkant omhoog, je hebt systeembeheer, een set software die dienst doet voor servicebeheer, die probeert een serviceniveau te beheren. Daarboven heb je business performance management. Als u dan naar beneden kijkt, het gebied voor automatisering van servicebeheer, hebt u gefragmenteerde services die evolueren naar gestandaardiseerde services, als u echt wilt investeren in dit soort dingen, die evolueren naar geïntegreerde services, die evolueren naar geoptimaliseerde services. . Meestal hebben mensen dit gedaan, alleen in de linkerbenedenhoek hiervan. Misschien een beetje servicebeheer. Beheer van bedrijfsprestaties, zeer zeldzaam. Gefragmenteerd, bijna alles. Een perfecte wereld zou dat rooster vullen. Instrumentatie - ik noemde een suboptimalisatieprobleem. U kunt delen van een systeem optimaliseren en het is niet goed voor het hele systeem. Als u het hart optimaal maakt, kan uw bloed te snel circuleren voor de rest van uw organen. Dat is een probleem met grote organisaties en serviceniveaus. Het is duidelijk dat er niets wordt bereikt zonder geavanceerde tools, omdat de variabelen net zijn binnengekomen - nou, er zijn te veel variabelen om te proberen te optimaliseren.
Dat gezegd hebbende, zal ik doorgeven aan Dez die hopelijk over iets anders zal praten.
Dez Blanchfield: Bedankt, Robin. Net als Dr. Robin Bloor heb ik veel te veel jaren besteed aan het nadenken over de prestaties van zeer complexe systemen op zeer grote schaal. Waarschijnlijk niet helemaal dezelfde schaal als Robin, maar prestaties zijn een dagelijks onderwerp en het zit in ons DNA om prestaties te willen, om het beste uit alles te halen. Ik heb zelfs een afbeelding gebruikt van een van mijn favoriete dingen ter wereld, Formule I autoracen, waar de hele planeet een tijdje stilstaat en auto's heel snel in cirkels rond ziet rijden. Elk aspect, er is geen aspect van Formule I dat niet specifiek draait om het verkrijgen van prestaties. Veel mensen poepen de sport omdat ze het zonde van het geld vinden. Het blijkt dat de auto waarmee we elke dag rijden om de kinderen in het weekend en op school de andere dagen op voetbal te zetten, is afgeleid van prestatiegerichte ontwikkeling en onderzoek. Het is een beetje het leven van Formule I autoracen. Alledaagse technologie, alledaagse wetenschap, komt vaak van iets dat puur gericht is op hoge prestaties.
De realiteit is echter dat onze nieuwe "altijd aan" -wereld, die 100% uptime vereist - zoals Robin eerder zei - met dingen zoals de introductie van webmail en andere services die we als vanzelfsprekend beschouwen in een continue ruimte, en we verwachten nu dat in onze onderneming en werkomgeving. De realiteit is dat opkomen niet altijd betekent dat je aan je serviceniveauovereenkomst voldoet. Ik neem aan dat het noodzakelijk is om de prestaties van applicaties te beheren en dat overeenkomsten op serviceniveau de afgelopen tien jaar een fundamentele verandering hebben ondergaan. We proberen ons niet alleen meer zorgen te maken over de prestaties van één systeem. Toen de wereld een beetje eenvoudiger was, hebben we mogelijk een situatie waarin een enkele server waarop meerdere services worden uitgevoerd live kan worden gevolgd en het relatief eenvoudig was om te ondersteunen. We konden - en hier is mijn kleine, de dingen waar we ons vroeger zorgen over maakten toen ik bijvoorbeeld een systeembeheerder was, vele jaren geleden - zouden we rondkijken, is de service typisch up and response? Kan ik bijvoorbeeld inloggen op een terminal? Reageert het besturingssysteem en kan ik opdrachten typen? Zijn de applicaties actief? Kan ik processen en geheugen zien in dingen en I / O in het netwerk, enzovoort? In de mainframedagen hoorde je tapes gaan zip-zip-zip en papier eruit vallen.
Reageren de apps en kunnen we inloggen en er dingen aan doen? Kunnen de gebruikers verbinding maken met sommige van die servers? Het gaat maar door. Ze zijn vrij fundamenteel, weet je. Dan een paar grappige - is de helpdesk groen? Want zo niet, dan gaat alles goed, en wie krijgt de donuts? Het leven was toen heel eenvoudig. Zelfs in die dagen, en dan heb ik het over 20-30 jaar geleden, was de complexiteit nog steeds erg hoog. We kunnen op een relatief eenvoudige manier overeenkomsten op serviceniveau beheren en de prestaties in de gaten houden. We kunnen het niet meer met de hand doen, zoals Robin al zei. De uitdaging is te groot. Feit is het moment waarop een paar goede apps, beheerders, systeemnetwerk en database beheerders prestatie-SLA's kunnen controleren en voldoen. SLA's zijn nu zo ver weg dat ik het moeilijk had gisteravond toen ik mijn laatste aantekeningen aan het samenstellen was om zelfs aan het jaar te denken waarin ik voor het laatst in staat was om naar een systeem van een zeer complexe stapel te kijken, het te begrijpen en zelfs te begrijpen wat gaande onder de motorkap, en ik kom uit een diep technische achtergrond. Ik kan me niet voorstellen hoe het is om daar nu op een administratieve basis dagelijks mee geconfronteerd te worden.
Wat is er gebeurd? Welnu, in 1996 werden database-gestuurde apps getransformeerd met de opkomst van internet. Velen van ons hebben dat meegemaakt. Zelfs als je niet in de buurt van internet bent, kun je eenvoudig rondkijken en beseffen dat we in het dagelijks leven alles aan internet koppelen. Ik geloof dat we een broodrooster hebben dat blijkbaar wordt geleverd met de optie om op wifi te gaan, wat belachelijk is, omdat ik mijn broodrooster niet op internet moet aansluiten. In de jaren 2000, met name de vroege jaren 2000, hadden we te maken met deze enorme groei in complexiteit rond het leveren van serviceprestaties in dot-com boom. Toen nog een belachelijke onhandige vonk in web 2.0, waar smartphones tot stand kwamen en nu applicaties 24/7 in onze handen waren en altijd aan stonden.
Het is nu 2016, we worden geconfronteerd met een ander moeras in de vorm van cloud en big data en mobiliteit. Dit zijn systemen die net zo groot zijn dat ze vaak moeilijk te begrijpen en in gewoon Engels te beschrijven zijn. Wanneer we denken aan het feit dat sommige van de grote eenhoorns waar we het over hebben tientallen honderden petabytes aan gegevens hebben. Dit is de volledige verdieping met schijfruimte en opslag, alleen voor uw e-mail, afbeeldingen en sociale media. Of in sommige gevallen, in transport- en verzendlogistiek, zit het allemaal in bankieren, het is waar uw geld is, of waar uw post is, of uw, waar het ding dat u op eBay hebt gekocht, is. De volgende grote golf waar we voor staan, is deze zeer zware uitdaging van het internet der dingen.
Als dit niet erg genoeg was, gaan we kunstmatige intelligentie en cognitief computergebruik in zo ongeveer alles inbouwen. We praten tegenwoordig met Siri en Google-engines. Ik weet dat Amazon er een heeft. Baidu heeft een van deze apparaten waar je mee kunt praten, ze converteren het naar tekst die naar een normaal systeem gaat, de database voert een zoekopdracht uit en keert terug en keert het proces om. Denk na over de complexiteit die daarbij hoort. De realiteit is dat de complexiteit van de huidige standaardapplicatiestack de menselijke mogelijkheden ver te boven gaat. Als je denkt aan alles wat er gebeurt wanneer je op een knop op je smartphoneapparaat of je tablet drukt, praat je ermee, converteert dat naar tekst, voert dat helemaal naar het internet uit naar een back-endsysteem, ontvangt een front-end dat, converteert het naar een query, voert de query uit via een applicatiestack, doorloopt een database, raakt schijf, komt er weer uit, en in het midden is er een carriernetwerk, er is een LAN-statuscentrum. De complexiteit is gek.
We beweren dit effectief als hyperscale. De complexiteit en snelheid van hyperscale is gewoon watertanden. Toepassingen en databases zijn zo groot en zo complex geworden dat het beheren van prestaties in feite een wetenschap op zich is. Velen noemen het een raketwetenschap. We hebben onsite technologie, we hebben offsite technologie, we hebben een reeks opties voor datacenters; fysiek en virtueel. We hebben fysieke en virtuele servers, we hebben cloud, we hebben infrastructuur als service en platform als service en software als service is iets dat we nu als vanzelfsprekend beschouwen. De laatste, software als een service, werd een tijdje geleden een paar jaar geleden eng toen CFO's en delen van de organisatie zich realiseerden dat ze hun creditcard konden ophalen en gewoon dingen zelf konden kopen en rond de CIO konden gaan en eigenlijk noemden we dit "schaduw" IT 'en de CIO's proberen dit nu terug te wikkelen en de controle weer terug te krijgen.
In de infrastructuur hebben we softwaregedefinieerde netwerken, netwerkfunctievirtualisatie, hieronder hebben we, waarschijnlijk voorbij, nu hebben we microservices en apps met actieve services. Wanneer u op een URL klikt, staat er een reeks bedrijfslogica aan het einde van die URL die beschrijft wat deze nodig heeft om deze daadwerkelijk te leveren. Er hoeft niet altijd een vooraf gebouwde logica op te wachten. We hebben traditionele databases aan de ene kant die heel, heel groot zijn. We hebben de Hadoop-infrastructuur en ecosystemen in het andere spectrum die net zo groot zijn dat, zoals ik al zei, weet je, mensen nu over honderden petabytes aan gegevens praten. We hebben complexiteitsmobiliteit tot apparaten die meeslepen, laptops en telefoons en tablets.
We hebben BYOD in sommige gesloten omgevingen en steeds meer nu, omdat de Gen Y-ervaren mensen hun eigen apparaten meenemen. We laten ze gewoon met hen praten over webinterfaces. Of het nu via internet is of via wifi, we hebben gratis wifi in het café beneden terwijl ze koffie drinken. Of onze interne wifi. Machine-to-machine is nu altijd aanwezig. Dat is niet direct onderdeel van het internet der dingen, maar het is ook gerelateerd. Internet of Things is een geheel nieuw spel met een complexiteit die je verbijstert. Kunstmatige intelligentie, en als je denkt dat waar we nu mee spelen, met alle Siri en andere gerelateerde apparaten die we spreken complex is, wacht dan tot je een situatie ziet waarin je iets ziet dat de Olli wordt genoemd, wat een 3D is gedrukte bus die ongeveer zes personen neemt en zichzelf rond de stad kan rijden en je kunt er gewoon Engels tegen spreken, en hij zal tegen je spreken. Als het verkeer raakt, zal het beslissen om links of rechts af te slaan van het hoofdgebied waar verkeer is. Terwijl het draait en je je zorgen maakt over waarom het links of rechts van de hoofdweg af is gedraaid, zal het tegen je zeggen: “Maak je geen zorgen, ik sta op het punt naar links te gaan. Er staat verkeer voor de boeg en ik ga er omheen. '
Het beheren van de prestaties van alle systemen daar en alle complexiteit, bijhouden waar die gegevens naartoe gaan, of ze de database ingaan, alle interconnects en alle relevante bits is gewoon verbijsterend. De realiteit is dat het beheren van prestaties en SLA's met de snelheid en schaal van vandaag hulpmiddelen en systemen vereist, en standaard is dit niet langer iets waarvan u alleen maar zou denken dat het leuk zou zijn om een hulpmiddel te hebben - het is een vereiste; het is gewoon absoluut noodzakelijk. Hier is iets als een klein voorbeeld, een lijst met de ontwerpdiagrammen op hoog niveau voor de OpenStack, open-source softwaregedefinieerde cloud. Dit is gewoon een groot stuk. Dit zijn niet alleen servers en databases. Dit is waar elke kleine blauwe blob clusters van dingen vertegenwoordigt. In sommige gevallen worden bestanden en servers of honderden databases of natuurlijk niet meer dan tienduizenden kleine stukjes applicatielogica uitgevoerd. Dat is een kleine versie. Het is echt heel verbijsterend als je begint na te denken over de complexiteit die hierin ontstaat. Vandaag, zelfs in alleen de big data-ruimte, zal ik slechts enkele screenshots van alleen de merken maken. Als je nadenkt over alle onderdelen die we hier moeten beheren, hebben we het niet alleen over één merk, dit zijn allemaal merken in het big data-landschap en het topmerk, niet alleen elke kleine of open source. Je kijkt en je denkt dat het nogal een verbijsterende grafiek is.
Laten we een paar verticale lijnen bekijken. Laten we bijvoorbeeld marketing nemen. Hier is een vergelijkbare grafiek, maar alleen van de technologiestapels die alleen in marketingtechnologie beschikbaar zijn. Dit is de grafiek voor 2011. Hier is de 2016-versie. Denk maar aan, dit is slechts het aantal merken van producten dat u kunt uitvoeren voor technologie met betrekking tot marketingtechnologie. Niet de complexiteit van de systemen daarbinnen, niet de verschillende app en web en ontwikkeling en netwerk en al het andere. Alleen het merk. Er is de vorige, vijf jaar geleden en hier is vandaag. Het wordt alleen maar erger. We zijn nu op dit punt waar de realiteit is dat mensen gewoon niet kunnen zorgen voor alle overeenkomsten op serviceniveau. We kunnen niet in voldoende detail duiken, snel genoeg en op de schaal die we nodig hebben. Hier is een voorbeeld van hoe een bewakingsconsole er nu uitziet. Dit is als bijna eenentwintig schermen die aan elkaar zijn gelijmd en doen alsof ze één groot, groot geprojecteerd scherm zijn dat elk klein stukje bewaakt. Nu is het hier interessant, ik zal het merk niet noemen, maar dit monitoringplatform bewaakt een enkele applicatie in een logistieke en verzendomgeving. Slechts één app. Als je nadenkt over waar Robin het over had, waar organisaties nu 40.000 databases in productieomgevingen kunnen hebben. Kun je gewoon visualiseren hoe 40.000 versies van deze verzameling schermen die één applicatie bewaken eruit zouden kunnen zien? Het is een heel dappere wereld waarin we leven. Zoals Robin al zei en ik zal absoluut, 100 procent echoën dat, zonder de juiste tools, zonder de juiste ondersteuning en mensen op de tafel met behulp van die tools, applicatieprestaties een verloren spel zijn voor de mens en het moet worden gedaan door tools en software.
Daarmee zal ik overgaan naar onze vrienden in IDERA.
Eric Kavanagh: Oké, Bill.
Bill Ellis: Bedankt. Mijn scherm hier delen. Ik denk dat iemand kan bevestigen dat je mijn scherm kunt zien?
Dr. Robin Bloor: Ja.
Eric Kavanagh: Het ziet er goed uit.
Bill Ellis: Bedankt. Het enige waar hij naar verwees was, waar ik echt niet op kan wachten, was de zelfrijdende auto. Het enige waar ik nog niemand over had horen praten, wat gebeurt er als het sneeuwt? Ik vraag me af of de ingenieurs in Californië zich realiseerden dat het in andere delen van het land behoorlijk sneeuwt.
Dez Blanchfield: Dat vind ik leuk, die ga ik onthouden.
Eric Kavanagh: Een typische anderhalve kilometer per uur.
Bill Ellis: We zijn hier om te praten over applicatieprestatiebeheer in een complexe omgeving. Een ding waar ik graag over praat, is dat veel mensen, wanneer ze het hebben over prestaties, de aard van de reactie is, hey meer servers, meer CPU, meer geheugen, enz. De andere kant van die medaille is de verwerkingsefficiëntie. Echt, dat zijn twee kanten aan dezelfde medaille en we gaan ze allebei bekijken. Het uiteindelijke doel is om te voldoen aan de service level agreements voor de zakelijke transacties. Uiteindelijk bestaat al deze technologie voor het bedrijf. We hadden het over een eersteklas database voor prestatiemanagement. Het ideaal hiervan is om in de ideale vorm van prestaties te passen en deze vanaf het begin van de levenscyclus van applicaties te beheren.
De onderwerpen komen eigenlijk neer op vier stukken; een daarvan is het proces van prestatiebeheer. We hebben met iedereen gesproken en iedereen heeft hulpmiddelen. Als ze geen tools hebben, hebben ze scripts of opdrachten, maar wat ze missen is context. Context is eenvoudigweg het verbinden van de punten over de applicatiestapels. Deze applicaties voor - zijn browsergebaseerd. Ze zijn zeer nauw van laag tot laag gekoppeld. Hoe de lagen op elkaar inwerken is ook van vitaal belang. Dan hebben we het over de zakelijke transactie. We gaan niet alleen de technische mensen zichtbaar maken, maar ook voor de eigenaars van applicaties en de operations managers.
Ik heb een paar casestudy's om gewoon met u te delen hoe klanten deze in gebruik hebben genomen. Dit is een zeer praktisch gedeelte van de presentatie hier. Laten we eens kijken wat er typisch gebeurt. Ik houd van diagrammen - het was net als een ongelooflijke collage van technologieën. Het aantal technologieën in het datacenter is zojuist gegroeid en gegroeid. Ondertussen geeft een eindgebruiker er niet om en is zich er niet van bewust. Ze willen gewoon de transactie uitvoeren, beschikbaar hebben, snel voltooien. Wat meestal gebeurt, is dat de professionals in IT niet weten dat de eindgebruikers zelfs een probleem hadden, totdat ze zelf rapporteerden. Dat begint een soort tijdrovend, traag proces en vaak frustrerend. Wat er gebeurt, is dat mensen hun tools openen en ze kijken naar een subset van hun applicatiestack. Met die subset wordt het heel moeilijk om de eenvoudigste vraag te beantwoorden. Is het gebruikelijk dat u het probleem heeft? Welke transactie is het? Waar in de applicatiestack is het knelpunt? Door al die tijd door te brengen, rij voor rij te kijken, niet in staat om deze vragen te beantwoorden, besteed je uiteindelijk veel tijd en energie, veel personeel, fondsen en energie om erachter te komen.
Om dit op te lossen, om een betere manier te bieden, is wat Precise doet eigenlijk de eindgebruiker-tracktransactie nemen, metadata vastleggen, de transactie volgen via het netwerk, in de webserver, in de bedrijfslogica en we ondersteunen .NET en ABAP en PeopleCode en E-Business Suite, in multitier-applicaties die uiteindelijk alle transacties zullen laten interageren met het recordsysteem. Of het nu gaat om het opzoeken van inventaris, het rapporteren van gewerkte tijd, ze werken altijd samen met de database. De database wordt de basis voor bedrijfsprestaties. De database vertrouwt op zijn beurt op opslag. Wat de metagegevens over de transacties beantwoorden, wie, welke transactie, waar in de applicatiestapel, en dan hebben we een diep inzicht op codeniveau om u te laten zien wat er wordt uitgevoerd. Deze informatie wordt continu vastgelegd en in de database voor prestatiemanagement geplaatst - dat voor iedereen een enkel blad wordt om te zien wat er aan de hand is. Er zijn verschillende mensen en organisaties die zich bekommeren om wat er gebeurt: de technische experts, de eigenaren van applicaties, uiteindelijk het bedrijf zelf. Wanneer een probleem naar voren komt, wilt u informatie over die transactie kunnen achterhalen.
Voordat we de beleggingstransactie gaan bekijken, wil ik je laten zien hoe dat voor verschillende mensen in de organisatie kan lijken. Op een managementlaag wilt u misschien een overzicht van meerdere applicaties. Misschien wilt u meer weten over de gezondheid die wordt berekend op basis van SLA-naleving en beschikbaarheid. Die gezondheid betekent niet dat alles 100 procent perfect werkt. Er is in dit geval ruimte om te zien dat de beleggingstransactie de waarschuwingsstatus heeft. Nu, een beetje dieper, misschien in de branche, wilt u wat meer informatie over individuele transacties, wanneer deze SLA's, transactietellingen, enz. Overtreden. Het operatieteam zal hiervan op de hoogte willen worden gebracht door een waarschuwing van soort. We hebben prestatiewaarschuwingen ingebouwd. We meten de prestaties in de browser van de eindgebruiker. Of het nu Internet Explorer, Chrome, Firefox, enz. Is, we kunnen detecteren, dit beantwoordt de eerste vraag: heeft een eindgebruiker een probleem?
Laten we erin duiken en kijken wat we daar nog meer over kunnen laten zien. De mensen die geïnteresseerd zijn in prestaties zouden Precise openen. Ze zouden de transacties evalueren. Ze zouden de SLA-kolom bekijken om transacties te identificeren die niet SLA-compliant waren. Ze zouden de eindgebruikers die er last van hadden kunnen zien, evenals wat die transactie deed toen deze door de toepassing vloeide. De manier waarop je deze hiërogliefen ontcijfert, is dit, de browser, de URL, de U is voor URL, dat is het toegangspunt tot de JVM. Nu doet deze specifieke JVM een webserver aanroepen naar de tweede JVM die vervolgens de SQL-instructie uitvoert. Dit is duidelijk een databaseprobleem omdat deze SQL-instructie verantwoordelijk was voor 72 procent van de responstijd. We zijn gericht op tijd. Tijd is de valuta van uitvoering. Het is hoe eindgebruikers ervaren of dingen langzaam lopen of niet, en het is een maat voor het verbruik van hulpbronnen. Het is erg handig; het is een soort afzonderlijke waarde die het belangrijkst is voor het evalueren van prestaties. Wanneer dit probleem wordt overgedragen aan de DBA, is het niet alleen een databaseprobleem, het is deze SQL-instructie. Dit is de context waar ik het over had.
Nu gewapend met deze informatie, kan ik naar binnen gaan en analyseren wat er is gebeurd. Ik zie allereerst dat de y-as de tijd is gedurende de dag. Pardon, de y-as is de reactietijd, de x-as is de tijd gedurende de dag. Ik zie dat er een databaseprobleem is, er zijn twee gevallen, ga terug naar die stroom, pak die SQL-instructie op en ga naar de expertweergave, waar de Precise u kan laten zien wat er gebeurt, de bedieningselementen, hoe lang die code duurt om uit te voeren. In de databaselaag is dit het uitvoeringsplan. U zult zien dat Precise het echte uitvoeringsplan heeft gekozen dat werd gebruikt tijdens de uitvoering, wat zich onderscheidt van het geschatte plan, dat zou zijn wanneer het plan werd gegeven en niet tijdens de uitvoeringstijd. Het kan al dan niet een weerspiegeling zijn van het feit dat de database dat inderdaad deed.
Hier is een analyse van de responstijd voor de SQL-instructie. Negentig procent van de tijd doorgebracht in opslag; tien procent werd in de CPU gebruikt. Ik zie zowel de tekst van de SQL-verklaring als het bevindingenrapport. De tekst van de SQL-instructie begint daadwerkelijk coderingsproblemen te onthullen. Het is uitgezochte ster; die alle rijen retourneert - neem me niet kwalijk, alle kolommen van de rijen die zijn geretourneerd. We keren extra kolommen terug die de toepassing al dan niet nodig heeft. Die kolommen verbruiken ruimte en middelen om te verwerken. Als u SAP uitvoert, is een van de grote veranderingen, omdat de HANA-database zuilvormig is, dat SAP in feite herschrijft om geen select star te kiezen, zodat ze het verbruik van bronnen sterk kunnen verminderen. Dit is eigenlijk iets dat vaak gebeurt, ook in toepassingen van eigen bodem, of het nu Java, .NET, enz. Is.
Dat scherm laat je zien wie, wat, wanneer, waar en waarom. Het waarom krijgt, zoals de SQL-instructie en het uitvoeringsplan waarmee u problemen kunt oplossen. Omdat Precise continu wordt uitgevoerd, kunt u voor en na, op het niveau van SQL-instructies, op transactieniveau meten, zodat u voor uzelf, maar ook via de eigenaars van de toepassing en voor beheer kunt meten dat u het probleem hebt opgelost . Die documentatie is echt nuttig. Deze applicatiestack bevat veel complexiteit. Van veel applicaties, in feite, iedereen waarmee we hebben gesproken, draait ten minste een deel van de applicatiestack onder VMware. In dit geval kijken ze naar de klantenservice-applicatie, kijken ze naar transactietijd en correleren deze met de vertraging is een virtualisatie-gebeurtenis. Nauwkeurig volgt alle virtualisatie-evenementen. We hebben een plug-in voor vCenter om dat op te halen.
We kunnen ook betwisting detecteren. Betwisting is anders dan gebruik. Wordt daadwerkelijk weergegeven wanneer een luidruchtige buurman uw gast-VM beïnvloedt, in de context van de applicatieserver van de klant. Nu kan ik inzoomen en informatie opvragen en kan ik de twee VM's zien die in dit geval strijden om CPU-bronnen. Hierdoor heb ik zichtbaarheid zodat ik naar planning kan kijken. Ik kan een gast-VM op een andere fysieke server plaatsen. Al dit soort dingen waarop je zou kunnen reageren en dan, naast dat, kan ik eigenlijk naar de code-efficiëntie kijken om het misschien minder CPU te laten gebruiken. Ik denk dat ik in deze presentatie een behoorlijk goed voorbeeld heb van hoe iemand het CPU-verbruik met orden van grootte kon verminderen.
Dat was VMware. Laten we ingaan op de code zelf, de applicatiecode. Precise zal u kunnen laten zien wat er gebeurt binnen Java, .NET, de ABAP-code, E-Business, PeopleCode, enz. Dit zijn de toegangspunten tot, in dit geval, naar WebLogic. Hier beneden is er een bevindingenrapport dat me vertelt dat het deze EJB's zijn waar je naar moet kijken, en zal me vertellen dat er ook vergrendeling gebeurde op dit systeem. Nogmaals, de details van de bedrijfslogica om te laten zien wat er aan de hand is. In dit geval kijk ik naar bepaalde gevallen; Ik steun ook clustering. Als er meerdere JVM's actief zijn, kunt u het cluster als geheel bekijken of kijken naar knelpunten binnen de afzonderlijke JVM.
Als je vast komt te zitten, kan ik uitzonderingen krijgen. De uitzondering is een beetje anders dan een prestatieprobleem. Meestal worden uitzonderingen erg snel uitgevoerd. Omdat er een logische fout is en als je die logische fout raakt, wordt deze beëindigd. We konden een stapelspoor vastleggen met een uitzondering, dit kan een hoop tijd besparen, omdat het probeert te achterhalen wat er aan de hand is, je hebt gewoon de stapelspoor, precies daar. We kunnen ook geheugenlekken vastleggen. De oplossing omvat ook de database-laag, ik kan erin gaan, ik kan de database-instantie evalueren. Nogmaals, de y-as is waar de tijd werd doorgebracht, de x-as is de tijd gedurende de dag. Er is een bevindingenrapport dat me automatisch vertelt wat er in het systeem gebeurt en waar ik naar zou kunnen kijken.
Een van de dingen in het bevindingenrapport van Precise, het kijkt niet alleen naar logs of wachtstatus - het kijkt naar alle uitvoeringsstatussen inclusief CPU, en retourneert informatie uit opslag. Opslag is een zeer belangrijk onderdeel van de applicatiestack, vooral met de komst van solid state. Informatie in die zin kan erg nuttig zijn. Voor bepaalde opslageenheden kunnen we daadwerkelijk inzoomen en laten zien wat er op individueel apparaatniveau gebeurt. Dat soort informatie - nogmaals, het is een diepe zichtbaarheid; het is breed van opzet - om u net genoeg informatie te geven om meer invloed te hebben als professional in applicatieprestaties, zodat u uw applicaties end-to-end kunt optimaliseren om aan die zakelijke transacties te voldoen.
Ik heb een aantal casestudies die ik met je wilde delen. We varen behoorlijk snel mee; Ik hoop dat ik in een goed tempo ga. Over opslag gesproken, iedereen verandert in de loop van de tijd van hardware. Er is een hardwaregarantie. Heeft het echt opgeleverd wat de verkoper je heeft verteld? U kunt dat evalueren met Precise. Je komt binnen, en wat hier is gebeurd, hebben ze in feite een nieuwe opslageenheid geplaatst, maar toen de opslagbeheerders alleen op het niveau van de opslageenheid keken, zagen ze veel strijd en dachten ze dat er een probleem zou kunnen zijn met deze nieuwe opslageenheid . Meer vanuit een end-to-end perspectief bekijken, precies om te laten zien waar dat daadwerkelijk zou gebeuren. Ze gingen eigenlijk uit van een doorvoer van ongeveer 400 meg per seconde, waarbij de opslag verantwoordelijk was voor 38 procent van de responstijd, dus het is behoorlijk hoog. Met de nieuwe opslageenheid hebben we de doorvoersnelheid verhoogd tot zes, zevenhonderd meg per seconde, dus eigenlijk het dubbele, en we kunnen de bijdrage van de opslaglaag aan transactietijd halveren. Ik kan dat eerder uitzetten, dit is de overgangsperiode en daarna.
Dus nogmaals, documentatie om te bewijzen dat de investering in hardware het waard was en ze leverden zoals die specifieke leverancier had verwacht. Er is alles, vanwege de complexiteit, het aantal dingen, er zijn allerlei dingen die kunnen gebeuren. In dit geval hadden ze eigenlijk een situatie waarin iedereen de DBA een beetje de schuld gaf, de DBA was als "Nou, niet zo snel." Hier kijken we eigenlijk naar een SAP-applicatie, ik denk dat dit soort scenario vrij gebruikelijk is . Wat er gebeurde, was dat ze een aangepaste transactie ontwikkelden voor een gebruiker. De gebruiker zegt: "Dit is zo traag." De ABAP-coder - dat is de programmeertaal in SAP - zei: "Dit is een databaseprobleem." Ze openden uiteindelijk Precise; ze hebben die eindgebruiker 60 seconden gemeten, dus ruim een minuut. Drieënvijftig seconden werd besteed aan de achterkant. Ze boorden zich in de achterkant en konden de SQL-instructie in aflopende volgorde weergeven.
Deze top SQL-instructie die verantwoordelijk is voor 25 procent van het bronverbruik, heeft een gemiddelde uitvoeringstijd van twee milliseconden. Je kunt de database eigenlijk niet kwalijk nemen. Weet je, hey, niet zo snel, man. De vraag is, waarom zijn er zoveel executies? Nou, ze stuiterden het terug naar de ABAP, hij ging naar binnen, keek naar het nestelen van de lus, ontdekten dat ze de database op de verkeerde plek aan het bellen waren, ze hebben in feite de wijziging doorgevoerd, de wijziging getest en nu is de nieuwe responstijd vijf seconden. Een beetje traag, maar daar kunnen ze mee leven. Veel beter dan 60 seconden. Soms is het gewoon de applicatiecode, is het de database, is het opslag? Dat zijn de gebieden waar Precise, door de context van de end-to-end transacties, dat is waar Precise in het spel komt. Je maakt eigenlijk een einde aan die dingen.
Ik kijk naar de tijd, het lijkt erop dat we nog een beetje tijd hebben om er nog een paar door te nemen. Ik stream hier doorheen. Deze applicatie is ruim een jaar in ontwikkeling. Toen ze naar QA gingen, zagen ze dat de webservers maximaal 100 procent hadden en het leek erop dat de applicatie niet kon draaien onder VMware. Het eerste wat iedereen zei was: "Doe dit fysiek aan; het kan niet draaien onder VMware. ”Precise bood hen zelfs extra manieren om het probleem op te lossen. We hebben de transacties bekeken, we zagen een webserveroproep, deze komt binnen als een ASMX in IIS.NET. Het onthulde eigenlijk de onderliggende code. Zie je dit waar ik naar wijs? Dit is 23 dagen, 11 uur. Wauw, hoe kan dat? Welnu, elke aanroep duurt 9, 4 seconden en dit ding wordt 215.000 keer aangeroepen. Voor elke aanroep gebruikt het 6 seconden CPU. Dit is de reden, deze code is de reden waarom dit ding nooit zou kunnen schalen. In feite kon het niet fysiek schalen.
Wat ze deden, is dat ze teruggingen naar hun ontwikkelaars en ze zeiden: "Kan iemand iets veranderen?" Ze hadden een soort wedstrijd, en ze testten de verschillende suggesties en kwamen met een suggestie die veel kon uitvoeren efficiënter. De nieuwe voltooide één punt, iets minder dan twee seconden, met tweehonderdste van een seconde in CPU. Nu zou dit kunnen schalen en zou het kunnen draaien op de VMware-farm. We konden dat in principe documenteren, zowel op codeniveau als op transactieniveau. Dit is een beetje het voor en daarna. Nu dat je hier kunt zien in de stapelbalkgrafiek die web, .NET en database toont, heb je nu interactie met de database. Dit is een profiel dat u zou verwachten voor een toepassing die normaler werd uitgevoerd.
Oké, ik kies en kies voor extra dingen die ik je kan laten zien. Veel mensen vinden dit leuk omdat dit veel winkels verbaast. Als u niet in staat bent om een zakelijke SLA te ontmoeten en iedereen is als: "Help ons." Deze winkel had een situatie waarin de zakelijke SLA vóór 15.00 uur in orders is ontvangen, het wordt die dag verzonden. Het is echt van vitaal belang dat ze de bestellingen ontvangen en het magazijn is erg druk. Het verkooporderscherm van JD Edwards liep vast en je kunt een heel goed idee krijgen dat dit een just-in-time systeem voor voorraadbeheer is. Lege planken zijn onaanvaardbaar in de detailhandel. Ik moet de goederen daar hebben om het te verkopen. Wat we deden is dat we doken, in dit geval kijken we naar de SQL-serverdatabase. Het uiterlijk is hetzelfde, ongeacht of het SQL, Oracle, DB2 of Sybase is.
We hebben de select van PS_PROD geïdentificeerd en we kunnen de duur vastleggen, het feit dat ze zoveel uitvoeren. Het donkerblauw kwam overeen met de sleutel die zei dat ze niet wachten op een wachttoestand of een logboekregistratie of zelfs opslag - dit ding is gebonden aan CPU. We hebben de SQL-instructie met 34301 gevolgd, dus elke keer dat deze wordt uitgevoerd, verhogen we onze tellers om deze bij te houden. Dat betekent dat we een gedetailleerde geschiedenis hebben en ik heb er toegang toe door op die afstemknop te klikken. Dit is het tabblad Geschiedenis. Dit scherm hier toont de gemiddelde duur versus veranderingen. Woensdag, donderdag, vrijdag was de gemiddelde duur ongeveer twee tienden van een seconde. Zeer weinig scherm loopt vast, ze kunnen voldoen aan de zakelijke SLA. Op 27 februari verandert er iets en ineens is de uitvoeringstijd hier, en dat is eigenlijk langzaam genoeg om time-outs te veroorzaken, wat resulteert in een bevriezing van het scherm. Nauwkeurig, door een gedetailleerde geschiedenis bij te houden, inclusief het uitvoeringsplan en algemene wijzigingen in de indexen van de tabel als die SQL wordt gebruikt. We hebben kunnen vaststellen dat het toegangsplan op 27 februari is gewijzigd. Maandag tot en met vrijdag slechte week. Op 5 maart is het toegangsplan opnieuw gewijzigd. Dit is een goede week. Deze roze ster vertelt ons dat het volume is bijgewerkt.
U kunt hier zien dat het aantal rijen in de onderliggende tabellen groeit en dit is typerend voor een bedrijf. U wilt dat uw tafels groeien. Het ding is dat de instructies parse zijn, de SQL-instructies binnenkomen, de optimizer moet beslissen wat te doen en kiezen wanneer het uitvoeringsplan snel is, een ander uitvoeringsplan kiezen wanneer het langzaam is, waardoor het scherm vastloopt. Op een diepgaande technologische basis moet ik weten wat het uitvoeringsplan is en Precise legt het voor mij vast, compleet met de datum- en tijdstempel. Dit was degene die snel en efficiënt was, dit was degene die langzaam en inefficiënt was. Deze filter join gebruikt eenvoudigweg veel meer CPU om te verzoenen, om deze specifieke SQL-instructie uit te voeren. Ze hebben nog steeds hetzelfde ultieme effect, maar deze heeft in principe een langzamer, minder efficiënt recept voor het leveren van de resultatenset. Dus we stappen erdoorheen. Hé, hebben we tijd voor nog een paar?
Eric Kavanagh: Ja, ga ervoor.
Bill Ellis: Oké, ik zal doorgaan. Eén ding waarvan ik wil dat u het noteert, we hadden het over hardware, we hadden het over SAP, we hadden het over .NET, we hadden het over JD Edwards en de Java-SQL Server-omgeving. Dit is SAP, hier kijken we naar PeopleSoft. De ondersteuningsmatrix van Precise is breed en diep. Als u een toepassing heeft, kunnen we deze hoogstwaarschijnlijk instrumenteren om dit niveau van zichtbaarheid te bieden. Een van de grootste veranderingen die zich momenteel voordoen, is mobiliteit. PeopleSoft introduceerde mobiliteit met zijn Fluid UI. De Fluid UI gebruikt een systeem heel anders. Deze applicatie evolueert. De Fluid UI - wat het doet vanuit een managementperspectief is dat het de eindgebruikers toestaat om hun telefoon te gebruiken en het verhoogt de productiviteit enorm. Als u honderden of duizenden of zelfs meer werknemers hebt, als u hun productiviteit kunt verhogen, 1-2 procent, kunt u een enorme impact hebben op de loonlijst en al het andere. Wat er gebeurde, was dat deze specifieke winkel de PeopleSoft Fluid UI heeft uitgerold. Nu we het over complexiteit hebben, dit is de PeopleSoft-stapel. Eén applicatie, minimaal zes technologie, talloze eindgebruikers. Hoe begin je eraan?
Opnieuw zal Precise deze transacties kunnen volgen. We laten u hier een gestapeld staafdiagram zien met de client, webserver, Java, Tuxedo-database, PeopleSoft-toepassingsstack. De groene kaarten naar J2EE, wat een mooie manier is om WebLogic te zeggen. Dit is de overgang. De eindgebruikers beginnen de Fluid UI te gebruiken en de responstijd gaat van misschien anderhalf, twee seconden, tot ongeveer negen, tien seconden. Wat dit ene scherm niet laat zien, is het aantal mensen dat 'niet reageerde'. Ze hebben zelfs een bevriezing van het scherm in de applicatie. Laten we eens kijken naar een deel van de zichtbaarheid die Precise deze klant kan bieden.
Allereerst, als ik naar de PeopleSoft-transacties kijk, kunnen ze zien dat we dit soort dingen overal hebben gezien. Alle transacties werden beïnvloed, evenals alle locaties. Overigens, als je hiernaar kijkt, kun je locaties over de hele wereld zien. Van Azië-Pacific tot Europa en Noord-Amerika. Het prestatieprobleem bevond zich niet in een bepaalde transactie of in een bepaalde geografische locatie, het is systeembreed. Het is een soort manier om te zeggen dat de verandering of de manier waarop de Fluid UI een wereldwijde impact had. Je kunt hier zien vanuit het oogpunt van schaalbaarheid, mensen proberen hetzelfde type hoeveelheid activiteit te doen, maar de responstijd is in feite gewoon verslechterd en verslechterd. Je kunt zien dat dingen niet schalen. Het gaat heel, heel slecht. Hier, wanneer ik naar het aantal assen en de gelijktijdige verbindingen kijk, zie je iets dat heel interessant is in termen van het aantal toegangen en de verbindingen. Hier zijn we slechts opgeschaald naar ongeveer 5.000 en je kijkt naar ongeveer, dit komt boven op 100 gelijktijdige verbindingen. Dit wordt gedaan na; dit is eerder. Dus wat mijn echte eis aan het systeem is, als dit ding zou kunnen schalen, ligt in het bereik van 300.000. Vroeger keek je met de klassieke gebruikersinterface naar 30 gelijktijdige verbindingen.
Wat dit u nu vertelt, is dat de Fluid UI minstens 10x aantal gelijktijdige verbindingen gebruikt. We beginnen terug te trekken wat er onder de covers gebeurt met PeopleSoft, zodat u de impact op de webservers kunt zien, het feit dat SLA's beginnen te breken. Niet op alles ingaan, maar wat uiteindelijk gebeurt, is dat ze in feite afhankelijk zijn van berichten. Ze oefenen in principe WebLogic uit en veroorzaken wachtrijen binnen Tuxedo. Er was eigenlijk een afhankelijkheidsprobleem met meerdere niveaus dat opdook met de Fluid UI, maar Precise kon aantonen dat we ons door een heleboel verschillende dingen kunnen concentreren op wat het probleem was. Het bleek dat er ook een probleem was in de database zelf. Er is eigenlijk een logbestand voor berichten en vanwege alle gelijktijdige gebruikers was dat logbestand vergrendeld. Het had eigenlijk dingen om af te stemmen, in elke afzonderlijke laag binnen de applicatiestack. Over complexiteit gesproken, hier is eigenlijk de Tuxedo-laag die je de wachtrij laat zien en je kunt de prestaties ook binnen deze laag zien afnemen. Ik kon de processen zien; Ik kon de domeinen en de servers zien. Voor mensen om dat te gebruiken, opent u meestal extra wachtrijen, domeinen en servers, net als in de supermarkt om de congestie te verlichten, om de wachttijd te minimaliseren. Laatste en laatste optie, Precise toont veel informatie.
Zoals ik eerder had vermeld, heeft elke significante transactie een wisselwerking met het registratiesysteem. Zichtbaarheid in de database staat voorop. Precise laat zien wat er gebeurt in de database, in WebLogic, in Java, .NET, in de browser, maar de plaats waar Precise echt uitblinkt is in de database-laag. Dit is toevallig de zwakte van onze concurrenten. Laat me je een van de manieren tonen waarop Precise je kan helpen dit te doorstaan. Ik ga geen tijd besteden aan de driehoek van database-optimalisatie, maar we kijken in principe naar goedkope, weinig risicovolle, grootschalige, risicovolle type wijzigingen. Ik zal deze dia eigenlijk achteraf tweeten als mensen willen proberen er naar te kijken. Het is een vrij grote gids, denk ik, voor afstemmingsproblemen. Hier is de weergave van de Precise for Oracle-expert. Bovenop het bevindingenrapport, is 60 procent impact deze specifieke SQL-verklaring. Als u dit activiteitenscherm opent, wordt het daar weergegeven. Ik kan deze selecte verklaring bekijken, er is één uitvoeringsplan. Elke uitvoering duurt een seconde - 48.000 uitvoeringen. Dat levert 48.000 extra uren executies op.
Het donkerblauw is opnieuw CPU. Dit ding is CPU-gebonden, geen wachttoestand, geen logboek. Ik benadruk dat omdat sommige van onze concurrenten alleen kijken naar wachttoestanden en logboekgebeurtenissen, maar over het algemeen gesproken, CPU de drukste uitvoeringsstatus is en de meeste terugkoop biedt. Toen ik in deze expertview ging - en ik ga heel snel - heb ik naar de tafel gekeken, 100.000 rijen, 37.000 blokken. We doen een volledige tabel, maar we hebben zes indexen voor dit ding. Wat is hier aan de hand? Welnu, als ik naar de Where-clausule kijk, is wat deze Where-clausule doet eigenlijk een kolom naar hoofdletters converteren en zeggen waar het gelijk is aan hoofdletters, variabele zoeken. Wat er gebeurt is, elke keer dat dit ding wordt uitgevoerd, moet Oracle deze kolom in hoofdletters omzetten. In plaats van dat bijna vijftigduizend keer te doen, is het veel efficiënter om die index in hoofdletters van een op functies gebaseerde index te bouwen en deze is niet alleen beschikbaar in de divisie van Oracle enterprise, ook in de standaarddivisie. Wanneer u dat doet, kunt u dan het uitvoeringsplan verifiëren dat de nieuwe indexgebruiker hoofdletters geeft, dat was gewoon een beetje mijn ding.
Vervolgens, vanuit een voor-en-na-meting, kijkt u naar de uitvoeringstijd van één seconde, tot maximaal 9 uur en 54 minuten, met dezelfde exacte SQL-instructie, maar met die index in hoofdletters gebouwd voor 58.000 uitvoeringen, het antwoord de tijd zakt tot sub-milliseconden, geaggregeerd, het komt tot zeven seconden. Ik heb in principe tien uur CPU op mijn server opgeslagen. Dit is enorm. Omdat als ik niet toe ben aan een serververnieuwing, ik op die server kan leven. Ik laat dat servergebruik zelfs met 20 procent vallen en je kunt het voorgaande en het volgende zien. Dat is het soort zichtbaarheid dat Precise kan bieden. Er zijn ook enkele aanvullende dingen waar we naar kunnen kijken, waarom hebben jullie al deze indexen als ze niet worden gebruikt? Ze kunnen dat opvolgen. Er is architectuur en ik zal het afronden, want we bereiken de top van het uur. Ik ben een echte gelovige in deze oplossing en we willen dat je een echte gelovige bent. Bij IDERA geloven we dat een proef een klant maakt, dus als u geïnteresseerd bent, kunnen we evaluaties uitvoeren op uw site.
Daarmee geef ik het baken terug.
Eric Kavanagh: Ja, dit was een enorm detail dat je daar hebt laten zien. Het is echt heel fascinerend. Ik denk dat ik je in het verleden misschien heb verteld dat - en ik weet dat in sommige van de andere webcasts die we met IDERA hebben gedaan, ik dat heb gezegd - ik eigenlijk Precise heb gevolgd sinds voordat het werd overgenomen door IDERA, helemaal terug naar 2008, denk ik, of 2009. Ik was toen al gefascineerd. Ik ben benieuwd om te weten hoeveel werk het kost om bovenop nieuwe releases van applicaties te blijven. U noemde dat SAP HANA, wat volgens mij behoorlijk indrukwekkend was, dat u daadwerkelijk in de HANA-architectuur kunt graven en daar wat probleemoplossing kunt doen. Hoeveel mensen heb je? Hoeveel moeite kost het van uw kant en hoeveel daarvan kan enigszins dynamisch worden gedaan, wat betekent dat wanneer de tool wordt geïmplementeerd, u begint rond te kruipen en verschillende dingen ziet? Hoeveel daarvan kan dynamisch worden bepaald door de tool, zodat u mensen kunt helpen bij het oplossen van complexe omgevingen?
Bill Ellis: Je hebt daar veel vragen gesteld.
Eric Kavanagh: Ik weet het, sorry.
Bill Ellis: Ik heb veel detail gegeven, want voor deze toepassingen, kijkend naar de code, zit de duivel in het detail. Je moet dat detailniveau hebben om echt iets te hebben dat bruikbaar is. Zonder bruikbare statistieken weet u gewoon wat de symptomen zijn. Je lost eigenlijk geen problemen op. IDERA gaat over het oplossen van problemen. Op de hoogte blijven van de nieuwe releases en dergelijke is een grote uitdaging. De vraag wat daarvoor nodig is, is echt voor productbeheer. Ik heb niet veel inzicht in het team dat ons in feite op de hoogte houdt van dingen. In termen van HANA is dat eigenlijk een nieuwe toevoeging aan de IDERA-productlijn; het is erg spannend. Een van de dingen met HANA is - laat me even over de taak praten. In de taak zouden de SAP-winkels doen dat ze de database repliceren voor rapportagedoeleinden. Dan zou je mensen moeten laten verzoenen met wat feitelijk actueel is. Je zou deze verschillende databases hebben en ze zouden op verschillende niveaus niet gesynchroniseerd zijn. Er is gewoon veel tijd en moeite, plus de hardware, de software en mensen om dat allemaal te onderhouden.
Het idee van HANA om een zeer parallelle in-memory database te hebben, om in feite de noodzaak van dubbele databases te vermijden. We hebben één database, één bron van waarheid, het is altijd up-to-date, op die manier vermijdt u het nodige om al die verzoening te doen. Het belang van de prestaties van de HANA-database gaat omhoog - ik ga zeggen 10x of op zijn minst waardevoller dan de som van al die andere databases, hardware, bronnen die kunnen worden gekocht. In staat zijn om HANA te beheren, nu dat onderdeel momenteel in beta-testen is, is het iets dat binnenkort GA zal gaan. Dat is dus best opwindend voor IDERA en voor ons om het SAP-platform in feite te ondersteunen. Ik weet niet zeker welke andere delen van je vraag ik eigenlijk heb veranderd, maar -
Eric Kavanagh: Nee, daar zitten allemaal goede dingen in. Ik heb je allemaal ineens gegooid, sorry daarvoor. Ik ben gewoon gefascineerd, echt, ik bedoel, dit is niet een heel eenvoudige toepassing, toch? Je gaat diep in op deze tools en begrijpt hoe ze met elkaar omgaan en tot op je punt, je moet het verhaal een beetje in je hoofd samenvoegen. Je moet stukjes informatie combineren om te begrijpen wat er feitelijk gebeurt en wat jou de problemen veroorzaakt, zodat je daar naar binnen kunt gaan en die problemen kunt oplossen.
Een deelnemer vraagt, hoe moeilijk is het om Precise te implementeren? Een andere persoon vroeg, wie zijn de mensen - uiteraard DBA's - maar wie zijn enkele andere rollen in de organisatie die deze tool zouden gebruiken?
Bill Ellis: Nauwkeurig is een beetje ingewikkelder om te implementeren. Je moet wel enige kennis hebben van de applicatieomgeving, in termen van, weet je, deze applicatie draait op deze database, hij heeft of - de middle-tier webservers, enz. Nodig. Ik denk dat gezien de complexiteit van sommige van deze applicaties, het is eigenlijk relatief eenvoudig. Als ik de webserver tot uw database kan instrumenteren, kan ik dat end-to-end doen. Je merkt dat ik niets heb gezegd over het instrumenteren van een eindgebruiker-client en dat is omdat we alleen dynamisch opnemen, zodat je je code of iets anders niet hoeft te wijzigen. Een JavaScript gaat in het applicatiepaginaframe. Het maakt niet uit waar de gebruiker ter wereld is, wanneer ze de URL openen vanuit uw applicatie en ze die pagina naar beneden halen, wordt het instrument met Precise geleverd. Dat stelt ons in staat om de gebruikers-ID, hun IP-adres, ook de eerste byte-weergavetijd van elk van de scriptcomponenten van de paginaonderdelen in de browser van de eindgebruiker te kiezen.
Wat de transacties betreft, hoeft u de transacties niet in kaart te brengen omdat ze nauw gekoppeld zijn. Deze URL wordt een toegangspunt tot JVM en roept vervolgens dit bericht op, wat resulteert in een JVC die uit de database wordt gevangen. We kunnen die natuurlijke verbindingspunten in feite vangen en ze vervolgens aan u presenteren in dat transactiescherm dat ik u liet zien, waar we ook berekenden hoeveel tijd, of het percentage tijd dat werd besteed in elke afzonderlijke stap. Dat alles gebeurt automatisch. Over het algemeen geven we 90 minuten de tijd om dit te doen - om in feite de Precise-kern te installeren en vervolgens beginnen we de toepassing te implementeren. Afhankelijk van de kennis van de applicatie, kunnen er wat extra sessies nodig zijn om de hele applicatie instrumentaal te krijgen. Veel mensen gebruiken alleen de databasecomponent van Precise. Dat is prima. Je kunt dit in feite splitsen, opsplitsen in de componenten die je het gevoel hebt dat je site nodig heeft. We zijn er absoluut van overtuigd dat de context van het hebben van een instrumentarium voor de hele applicatie, zodat u kunt zien dat de rij-tot-rij afhankelijkheid de waarde van het bewaken van een afzonderlijke rij vergroot. Als iemand de instrumentstapel verder wil verkennen, ga dan naar onze website - ik denk dat dat de gemakkelijkste manier is om extra informatie aan te vragen, en we zullen het een beetje verder bespreken.
Eric Kavanagh: Laat me je een of twee snelle vragen stellen. Ik gok dat je in de loop van de tijd een repository verzamelt en opbouwt, zowel voor individuele klanten als als een algemene entiteit, van interacties tussen verschillende applicaties en verschillende databases. Met andere woorden, ik veronderstel dat ik scenario-modellering bedoel. Is dat zo? Heeft u eigenlijk een soort repository van veel voorkomende scenario's, zodat u suggesties voor eindgebruikers kunt doen wanneer bepaalde dingen een rol spelen? Net als deze versie van E-Business Suite, deze versie van deze database, enz. Doe je daar veel van?
Bill Ellis: Nou, dat soort informatie is ingebouwd in het bevindingenrapport. Het bevindingenrapport zegt wat de prestatieknelpunten zijn, en het is gebaseerd op de uitvoeringstijd. Onderdeel van dat bevindingenrapport is meer informatie en wat ga je nu doen. De informatie of de ervaring van klanten, enzovoort, is in principe in die bibliotheek van aanbevelingen verwerkt.
Eric Kavanagh: Oké, dat klinkt goed. Nou mensen, fantastische presentatie vandaag. Bill, ik vond het geweldig hoeveel details je daar had. Ik dacht gewoon dat dit echt fantastische, korrelige, korrelige informatie was die liet zien hoe al deze dingen worden gedaan. Op een gegeven moment lijkt het bijna op zwarte magie, maar dat is het echt niet. Het is een zeer specifieke technologie die jullie samenstellen om zeer, zeer complexe omgevingen te begrijpen en mensen gelukkig te maken omdat niemand het leuk vindt als applicaties langzaam draaien.
Nou mensen, we zullen deze webcast archiveren. U kunt online naar Techopedia of insideanalysis.com springen en wauw, bedankt voor uw tijd, we zullen u de volgende keer ontmoeten. Hou je haaks doei.
