Odnést: Hostitel Rebecca Jozwiak diskutuje o řešení problémů s databází a otázkách efektivity s analytiky Ericem Kavanaghem a Dezem Blanchfieldem a Billem Ellisem z IDERA.
Momentálně nejste přihlášeni. Chcete-li zobrazit video, přihlaste se nebo se zaregistrujte.
Rebecca Jozwiak: Dámy a pánové, ahoj, vítejte v Hot Technologies roku 2016. Dnešní téma: „Aplikace běží pomalu? Čas získat přesnost.“ A nevíme všichni příliš dobře problémy, které se mohou objevit, když věci běží pomalu? Tohle je Rebecca Jozwiak, vyplňuji Erica, který tady dnes dělá nějakou novou roli. Ano, tento rok je horký a jak víte, pokud jde o technologii, jak jsem řekl, jedna věc, kterou opravdu nechcete, je pomalý běh čehokoliv, jakákoli část vašeho systému. A jen proto, abych použil příklad pro spotřebitele, myslím, že pokud máte restauraci, nezáleží na tom, jak skvělé jídlo je, pokud je služba pomalá, pravděpodobně se vám to nakonec nevrátí. Nyní je v restauraci snadné zjistit, proč něco běží pomalu. Možná je v kuchyni krátká obsluha nebo došlo k poruše s nějakým vybavením, nebo možná obsluha čeká trochu líná a její druh snadno identifikovat a opravit.
Ale když přemýšlíte o datovém centru, je to úplně jiný příběh. Mohlo by to být problém se sítí, špatný dotaz, který zasekává věci, výkon aplikace nebo vadný kabel může dokonce způsobit některé problémy. A řešení problémů s tímto typem složitosti může být, jak víte, v nejlepším případě obtížné. To je to, o čem se dnes bude mluvit. A jak jsem řekl, Eric Kavanagh se dnes zazněl jako analytik. Weve dostal našeho datového vědce Dez Blanchfielda a máme Billa Ellise z IDERA, který bude mluvit o svém řešení společnosti, které pomáhá s řízením výkonu aplikací. A s tím Im půjdu míčku Ericovi. Ericu, podlaha je tvoje.
Eric Kavanagh: Dobře, zní dobře, lidi. A ve skutečnosti to byla skvělá analogie, protože jste hovořili o problémech nebo snadnosti, s nimiž lze řešení problémů vyřešit, a dostanete se k tomu přímo. Problémy s výkonem vždy vyplývají z nějakého problému, který je v síti. Myslím, že by to mohlo být stejně jednoduché jako starý hardware, ale spodním řádku je situace, kdy taková situace vyžaduje řešení problémů. To je to, o čem dnes budu mluvit. A dovolte jít dopředu a skočit na snímky zde.
Tady přicházejí potíže. Odstraňování problémů - je to zábava pro lidi, kteří se to líbí, to je skvělá věc. Pokud najdete někoho, kdo rád řeší odstraňování problémů, držte se této osoby, získejte některé nástroje, jak tuto práci odvést, protože opravdu dobré věci, pokud najdete někoho, kdo se může dostat na dno něčeho a dostane věci. Sečteno a podtrženo je, že řešení problémů je problematické a vždy to bylo a vždy bude, a pokud začnete hovořit o řešení problémů, pak se skutečně zabýváte analýzou hlavních příčin. Co je příčinou problému?
No, pokud si jen tak sedíte a přemýšlíte o chvílích sálových počítačů, objevily se všechny problémy. A tehdy jste museli mít lidi, kteří opravdu věděli o jejich věcech, protože na řešení problémů neměli ani dobré nástroje, takže jste opravdu museli znát příkazový řádek a za chvilku o tom dobře mluvit. A vlastně jsem zapomněl vložit jeden z mých oblíbených snímků. Hledám ho, když jsem byl dnes v show, možná během prezentace Dezse. Chtěl jsem však ukázat každému, kdo to neviděl, jednu z nejzábavnějších britských televizních pořadů, která se jmenuje „The IT Crowd“. A pokud jde o odstraňování problémů, Ir, který je jedním ze dvou IT lidí v celku Společnost říká vždy to samé, kdykoli začne jakýkoli hovor: „Zkusili jste jej vypnout a znovu zapnout?“ Takže to zkuste vypnout a znovu zapnout. Byli byste překvapeni, jak často může tato jednoduchá věc vyřešit některé problémy.
Ti z vás, kteří provedli řešení problémů doma, možná se svými rodiči nebo přáteli, pravděpodobně ne se svými dětmi, protože mají tendenci vědět, co dělat, vypněte a znovu zapněte. Ale bez ohledu na to, řešení problémů není snadné, nikdy to nebude snadné, ale dnes se budeme bavit o některých věcech, které můžete udělat, aby bylo snazší. Takže příkazový řádek - ano, opravdu, jsem dost starý na to, abych si vzpomněl na počáteční dny práce na počítači, když jste měli pouze příkazový řádek k provedení DIR, Enter. To je to, co by to vidělo, adresář souborů a cítil se pozitivně, že to vlastně udělal nějaký příkaz, že? Dez, samozřejmě, náš datový vědec, ví, jak používat příkazový řádek. A pokud můžete použít příkazový řádek, je to skvělé, protože většina z nás obyčejných smrtelníků používá nějaký druh grafického uživatelského rozhraní, grafické uživatelské rozhraní, ale vždy je něco, vždy existuje nějaké odpojení mezi grafickým uživatelským rozhraním a příkazovým řádkem pod ním. A jen proto, abychom vám ukázali náhodný příklad, pokud chcete vědět, kolik kódu se některé ze základních programů v těchto dnech pečou do dokumentů, přejděte do nejnovější verze aplikace Microsoft Word, zadejte „hello world“ a poté „uložte jako HTML. “A pak výsledný dokument otevřete v editoru a pravděpodobně uvidíte stránky a stránky značek. To se nazývá blokace kódu a blokace kódu není opravdu dobrá pro řešení problémů, jen abych byl upřímný.
Samozřejmě přišel klient-server a to bylo skvělé. A určitým způsobem se to v tomto směru vracelo zpět, ale jen přemýšlejte o složitosti, která přišla se situací, nyní, kde je problém, je to na klientovi, je to na serveru, je to síť? Kde to je? Co se může stát, když tyto weby přemýšlejí o virech a kdy se virus může dostat do jednoho v síti? Může jít kamkoli. Porušení dat je v těchto dnech šílené. Způsobují problémy s výkonem. Weve měl ruské hackery, které můžeme identifikovat podle IP adresy. Byli si docela jistí, že jsou Rusové, nebo jsou velmi blízko, nebo jsou velmi chytrí Ukrajinci nebo Poláci nebo dokonce Američané pomocí proxy. Ale měli jsme hackeři přišli na naše malé staré stránky, Inside Analysis, v průběhu let a způsobit všechny druhy problémů. Věci přestanou fungovat, nemůžete to udělat. Věci, které fungovaly, nefungují. Jak to víš? Jak víš, co to je? Stejně jako další příklad zde je velmi složité prostředí, jeho velmi obtížné se dostat do plevelů a skutečně porozumět tomu, jak se věci odehrávají a jak pro nás fungují, zejména pokud získáte spoustu doplňků. Věci mohou docela rychle zbláznit. Jsem trochu před námi.
Hodil jsem sem, vždy mějte na paměti upgrade. Upgrades ode mě vždy vyděsí denní světlo. Určitě operační systémy. Vzpomínám si na dny, kdy Microsoft skutečně navrhl, že ano, mohli byste upgradovat svůj operační systém z této verze na tuto verzi. Několikrát jsem to zkusil, a to nikdy nefungovalo. Nezapomeňte, že čím větší je prostředí složitější, tím těžší je situace. A pak virtualizace. Přemýšlejte o tom, co VMware udělal IT. Revolucionalizovalo to IT, ale také vytvořilo tuto vrstvu abstrakcí. Pokud máte na této základní úrovni abstrakci vrstvy, to je zcela nová míčková hra, to je úplně nová koule vosku a opravdu musíte přehodnotit, co děláte, a všechny staré nástroje se musely změnit. A teď je to samozřejmě cloud, že? Pro zákazníka je cloud skvělý, protože jeho velmi jednoduché uživatelské rozhraní je velmi jednoduché, ale samozřejmě nemáte nad cloudem moc kontroly. Ale pro lidi, kteří jsou v zákulisí, je tu spousta věcí, které potřebují znát a pochopit v těchto dnech. Prostředí se stalo mnohem, mnohem složitějším. A určitě s elektronickým obchodem, a vy si myslíte o všech penězích, které se dnes obchodují s rukama. Proto mě v dohledné době nenajdete ve prospěch bezhotovostní společnosti. Pointa je, že situace se každým dnem stává problematičtější.
A udržování optimálního výkonu vždy zahrnuje nějaký prvek řešení problémů. Nezajímá mě, co vám někdo říká, neexistuje dokonalý nástroj, není to stříbrná kulička a nikdy nebude, protože - v jiné zajímavé perspektivě zde - se stále učili mluvit křemík. Stále jsme se učili porozumět tomu, jak funguje i síťování na úrovni dusnatých štěrků. Pokud se podíváte na software pro správu systémů, je v dnešní době docela dobrý. Ale stále se díváte na linie, které se pohybují nahoru a dolů, a díváte se na reprezentace reality, vezme to člověka, který ví, co se děje, aby se vešly stopy, které byste mohli hledět na optimální nástroje, aby mohli pochopit, co funguje a co není a je to hodně pokusů a omylů, jen abych byl upřímný. S tím jsem to předal Dez Blanchfieldovi a pak dobře slyším od Billa Ellise z IDERA, kdo nás chce zahanbit svými znalostmi. S tím, Dezi, vezmi to pryč.
Dez Blanchfield: Hej, díky Ericu. Děkuju. Pěkně vedl do mé malé secese. Můj titul „Performance Art“ je podle mě nesmírně výstižný v tom, o čem se dnes bavilo, protože v mnoha ohledech, když přemýšlíme o performance, přemýšlíme o tanci a hudbě a dalších kreativních věcech. A upřímněji častěji než ne, pokud by se řešily problémy a ve velmi rozsáhlých IT prostředích a obchodních systémech skutečně existuje prvek umění a často černé umění, protože situace, která je podle mých zkušeností asi za 25 let a více, je, že moderní aplikace komíny, velmi rychle rostou složitost rychlostí, jakou jsme nikdy předtím neviděli. A upřímně se snažili udržet krok a existují organizace, jako je například Uber a podobně, a vývojový tým Pokémon Go, myslím, že zažívají růst a složitost a zvyšování složitosti rychlostí, která je jen astronomická. Neexistují dokonce ani knihy o tom psané, protože jsme tuto úroveň růstu nepochopili. Můj názor je, že základní definice zásobníku aplikací se exponenciálně proměnila a já vysvětlím, proč si myslím, že tomu tak je, a pak vedou k výzvě, po které se moji dobrí přátelé v IDERA zdají mít řešení, které je třeba vyřešit.
Velmi stručně to všichni víme, ale jen je rekapitulujeme, víte, v prvních dnech jsme měli to, čemu říkám, aplikační architektura, verze 1.0. Byl to serverový počítač, v tomto případě sálový počítač s připojeným svazkem terminálů, bylo poměrně snadné diagnostikovat problémy, pokud jste na terminálu neviděli věci - mohli byste vystopovat kabel mezi terminálem a poté serverovým počítačem a buď to byl nulový kabel nebo konektor nebo nějaký problém, pokud to nesouviselo s terminálem, a když vidíte věci na obrazovce, bylo docela snadné zjistit, že věci, které způsobovaly problémy, byly v samotném stroji. A můžete pomalu diagnostikovat, kde v zásobníku byl hardware od hardwaru až po softwarovou vrstvu a uživatelské rozhraní. V tom, čemu říkám verze 1.1, jsme to trochu složitější. Umístili jsme zařízení do středu, abychom mohli nasadit více terminálů. Byly to jakousi komunikační zařízení a často to byly muxy nebo multiplexery a buď by běžely přes vyhrazenou linku nebo vytáčenou linku, a tak jste měli sálový počítač na vzdáleném místě - mohlo to být mezistátní nebo mezinárodní - a nějaké zařízení připojené přes SMA linku nebo nějaký druh WAN konektivity a tyto terminály stále fungují stejným způsobem. Měli jste však trochu složitější situaci, protože jste museli zjistit, zda se jedná o problém mezi terminály a zařízením Comms nebo zařízením Comms a mainframe. Zásobník však zůstal relativně podobný v mainframe.
Verze 1.2, o něco složitější znovu, protože nyní jsme přidali další zařízení, přidali jsme ers a další věci, a tyto věci jsme seskupili, a myslím na front-end procesor, který by zvládl všechny problémy zařízení lokálně, ers a terminály atd. s mainframem, který je vzdálenější. Trochu složitější. Ale opět, konzistentním tématem sálového počítače byly aplikace běžící lokálně, takže řešení problémů zůstalo v zásobníku aplikací docela podobné. A pak jsme nechali běžet lidi s dovednostmi, jak řešit problémy s terminály a ers a řadiči clusterů. Ale pak jsme komplikovali věci a stavěli jsme sítě a najednou stejný druh architektury zavádí síťovou vrstvu. Najednou jsme měli síťový přepínač a pracovní stanice byly mnohem složitější. A tuto verzi architektury jsme často měli graficky uživatelského rozhraní aplikace na pracovní stanici. Nejenže jsme server provozovali zásobník aplikací, ale měli jsme také další stoh aplikací spuštěných lokálně a samozřejmě stejný základní model zařízení připojujících se k serveru. Pak jsme se kvantově posunuli k novějšímu modelu toho, čemu říkám 2.1, což je místo, kde jsme vzali tento zásobník aplikací a udělali jsme to mnohem složitější, mnohem těžší diagnostikovat. A my jsme představili mnohem více zařízení na front-endu, ve webových prohlížečích a počítačích a mobilních zařízeních atd. A tady se aplikační balíček začal ponořit trochu hlouběji do integrace jako operační systém a hypervisor.
Tento obrázek zde na pravé straně dostal celý zásobník včetně síťové infrastruktury, úložných serverů, virtuálních strojů, operačního systému a poté tradičních tří vrstev databázových kovových aplikací atd., V pravé přední části. Diagnostika problémů s aplikací a problémů s výkonem na tomto modelu se stala mnohem těžší. Existuje tolik dalších pohyblivých částí a pokusit se vrtat skrz ten stack byl jen, víš, stal se noční můrou a vy jste se museli zabývat dalšími sadami dovedností a organizací, které se s tím vypořádaly. Už to nebyl jen váš aplikační tým, najednou jste měli lidi v oblasti infrastruktury, měli jste databázové specialisty, čistě jen pracovali na databázích a nic jiného - na rozdíl od systémového programátora, který věděl, jak se pohybují kolem databází. Nyní máme scénář, ve kterém se oddělení IT musí vypořádat s výrazně širší složitostí „jako služby“, a to, že svět právě explodoval a naše výzvy k řešení problémů se staly, přešlo z noční můry na něco, co je téměř nesnesitelné v některých ohledech.
A to se stalo jako řešitelné měřítko, které se snažilo poskytovat služby na. Verze 3 toho, co považuji za aplikační zásobník - zavedlo to jako model služeb, kde tradiční model na levé straně, podnikový IT zásobník, kde všechno muselo být na našem konci spravováno jako spotřebitel a dodavatel služby - z databáze zabezpečení aplikací, operačních systémů, virtualizačních úložišť služeb, síťových datových center - museli jsme to všechno spravovat, ale měli jsme ke všem přístup, a tak jsme mohli škálovat své schopnosti a technické dovednosti a mohli jsme se vrtat přímo dolů skrz ten stack a mohli jsme najít věci. Ale jak se objevila infrastrukturní služba a platformová služba a model softwarové služby, najednou byl náš přístup k infrastruktuře back-end, náš přístup k platformám a nástroj, ze kterého jsme poskytovali služby, od nás trochu odebrán. Když jsme začali spotřebovávat infrastrukturní službu, měli jsme k dispozici pouze ty čtyři hlavní části z operačního systému, databáze, zásobníku aplikací zabezpečení prostředí a výše. Všechno pod tím byla černá magie. A to se stává ještě zajímavějším, když se přestěhujete do služby platformy, protože také právě spravujete zásobník aplikací.
Když se dostanete k softwaru jako službě a jeho tradičním modelem je webmail nebo internetové bankovnictví, máte pouze přístup do webového prohlížeče, takže pokusit se diagnostikovat, co je za tím, je rozhodně netolerovatelné. A já jsem to rozdělil na časová pásma, časové úseky nebo časové úseky, pokud se vám líbí nebo generace, v tom zleva doprava, odešli z jakéhokoli před 2000 let a tradičního zásobníku, kde jsme měli přístup do celého prostředí a mohli bychom to projít. Ale postupem času se to stalo stále složitějším. Na počátku roku 2000 až do poloviny roku 2000, do konce roku 2000 až do současnosti, kdy se od služeb infrastruktury, služeb platforem, softwarových služeb odvíjelo v zásadě obchodní služba. A složitost se dramaticky zvýšila. Existuje tolik dalších pohyblivých částí. Dostupnost dovedností je však těžší a těžší a stále těžší je využít. Nalezení lidí se správnou sadou dovedností se správným přístupem ke správným nástrojům, jak se dostat do tohoto balíčku a zjistit, kde se něco děje pomalu. Je to můj notebook nebo můj počítač, je to můj telefon nebo tablet, je to moje připojení přes 3 nebo 4G, nebo můj vyhrazený odkaz s ADSL nebo ISDN, co to může být? Nebo dokonce dial-up, i když to je v těchto dnech stále méně. Je konec webového serveru, je to něco uvnitř webového serveru? Je to aplikační server? Je to něco kolem paměti a disku výkonu CPU a sítě uvnitř aplikačního serveru? Je tam databáze spuštěna?
A dokážete si představit, nakreslíte tento obrázek velmi rychle o složitosti, která se začíná rozšiřovat, jako je obrázek velkého třesku, této stále rostoucí bubliny, která se snažila obejít naše zbraně a mít dovednosti, do kterých by se mohla ponořit, a znalosti a kde rozebrat a rozebrat. A teď už to bylo hodně v době, kdy, jak víte, si lidé nedokážou poradit s fyzickým měřítkem, i když máte schopnost odtáhnout prostředí databáze od sebe a odtáhnout tuto databázi od sebe a ponořit se do detailů v této databázi.Počet databází, které musíte nyní spravovat, rychle roste. Vše je nyní poháněno databází. Velmi málo aplikací v těchto dnech není poháněno databází. A typy databází také rychle rostou. Nejedná se pouze o tradiční databáze SQL, někdy o její SQL, někdy o jiné než SQL, někdy o databázi grafů, někdy o databázi dokumentů. A existují všechny tyto různé typy funkcí, které tyto různé typy databází mají, a v důsledku toho každá z nich má různé výzvy k výkonu a různá výkonnostní kritéria. Protokolování databází a databází dokumentů se provádí velmi, velmi odlišně a provádí jinou funkci než tradiční databáze SQL kompatibilní s ACID a ANSI 92. A druhy věcí, které jsme tam uložili.
V mé mysli jsem byl v bodě, kde - a myslím si, že to Eric zmiňoval - že se lidské bytosti snaží udržet krok se složitostí toho, co stavěly, a rychlostí, se kterou se stavěly, a nyní byly v místě, kde Jediný způsob, jak spravovat tuto infrastrukturu, a jediný způsob, jak sledovat a ponořit se do problémů, se kterými se potýkají, jsou nástroje a správné typy nástrojů. A pak vždy správná generace nástrojů. Nástroje, které skutečně rozumí back-end infrastruktuře. Už není v pořádku házet monitor SQL nebo dotazový nástroj SQL na něco a začít dotaz rozebírat a zjistit, co to funguje. Vlastně potřebujeme nástroj, který chápe vytváření dotazů a vhodný způsob, jak vytvářet dotazy, a vhodné způsoby, jak mohou dotazy hovořit s infrastrukturou na pozadí, a jak se jim daří, jak to dělají. A podívat se na načasování těchto interakcí a na pořadí, ve kterém se odehrávají.
A to je mnohem složitější výzva, a to mě vede k mému bodu otázek se zaměřením, a to je, že jak se vyvíjí složitost aplikačních balíčků, je třeba, aby se výkonové nástroje a nástroje, které používáme k jejich správě, staly stále chytřejší a mnohem schopnější dívat se na více věcí. Ale také mnohem chytřejší v tom, jak se ponořit do toho, co běží na pozadí a co o tom mohou zjistit, a potenciálně dokonce provést nějaký druh analytiky prováděné nad tím, aby pochopili, že interakce a výkon, jsou dodávány, a proč jeho výkon pomalejší nebo rychlejší.
A pak s tím Im půjdu na našeho drahého přítele z IDERA, Billa Ellise, a uvidíme, co dnes musí říci o tom, jak tento problém vyřeší. Bille, k tobě.
Bill Ellis: V pořádku. Jmenuji se Bill Ellis a moc vám děkuji. Měli jsme mluvit o mé aplikaci běží pomalu, je čas získat přesné. Uvidíme, co dokáže Precise, produkt IDERA, a jak vám může pomoci. Mnohokrát zjistíte pouze to, že to byl problém s výkonem, protože vás koncový uživatel zavolal, a to je samo o sobě velký problém. Z každého v IT nikdo nevěděl, dokud nezazvonil telefon. Nyní je dalším velkým problémem to, jak tomuto konkrétnímu člověku pomáháme a ve skutečnosti to není triviální problém. Z toho je jeden s sebou. To je nad a za touto skluzavkou, nad a za ostatními. A chci, abyste viděli, jestli to dokážete. Jak jsme však již zmínili, aplikace vyžaduje, spoléhá se na spoustu různých technologií, zásobník aplikací je vysoký a roste. A mnoho lidí přistupuje k aplikaci prostřednictvím prohlížeče a překvapivě je zde stále více zpracování, které se děje v prohlížeči se skriptováním atd., A pak samozřejmě máte síť, webový server, kód obchodní logiky a databázi. Chci, abyste zvážili, že každá významná obchodní transakce interaguje s databází, ať už jde o podávání zpráv o časové kartě, vyhledávání zásob, nákupní objednávku, databáze se aktualizuje. Databáze se tak stává skutečným základem výkonu. Databáze se samozřejmě může zapnout nebo se spoléhat na navazující úložiště. Každá z těchto technologií je pevně propojena a dokáže vidět, co se děje. Musíte vědět, co se děje, aby bylo možné měřit, je kritické.
Nyní zjistíme, že mnoho našich zákazníků má nástroj a že mají nástroj pro každou technologii, ale to, co nemají, je kon. A con je v podstatě schopnost propojit tečky mezi každou vrstvu v aplikačním zásobníku, a to je ve skutečnosti relativně jednoduché. Dříve jsme měli omezení dvanácti úrovní, ale v zásadě jsme to změnili, máme neomezený počet úrovní a podporujeme smíšená prostředí, takže se v zásadě můžeme s precizním řešením v zásadě komplikovat.
Nyní na vysoké úrovni takto řešíme problém a jeho zaměření na transakci, transakce koncového uživatele od kliknutí na disk, řekne nám, které běží pomalu, které spotřebovávají zdroje, ale klíčem je toto - dovolujeme vám vyzvednout a identifikovat uživatele jejich umístění a nejen celou dobu transakce, ale kolik času strávíte v každém jednotlivém kroku. Čas je měna výkonu a také ukazuje, kde se spotřebovávají zdroje. Nevíme dopředu, kde bude problém, takže musíme mít odpovídající metriky a analytiku na každé z úrovní, abychom mohli diagnostikovat, jaký problém, kde by problém mohl být.
Nyní, v dnešní prezentaci, se zaměřím na tuto oblast, chci, abyste si byli jisti, že v zásadě poskytujeme stejnou úroveň viditelnosti na všech úrovních v aplikačním zásobníku a klíčovou věcí je, že nám to řekne, kdo, co, kde a potom tato část, to nám řekne proč. A to je opravdu důvod, proč je to absolutně zásadní pro řešení problémů, nejen o nich vědět. Nyní další věc, která vyšla velmi jasně v prezentaci, byla skutečnost, že je to nemožné. Potřebujete automatizaci. A automatizace znamená, že vás upozorní, máte něco, co vám, doufejme, před komunitou koncových uživatelů, řekne, že máte pokračující trend, vytvořili odchylku od upozornění na trendy. A pak také nabízíme čáru v písku, skutečně porušujete SLA. Nyní nabízíte spoustu různých informací - ne každý musí konzumovat bufet, někteří lidé chtějí jen lehké občerstvení, je to salát, a proto s tím, že nabízíme portál, můžeme nahrávat informace, potřebuje pouze konkrétního uživatele nebo konkrétní komunitní informační potřeby o výkonu. Aplikace běží pomalu, je čas získat přesnost. Opravdu jsme se zaměřili na čtyři věci. Jedním z nich je umístění, zadávání koncového uživatele. Opět platí, že tato kon, která spojuje tečky, a třetí část výzkumu ukazuje, že téměř 90 procent aplikací problémy jsou v databázi, a tak je to opravdu druh travesty, že většina řešení výkonu může říct jeden příkaz SQL. Ale oni vám neřeknou, proč tento příkaz SQL běží pomalu.
A proto je vždy klíčová věc a Precise je vynikající v tom, proč, pro každou vrstvu a zejména databázi, a jen se s vámi trochu podělit o naší podpůrné matici, kterou podporujeme SQL Server, Sybase, DB2 a / nebo Hromadně. Vzhled a dojem z řešení je velmi podobný, takže pokud se díváte na více aplikací, ale mírně odlišné architektury. Informace, které zde sdílím, mají vzhled a pocit, přístup, to samé bez ohledu na to, jaké základní technologie se používají. Přesný web je povolen. Vstoupíme, autentizujeme Preciznost, a tím vcházíme dovnitř a první věc, na kterou bychom se mohli podívat, je výkon podle místa. A tak zde můžete skutečně vidět různá místa, kde lidé skutečně přistupují ke svým popravám. Můžete vidět, zda někdo opustil stránku před jejím úplným vykreslením, nebo zda došlo k chybám.
Nyní je jedna věc s těmito aplikacemi, že síť nebo vzdálenost od aplikačního serveru se liší. Je velmi snadné vidět, že existuje určitá úroveň sítě. Vidím, kdy se lidé začali zabývat, a pak další zajímavou věcí, mluvili jsme o tom, jak je zpracování v prohlížeči, skutečně si všimnou, že některé z různých typů prohlížečů poskytují lepší prostředí pro rychlé zpracování. A proto věděme, zda lidé přistupují k prohlížeči Chrome nebo IE nebo k tomu, co se stane, můžete skutečně zjistit, že inverze jednoho typu prohlížeče je ve skutečnosti lepší než jiná. Teď, někdy máte veřejnou orientaci, nemáte kontrolu nad prohlížečem, někdy jsou aplikace interní, kde můžete doporučit lidem typ prohlížeče vaší komunitě koncových uživatelů, a proto se jedná o typy hloubkové viditelnosti a analytiky, které jsou přesné schopen poskytnout. Nyní se podíváme na aplikaci.
Nejsem si jistý, jestli můžete vidět můj ukazatel, ale chtěl jsem vám popsat horní graf. Osa y ukazuje průměrnou dobu odezvy. Osa x je čas v průběhu dne. A je-li ve skutečnosti skládaný sloupcový graf a tento skládaný sloupcový graf, součet vám ukáže, co je výkon, a pak ukazuje odstupňování toho, kolik času je stráveno v každém jednotlivém kroku nebo v každé jednotlivé vrstvě aplikace. Z klienta přes webový server je zelená Java, toto místo používalo Tuxedo a dolů do databáze. Ve spodní polovině obrazovky jsou nyní zobrazeny různé webové nabídky, které jsou přístupné, a poté jsme si vybrali malou zelenou šipku směřující dolů. Je v sestupném pořadí, a to nahoru až nahoru, webové menu začne ukazovat. Ve skutečnosti zobrazujeme dobu provádění, dobu odezvy každé jednotlivé technologie a potom je ve skutečnosti sloupcový graf pro každou z těchto webových nabídek, a tak dostaneme, začneme si dělat představu o tom, co se děje. Teď si pamatujte, že jsme to všechno seřazili s koncovým uživatelem, který by zavolal, ale jak najdu koncového uživatele? Přicházím sem, otevírám nabídku, která mi umožňuje filtrovat konkrétního uživatele, takže jsem nastavil tohoto uživatele na Alex Net, klikněte na OK, a pak jsem se zaměřil pouze na aktivitu Alex Net. Nyní to umožňuje, aby IT a správa IT mohla přímo reagovat na koncového uživatele, a zejména, že se dívali na správu obsahu, která měla šest poprav s dobou odezvy trochu delší než tři sekundy. No tři sekundy jsou docela dobré, není to hrozné, ale je to možná pomalejší.
Co s tím mohu udělat, je to, že mohu tyto informace rozřezat a nakrájet různými způsoby. Mohl bych říct, dobře, je tato transakce pomalá pro všechny? Je dnes pro Alexe pomalejší, než tomu bylo včera? Je to pomalé pro každého uživatele na konkrétním místě? Nebo, a co to dělá, je to, že mi umožňuje rozřezat a nakrájet kostky a získat představu o tom, co se děje, jak univerzální je problém a je velmi důležité, abych mohl identifikovat koncového uživatele, protože se nejedná pouze o software, infrastruktura, její také o tom, jak koncoví uživatelé aplikaci používají. Často můžete mít nového zaměstnance nebo někoho s novou funkcí úlohy a oni nejsou obeznámeni s některými obrazovkami SAP nebo s některými panely PeopleSoft a potřebují trochu ukazatele, možná nechávají pole prázdná nebo vkládají zástupné znaky a nutí velké výsledky, aby byly vrácené z databáze. Ale s uživatelským ID je můžete skutečně zavolat dříve, než vám zavolají. Druhou věcí, kterou zjistíme, je, že jakmile si uživatelská komunita uvědomí, že IT ví, co dělají, mnohokrát se lépe chová a spousta problémů, spousta věcí, které byly problémy, prostě se vypařují, protože se lidé chovají, operujte trochu opatrněji. Používají systém s větší péčí.
Identifikace koncového uživatele je nezbytná. Nakonec je nezbytné, aby IT mohlo pomoci konkrétnímu koncovému uživateli. Teď, co se tady stalo, je třeba jít na záložku „Flow“. Můžete to vidět v levém horním rohu. A zaměřili jsme se na jednu konkrétní součást nabídky na webu. A na pravé straně je analýza této konkrétní transakce, a tak nahoře je to vlastně prohlížeč a poté pohled, abych se seznámil s trochou ikon v GUI je pro webový server, takže můžeme vidět bod atributu. A pak „J“ je pro Javu a „T“ pro Tuxedo a „Q“ je samozřejmě SQL. Tato peněžní hodnota v podstatě identifikuje konkrétní příkaz SQL. Zvažte, co to dělá. Weve identifikoval uživatele k transakci, k podkladovému kódu aplikace, včetně jednotlivých příkazů SQL. Nyní, když se podívám na tyto jednotlivé příkazy SQL, vidím, že z celkové doby odezvy je každý z nich zodpovědný za přibližně šest procent, a když sečtou první čtyři příkazy SQL, vzali asi čtvrtinu transakce čas.
Nyní je databáze často nejsnadnější manipulovat. Obvykle je nejsnadnější získat levný, mnohem lepší výkon. Teď musím jít trochu hlouběji, abych zjistil, co se děje a co, chci, aby příklad byl schopen udělat, je vlastně odhalit jednotlivé příkazy SQL, a víte, že vám mohu téměř zaručit pouhým jediným výstřelem na řádku měl nějaký druh databázového nástroje a co databázový nástroj dělá, ale jen při pohledu na jednu technologii izolovaně, je to, že se podíváte na, soustředíte se na zdraví této technologie. A mnohokrát se lidé dívají na první desítku seznamu. Nyní je tento příkaz SQL velmi rychlý a nebude na seznamu první desítky, ale je to příkaz SQL, na který se tato transakce spoléhá. Takže to, co v tom slově, con, mohu udělat, je, že to nyní mohu upozornit na hluboký pohled, ale v kontextu jednotlivých příkazů SQL.
Nyní, že osoba může otevřít Precise v souvislosti s jednotlivými příkazy SQL, a Precise zachycuje skutečný plán provádění, který používá, doba provádění je to důležité věci pro DBA, se skutečně ukáže, můžete vidět, že 50 procent čas strávený čekáním na úložiště. Padesát procent času se používá v procesoru, takže začnete získávat představy o tom, kde se čas tráví, jak bych se mohl časem kroužit a myšlenkou je dát lidem možnosti, protože různé reakce mají různé náklady a riziko spojené . V ideálním případě to bylo po nízkorizikovém a levném řešení problému. Nyní, když je příkaz SQL sledován pomocí hodnoty hash, a v levém středu obrazovky je toto malé tlačítko „Vyladit“ a to, co se chystá udělat, je jeho přesunutí k úkolu SQL. A tento úkol SQL je druh předem vytvořeného pracovního stolu a co to dělá, je to, že mi umožňuje skutečně analyzovat konkrétně to, co má dopad na příkaz SQL, počínaje plánem provádění. Plán provádění je vybrán optimalizátorem, když je příkaz analyzován, a to - zpět k analogii jídla, jeho recept, který následuje k vyřešení příkazu SQL.
A některé recepty jsou složitější než jiné, a proto poskytujeme zjištění. A tady to ve skutečnosti ukáže, hej, hodně času to dělá sekvenční I / O na konkrétním indexu. A teď, když se vracíme zpět k kyslíku, sleduj tento index. Byl tento index v poslední době defragmentován, co je to zdraví? V jakém stolním prostoru žije? Je tabulkový prostor oddělen od tabulky, na kterou odkazuje? A tak vám začíná dávat nejrůznější nápady, jak byste mohli vyřešit problém. Nyní samozřejmě víte, že stavěli v indexu. Je to mnohem nižší riziko, mnohem jednodušší než možná přesunutí indexu z jednoho tabulkového prostoru do jiného tabulkového prostoru, takže to, co chtěli udělat, je druh možností sestavení, takže můžeme nasadit řešení s nejnižšími náklady a nejnižšími riziky k vyřešení problém.
Přesné mohou také dělat věci, jako jsou proměnné zachycení vazby, které jsou odevzdány do příkazu SQL. Je zřejmé, že proměnné, které jsou obsazeny, budou řídit velikost sady výsledků. A bude kontrolovat, jak dlouho trvá provedení příkazu SQL a kolik dat musí aplikace předat a zpracovat aplikace prostřednictvím Java, přes .NET, do webového serveru a sítě, konečně vykreslené v prohlížeči koncového uživatele. . To, co se v databázi děje, přímo ovlivňuje čas prohlížeče. Proto bude velmi důležité mít tuto úroveň viditelnosti, abychom mohli přesně vědět, co se děje, a dát DBA co nejvíce možností, aby si mohli vybrat, která z nich má v dané situaci největší smysl.
Nyní jsou to některé z nabídek a ty se stávají z obchodu PeopleSoft, který má globální nasazení. Precise podporuje aplikace PeopleSoft a SAP, Siebel, Oracle, E-Business Suite, domácí Java a .NET aplikace. Podporujeme proto, pokud provádíte volání webových služeb na více JVM, od Java po .NET zpět do Java, můžeme vše sledovat. Může to být on-prem, může to být v cloudu. Zásadní věc je, že věci musí být instrumentovány.
A tak jen pár nabídek od jednoho z našich zákazníků: „Předtím přesně naše databáze DBA používaly OEM,“ - to je pouze databázový nástroj a v podstatě řekli: „Hej, instance vypadají skvěle.“ Ale mohli pomoci sdělit nebo vyřešit problém s konkrétní transakcí. Přesnost poskytla viditelnost. A tak mít tyto informace o příkazech SQL bylo rozhodující pro to, aby poskytovaly DBA viditelnost pro úplné vytlačení výkonu z databáze. A tak to bylo opravdu pěkné. Druh nad rámec některých nástrojů, na které se možná díváte.
A poté IT management opravdu miloval skutečnost, že Precise dokázal přeložit složitou URL do jména panelu. A pokud tak zavolá koncový uživatel a řekne: „Hej, mám s tím potíže,“ můžete izolovat a zjistit, kdo je ten uživatel, co provádějí, jaký výkon, skutečně měří vykreslování čas v prohlížeči koncového uživatele. Je to skutečná míra zážitku koncového uživatele. A také, že toto ID uživatele je naprosto nezbytné pro pomoc konkrétní osobě, která volá.
Jak to dělá Precise? A tak bychom rádi trochu sdíleli naši architekturu. Přesný by měl žít na svém vlastním serveru a žít ve VM, může žít v cloudu. Na rozhraní frontend je přesný web povolen, ať už používáte dashboardy, výstražné rozhraní nebo expertní GUI. Na straně sběru dat můžeme skutečně udělat agenta pro několik různých technologií. Často však budeme vyžadovat agenta a pro agenta je mnoho výhod a nevýhod. Velkým plusem je to, že shromážděná data lze před odesláním v síti LAN předzpracovat. To znamená, že můžeme minimalizovat celkový dopad monitorovacího řešení na cílové prostředí.
Nyní uvažujte pouze o alternativě, pokud máte „agentless“, stále existuje sběratel dat, jde jen o to, kde žije, a vyřizuje hovory a předává nezpracovaná data o cílové aplikaci v síti LAN. A je to vlastně docela drahé. A tak předběžným zpracováním můžeme skutečně minimalizovat chodidlo. Budete moci sledovat fyzický i virtuální.A jedna věc, kterou jsem chtěl říci o virtuální technologii, je to, že se opravdu zaměřuje na využití. Na co se přesně zaměřuje, je spor. Kdy technologie VMware ve skutečnosti minimalizuje zdroje pro hostujícího VM? A tak je to opravdu snadné. Pokud se díváte pouze na hostujícího VM, máte pouze část obrázku. Být schopen automaticky detekovat a upozornit na soupeření, je to opravdu nezbytné.
Precizní může sledovat až 500 instancí, takže velmi velká nasazení mají v zásadě více přesných serverů. A v případě globálního nasazení se obvykle jedná o přesný server v každém datovém centru. Mimochodem, u největších nasazení je můžete skutečně federovat, abyste se mohli podívat na celou společnost na to, co se děje, a mohli nabídnout reporting atd. Nyní, jak jsem se zmínil, máme spoustu technické analýzy. Ne každý musí jít do expertního GUI, proto vám nabízíme přizpůsobitelný dashboard. A každý z těchto portletů nebo widgetů je vše volitelné. A někdo by mohl jen chtít jít: „Hej, jak můžete zasáhnout výstrahu na nějaké úrovni v našem prostředí? Jak se daří skupinám koncového použití z hlediska výkonu? “Nebo možná budete mít otázku o infrastruktuře, a možná se dostanete i na výkon Tuxedo. Nebo dokonce vyrovnávání zatížení. V této části vyvažování zátěže je to něco zajímavého. Dívám se na portlet uprostřed po levé straně. Můžete vidět, že počet spuštění je mezi jednotlivými webovými servery velmi podobný. Ale doba odezvy se u nejvyšší liší. Ve skutečnosti můžete vrtat a zjistit přesně důvod, proč byla doba odezvy na tomto webovém serveru mnohem pomalejší než u ostatních.
Jedna věc o vyvažování zátěže, to je velmi důležité, a politiky vyvažování zátěže, víte, ne každá zásada vyvažování zátěže je vhodná pro každou aplikaci. Je opravdu užitečné ověřit si zásady vyrovnávání zatížení. Ve skutečnosti se setkáváme s některými aplikacemi, jako je nové uživatelské rozhraní PeopleSoft Fluid GUI, kde některé webové servery skutečně přejdou do režimu offline. A to je něco, co je opravdu kritické. Pokud implementujete GUI PeopleSoft Fluid GUI, kontaktujte nás. Můžeme vám poskytnout spoustu informací a spoustu znalostí o tom, s čím se ostatní zákazníci setkali. Každý z těchto portletů může být velmi podrobný. Stejně jako uprostřed vpravo, s modrou a zelenou, ve skutečnosti ukazuje vzor špičky meče, ukazuje to, že vaše kolekce odpadu v úrovni WebLogic běží tak, jak očekáváte. Každý z těchto portletů může být vysoce zaměřen nebo může být velmi vysoký. A důvod, proč je to důležité nebo důležité, je mnohokrát, že nestačí mít tyto informace pouze v IT, někdy musíte tyto informace sdílet s vlastníky aplikací a někdy s vrcholovým managementem o tom, co se děje .
Chtěl jsem se s vámi podělit o několik příběhů, například „Úspěch v datovém centru“. A to jsou databáze zaměřené a mám další příběhy zaměřené na střední úroveň. Ale dnes se opravdu chci zaměřit na databázovou úroveň. Pojďme se podívat na obrazovku zamrzne. Teď se stalo, že tento konkrétní obchod měl obchodní SLA, že pokud bude objednávka přijata do 15:00, objednávka bude odeslána ten den. A tak je sklad během tohoto časového období velmi zaneprázdněn. A poté, když se obrazovka zamrzla, to bylo velmi frustrující. A tak nadřízený - to je menší společnost - nadřízený ve skutečnosti vstoupil do IT a samozřejmě jde do DBA a říká: „A teď, co se děje?“ A co jsme udělali, jsme byli schopni ukázat přesně Co se dělo. Nyní se jedná o vícevrstvou aplikaci JD Edwards, jedná se o obrazovku prodejní objednávky. Můžete si udělat představu o tom, co to bylo za podnikání, v zásadě inventář v pravý čas, takže se v podstatě díváte na skladové aplikace. A nyní v podstatě přepravujete na řadu různých zákaznických webů, různých obchodů. A udělali jsme to, že jsme otevřeli Precise.
Nyní v tomto případě, předtím, než jsme se podívali na Oracle, se podíváme na SQL Server a nyní nám horní polovina ukazuje skládaný sloupcový graf, kde příkazy SQL tráví svůj čas při provádění. Každý slabý stav je zahrnut v ose y. Osa x, pokud samozřejmě v průběhu času, a můžete vidět, že skládaný sloupcový graf se mění z časového řezu v závislosti na tom, co se provádí a jak systém používá. Nyní v tomto konkrétním případě jsme se zaměřili na třetí sekvenci SQL shora. Je upraveno VYBRAT ZE PS_PROD a ve sloupci vidíte, že jsme zachytili skutečný plán provádění. A můžete vidět v celém počtu poprav. Skutečnost, že tento konkrétní příkaz SQL byl zodpovědný za 9,77 procent spotřeby zdrojů v tomto časovém rámci, na který se díváme - a to je důležitý bod, časový rámec, Precise udržuje průběžnou historii - a tak se mohu v zásadě vytáčet a zjistit, co se stalo v jakémkoli konkrétním okamžiku nebo v čase. Dokážu zobrazit trendy.
Nyní tento příkaz SQL vidíte ten skládaný sloupcový graf, je tmavě modrý. To znamená, že používáme veškerý procesor. Pojďme se zaměřit kliknutím na toto tlačítko „TUNE“ na konkrétní příkaz SQL. Co děláme, že to vezmeme do tohoto workshopu, předem vytvořeného workshopu, který je navržen tak, aby řekl: „Co bude DBA vědět o tomto konkrétním příkazu SQL?“ A na pravé straně vidíte kartu nazvanou „ Historie “, která byla vybrána. Chtěl bych, abyste nyní udělali něco, co byste posunuli na levou stranu, kde je uvedeno průměrné trvání změn oproti době trvání. A každý z těchto barů představuje události denně.
Vidíte ve středu, ve čtvrtek, v pátek, doba provedení byla, já se chystám na bod dva. Osa y ukazuje bod čtyři sekundy, takže bod dva. Velmi málo zamrzání obrazovky, operace jsou skvělé, ve SLA. Bohužel 27. únoratis plán provádění se změnil a to způsobilo okamžitou změnu času provedení. Najednou se doba provádění zvyšuje, čtyři X, možná pět X, a věci běží opravdu špatně. Nyní Precizní, ve svém úložišti vlastně časopisy všechny změny, které by mohly ovlivnit chování. A zde vidíte, že jsme skutečně zaznamenali změny roviny os. Ten uprostřed říká „Změnil se objem tabulky“. A tak tabulky rostou a my máme pravdu na vrcholu, když je analyzován příkaz SQL, optimalizátor vybere jeden plán provádění nebo jiný plán provedení.
Nyní, naštěstí, tento týden v pondělí se to propadlo, takže to bylo v pravý čas. Bohužel to zase překlopí a vy víte, co koncoví uživatelé začínají předvídat zamrzání obrazovky a začnou tuto obrazovku znovu odesílat a tlačí počet provádění nahoru a nahoru a nahoru. Máme obrovské množství podrobností, ale k vyřešení tohoto problému a jeho následnému odstranění v budoucnu potřebujeme další informace. A to mi ukazuje srovnání těchto plánů provedení. 5. březnatis když to bylo rychlé a efektivní, na levé straně to ukazuje plán provedení. Když to bylo 12. března pomalé a neefektivnítis, můžete vidět, že to dělá spojení filtrů. Spojení filtrů jen nutí mnohem větší spotřebu procesoru a dělá mnohem více práce. Výsledek je totožný, dělá jen mnohem více práce. Je to, jako byste jeli a dostali jste zásoby po jedné přísadě najednou, spíše než jít do spíž a získat všechny přísady najednou. Existuje tedy mnohem účinnější způsob, jak toho dosáhnout. Nyní to obvykle vědělo, že DBA byla schopna použít plán dotazů, aby se zabránilo tomuto pomalému plánu provádění a zajistila rychlý, vysoký výkon.
Nyní byl dalším druhem válečného příběhu „Zprávy jsou pozdě“. Myslím, že s tímto scénářem se může spousta lidí ztotožnit. Možná máte přehledy ad hoc, můžete použít nástroj jako NVISION, možná máte nějaký nástroj pro hlášení třetích stran. A co se stane, nástroj vyvine SQL. A SQL není často tak dobře kódováno. A to by se mohlo vztahovat také na situaci, kdy, jak víte, máte nějakou aplikaci třetí strany, správně, kde nebyl SQL napsán interně, a jako DBA: „Neovládám SQL, co budu s tím dělat? “No Precise poskytuje něco, co nevím o žádném jiném databázovém nástroji, který poskytuje, a to je pohled na objekt. V kombinaci s doporučeními a modelováním. A tak můžeme skutečně zviditelnit hlavu. Spíše než se podíváme na aktivitu, prozkoumejme, dobře, jaký objekt je v systému nejtěžší? A v dolní části obrazovky můžete vidět řádek SQL a sloupec „v MS-SQL“. A tabulka řádků objednávky je desetkrát rušnější než kterákoli jiná tabulka v systému. Myslím si, že v horní polovině si také všimnete, alokace prostoru roste a můžete se také podívat na specifikace serveru, jakou verzi softwaru používáme. Přesné zkontroluje sledované změny primárního nastavení. Znovu, příčina a následek.
Nyní se zaměřením na řádkovou tabulku objednávek, co mohu udělat s mým podrobným historickým úložištěm, je, že ve skutečnosti mohu korelovat příkazy SQL, které jdou proti řádkové tabulce objednávek. A můžete začít zkoumat klauzule where v těchto příkazech SQL. A začnete si všimnout, že klauzule where je mezi různými příkazy SQL velmi podobná. A navrhuji vám, abyste ve svém nahrávacím systému našli to samé. Protože obchodní uživatelé, obchodní analytici, budou chtít dělat věci jako agregované obchodní aktivity za poslední den, minulý týden, poslední měsíc, poslední čtvrtletí, minulý rok. Uvidíte velmi podobné, kde klauzule, řazení podle, seskupení podle, a to znamená, že budou existovat určité indexy, které mají smysl pro tyto příkazy SQL.
A tak Precise má motor doporučení, můžete vidět, že v pravém horním rohu, a to, co můžeme udělat, je získat doporučení. Řekněte: „Hele, spouštím všechny příkazy SQL, jaké indexy by je adresovaly?“ Indexy se vám zobrazí a vy můžete skutečně vidět DBL. Nyní je Precise pouze pro čtení, nenabízí možnost kliknout na tlačítko a vytvořit index, ale to je dostatečně snadné dělat mimo Precise. Ale tady je zásadní věc, je Precise vám umožní vyhodnotit a modelovat změny, takže je zde tlačítko Vyhodnotit v levém dolním rohu obrazovky. A co to dělá, je to, že zobrazuje příkazy SQL před a po.
Pojďme se podívat na tyto příkazy SQL. Vidíte zde tento sloupec, který říká „v MS-SQL“ a říká jednu hodinu, čtyři minuty? To nejlepší příkazy SQL spouští nebo spotřebovávají zdroje přibližně 64 minut. A jeho plánované zlepšení je 98 procent. Tyto změny ušetří zpracování hodiny. Další příkaz SQL je 27 minut a v podstatě ušetří třetinu. To je asi deset minut zpracování. Souhrnně, těmito navrhovanými změnami ušetříte hodinám a hodinám zpracování. A být schopen to vědět dopředu, být schopen to modelovat. Můžete také použít schopnost „what-if“ a říct: „No, nechci tento index vytvořit, nebo co se stane, když změním pořadí sloupce?“ A tak mohu tuto schopnost modelování použít přesně zjistit, co se bude dít dál.
Další důležitá věc je, že když provedu změnu, mohu ve skutečnosti měřit pro jednotlivý příkaz SQL. V předchozím příkladu jste viděli historii příkazů SQL a ve skutečnosti si mohu ověřit, zda jsem dosáhl modelových úspor. A tak je zpětná vazba, dokončení smyčky zpětné vazby, naprosto zásadní.
Dobře, tady je poslední příklad, který jsem měl pro vás. Toto je prodejna SAP a víte, šli pro zásadní upgrade, dělali nějaké věci s vlastními transakcemi a v podstatě koncový uživatel nebyl s výkonem spokojen. A tak jsme se dokázali zaměřit na to, co tento koncový uživatel zažil. A v horní části seznamu můžete vidět „VYBRAT“ a doba odezvy je něco přes 61 sekund. Pořízení této věci trvá minutu. Nyní vidíte, že máme skládaný sloupcový graf, který je zaměřen na SAP. Na pravé straně je zobrazen čas klienta, doba čekání ve frontě. Modrá je doba aplikace a v prostředí SAP, to je ABAP kód, a pak databáze. A tak ta databáze, víte, může to být Oracle, může to být SQL, může to být HANA. V podstatě jsme schopni to ukázat.
Nyní, co děláme s Precise, jsme se zaměřili, pro tuto transakci a toho uživatele, jaké příkazy SQL vyšly. Opět to spojí tečky. Nyní tento nejlepší příkaz SQL, můžete vidět, že je v kroužku, provádí se za dvě milisekundy. Opravdu nemůžete vinit databázi, pokud se provádí tak rychle. Počet provedení je velmi vysoký. Vlastně jsme schopni vrátit se k ABAP kodéru a říci: „Hej, co se děje?“ Ve skutečnosti jsme zjistili, že kód v databázi byl umístěn na špatném místě, vnořil se na nesprávné místo v rámci smyčky, udělal změnit a pak jsme schopni měřit po. Můžete skutečně vidět, co je po výkonu. Nejen na úrovni příkazu SQL, ale také na úrovni vlastního kódu. A tak mohli žít s popravou čtyř a půl sekundy. A tak to je jen několik příkladů toho, jak by bylo možné využít Precise, můžete ho využít. Stejně jako rychlá rekapitulace, Precise ukazuje výkon podle umístění, podle ID koncového uživatele, poskytuje kon prostřednictvím aplikačního zásobníku. Můžete vrtat v kořenové příčině. A myslím si, že jedním z velkých rozlišovačů je vědět, nejen příkaz SQL, ale proč příkaz SQL běží pomalu, být schopen identifikovat tvrzení a v zásadě nabídnout více možností pro řešení problémů. To je to, co nabízí Precise a můžete nás konzumovat, víte, lehkým způsobem nebo pokud máte velmi hluboké, velmi náročné problémy, rádi je také vezmeme.
Eric Kavanagh: Dobře, musím říct, že to bylo hodně fantastických detailů, Bille. Děkujeme za zobrazení všech těchto snímků obrazovky. A z mého pohledu jsi opravdu splnil to, co jsem chtěl vysvětlit v horní části hodiny, což je, číslo jedna, musíte mít ten správný nástroj. Musíte mít nástroj, který vám umožní množství podvodů potřebných k identifikaci všech prvků v rovnici, jak řekl někdo ve filmu jednou, to bylo trochu vtipné. Ale dovolte mi, abych to předal a předal to Dezovi, protože se vsadím, že má pro vás nějaké otázky, a chci posunout ještě jeden z těchto snímků jen pro vizuální bonbóny, pokud chcete. Vlastně, vydrž, nech mě to vzít zpět. Ale Dezi, jsem si jistý, že máte nějaké otázky, vezměte si to.
Dez Blanchfield: Jo, jo, páni. Tento nástroj prošel dlouhou cestu od doby, kdy jsem to původně věděl, a nevěděl jsem, že jste se do hromady dostali už tak hluboko. Je to docela ohromující. Jen velmi rychle, pár věcí. Model nasazení, můžete opravdu rychle, za minutu nebo dvě, nastínit tradiční nebo typický model nasazení. Zmínili jste se, že je k dispozici jako virtuální stroj. Může být spuštěn v cloudu. A myslím, že jedna z otázek, která se pravděpodobně objeví, si myslím, že v sekci Otázky a odpovědi se objevilo několik otázek. Abychom je shrnuli v souhrnu, je běžný model nasazení a typ požadované osy tradičně rozmístěn na místě nebo hostován nebo v cloudu? Jaké jsou typy implementačních modelů, které normálně vidíte? A jaký typ osy je třeba, aby to fungovalo? Musíme změnit věci na úrovni zabezpečení kolem přístupu k síti atd.? Nebo se to může chovat jako koncový uživatel?
Bill Ellis: Jo, takže v současné době je většina instalací v provozu. Stále více lidí vkládá komponenty sady aplikací do cloudu, a my to také zvládneme. Nasazení, které potřebujeme k provozu serveru, bude splňovat určité specifikace. K uložení historického úložiště potřebujeme databázi, takže splnění těchto předpokladů je prvním krokem. Další věc je, že určitě potřebujeme znát samotnou aplikaci a instalace je řízena pomocí průvodce a v zásadě vyplňte mezery. Z důvodu hloubky informací, které dostáváme, víte, od úrovně webového procesu po prováděcí kód, potřebujeme určitá oprávnění. Máme bezpečný datový model nebo model zabezpečení, musím říci, protože agenti běží pod přihlašovacími údaji, které jsou zcela oddělené od lidí, kteří používají metadata o transakcích atd.? Přesná komunikace komunikuje přes TCP přes IP, a proto vyžadujeme otevření určitých portů. Jako rychlý příklad, jako je náš výchozí port, je 2702. Tento typ podrobností je něco, pokud mají lidé zájem, mohli bychom se do něj dostat podrobněji. Ale obvykle jsme velmi rychlí čas na hodnotu. Pokud se někdo potýká s velkým problémem, často můžeme věc nainstalovat a zářit jasným světlem na situaci během několika hodin.
Dez Blanchfield: Jo, rozhodně jsem to pochopil také. V modelu nasazení jste hovořili o velmi velkém měřítku a až 500 instancích a o tom, jak by to mohlo být federováno. Na samé vstupní úrovni, jak to vypadá, když někdo chce - protože vím, že IDERA je velmi velká v poskytování přístupu k bezplatným zkušebním verzím, demonstracím zdarma, a pamatuji si, když jsem na webových stránkách viděl téměř všechno, s čím se dá hrát. Pro lidi tady a myslím, že jsem to zmeškal dříve, ale myslím, že se objevila otázka, která vypadá, jak vypadá typický web a jak k němu lidé získají přístup a začnou si s ním hrát a získávat tento typ zkušenosti, kde mohou vidět, zda mají způsob, jak vyřešit některé problémy s výkonem? Mohou si stáhnout ODS a roztočit je na hypervisoru, Hyper-V nebo notebooku nebo potřebují speciální stroj, aby ho mohli provozovat? Představili jste architekturu dříve, ale jen velmi stručně, za minutu nebo dvě, jak to vypadá pro nasazení na základní úrovni, jen aby se například dokázal koncept?
Bill Ellis: Jo, takže náš model je trochu jiný než nástroje IDERA. Hodně se hodíme do scénáře Embarcadero, kde byste chtěli kontaktovat některého z našich obchodních zástupců. Chtěli bychom s vámi jen prodiskutovat, jaké jsou výzvy, a pak bychom obvykle, jak víte, byla přidělena jedna ze SE a v podstatě by s instalací pracovala s někým. Obvykle byste na svém notebooku nespustili Precise. Chtěli byste mít VM nebo server v datovém centru, kde aplikace žije, aby mohl provádět kolekce. Ale my vám pomůžeme v každém kroku. Pokud se o to někdo zajímá, určitě se chcete obrátit na společnost IDERA.
Dez Blanchfield: Jedna z dalších věcí, která mě zasáhla, bylo, že myslím, že mnoho z toho, co jsme dnes pokryli, je reagovat na problémy s výkonem.Ale zdálo se mi, že a v živém prostředí, jak je lidé používají, tak, jako první prezentace, někdo zvedne telefon a řekne: „Aplikace běží pomalu, pomozte.“ Ale to mě zasáhlo, že během předprodeje aplikací nebo upgrady nebo nové opravy a opravy, mohli byste projít spoustou plánování kapacity a stresového testování a nechat si přesně prohlédnout celé prostředí a skutečně najít problémy, než začnete na životní prostředí dávat koncovým uživatelům. Je to případ použití, který jste viděli dříve, nebo to lidé také dělají, nebo to není typický případ použití?
Bill Ellis: Rozhodně bychom chtěli použít Precise po celou dobu životního cyklu vývoje aplikace nebo také během životního cyklu upgradu. Precizní nabízí škálovatelný pohled, ukáže počet provedených překrytí s časem odezvy. Je zřejmé, že pokud jak počet poprav, tak doba odezvy spolu narůstají, nebudete škálovat a musíte něco udělat. Tento druh věcí nesmírně pomohl. Myslím, že je to o něco méně pravdivé, ale když lidé začali vkládat produkční aplikace do VMware, byli trochu váhaví a bylo to jako, víte, na první pohled by to bylo jako: „Oh, musíme to přesunout do fyzicky. “A co vlastně můžeme udělat, je ukázat, jaká je spotřeba zdrojů, takže můžete aplikaci zefektivnit. V každém kroku životního cyklu aplikace určitě chcete použít Precise. Musím však říci, že výroba je opravdu důležitá pro výkon a přesnost je zaměřena na nepřetržité sledování výroby, takže opravdu nechcete spouštět své produkční aplikace bez viditelnosti.
Dez Blanchfield: Absolutně. Ještě jedna rychlá otázka právě na tuto specifickou zkoušku - hloubkový test, imigrace, UAT atd. - myslím, že je skvělé mít tento nástroj a představuji si, že vývojáři aplikací by naprosto rádi měli k tomu přístup prostřednictvím životních cyklů životního cyklu vývoje. . Se složitějšími architekturami, které nyní vidíte, jsme se přesunuli z vyhrazené služby k virtualizaci a virtualizaci, nyní se stěhujeme do jakéhokoli druhu, víte, přijetí outsourcingu do cloudového hostingu a vidíme také přechod do kontejnerizace. Viděli jste mnoho lidí, jak to nasazují a modelují regiony nebo zóny, takže někdo může mít - a v Austrálii máme velmi velký problém týkající se soukromí a vím, že v Evropě je to stejná věc a myslím, že se to stává více případem v USA, kde data, která mě dokáže osobně identifikovat, musí být často v bezpečnějším prostředí, než je skutečná aplikační vrstva pro webovou vrstvu. A tak nyní máme tato nasazení, kde si lidé mohou interně uchovávat svou databázi a jejich aplikační materiál, ale mohou svou webovou vrstvu a její dodávku ukončit a aplikovat atd. V cloudovém poskytovateli, jako je Azure nebo, nebo Amazon Web Services a software . Jak to funguje s běžným nasazením? Je to případ, že jste právě dostali další sadu sběratelů v regionu a jen se agregují? Jak to vypadá v precizním světě v dnešním bimodálním přístupu provozování IT starých starých věcí na jednom místě a vaše zboží je někdy v cloudu?
Bill Ellis: Jo, takže podporujeme smíšené prostředí. Jedna věc, kterou je třeba zvážit, je, že existují různé smlouvy s poskytovateli cloudu. Některé z nich nedovolí žádnému agentovi ani žádnému vnějšímu sledování v cloudu. Chcete-li instalovat a monitorovat pomocí Precise, musíte mít typ smlouvy, která tomuto typu přístupu umožní. Určitě existují určitá omezení, kterými se musíme občas vypořádat, a proto jsou to důležitá kritéria, která byste měli zvážit, když jste, myslím, nejprve podepsat tyto smlouvy a poté nebo / a pokud potřebujete zavést Precise.
Dez Blanchfield: Jo, viděl jsem řadu případů, kdy i v tradičním databázovém prostředí, pokud to obstaráváte jako součást služby, zejména s laskavými věcmi Azure, as, jako byste obstarávali jako HDInsight nebo SQL jako služba, jako platforma, vaše obvyklé nástroje se mohou ponořit jen tak hluboko, protože pro vás nejsou tak nadšení, abyste se podívali na to, co je pod kapotou. A tak skončíte s určitou úrovní nebo hloubkou, kterou můžete sledovat, a najednou prostě nevidíte za kouzelnou oponou. Je samoobsluha věc? Je to tradičně něco, co by běželo uvnitř síťového provozního centra, kde by technický tým, lid pod CIO získával přístup pouze, nebo je to také něco, co můžete poskytnout koncovým uživatelům úroveň přístupu? Možná ne nutně recepce a tradiční lidé v oblasti lidských zdrojů a financí, ale důvtipnější uživatelé, kteří dělají, víte, jako například vědci s údaji, pojistní matematici, statistici, lidé, kteří dělají opravdu velké pracovní zatížení. Je to tak, že mohou získat přístup k jakémukoli samoobslužnému přístupu, aby zjistili, co se děje, když tyto těžké dotazy spouští a kde se vyskytuje bolest, takže si mohou nějak vyladit průběh jejich pracovního vytížení?
Bill Ellis: V programu Precise je velmi dobrá bezpečnost, takže můžete nastavit uživatele, kteří mají různé úrovně přístupu. Na velmi základních úrovních poskytují dohled pouze řídicí panely. A pak v rámci, víte, pokud někdo chtěl jít do Expert GUI, můžete určitým způsobem omezit to, co jsou schopni vidět a co jsou schopni dělat. A jaksi krouží zpět k vaší předchozí otázce, že víte, ve zdravotnictví máte všechny zákony HIPAA, a tak existují určitě určité úvahy a ve skutečnosti existuje několik možností nasazení, abychom s nimi mohli pracovat v obou prostředích. Jedna věc, kterou je třeba vzít v úvahu s údaji, které jste viděli v této prezentaci, jsou všechna metadata o výkonu, ne obsah tabulek, víte, a tak je to opravdu, že se do těchto typů nedostane. obavy o soukromí.
Dez Blanchfield: Jo, to se mi líbilo. Měl jsem moment Eureka o tvém čtvrtém nebo pátém snímku na obrazovce a uvědomil jsem si, že jen táhneš výkon, ne jen, ale táhneš údaje o výkonu, táhneš věci, jak jsi řekl, metadata z na různých úrovních zásobníku, ve skutečnosti se nedíváte na obsah. A myslím, že je to zajímavá věc, protože je to jeden z nástrojů, kde byste jej mohli buď nasadit na krátkou dobu a podívat se na to, co se děje v prostředí, ale nemusíte mít přístup k samotným datům. Můžete se dokonce podívat na způsob, jakým jsou posádky vedeny. Poslední věc, myslím, jen rychle, a pak se vrátím zpět Ericovi, takže pokud máš otázku, pak si Rebeccu zabalím, už jsi zmínil, že režie je nominální, je to tak, že je to dokonce znatelná režie z monitorovací strany věcí a jen pozorování pozadí nebo je to tak zanedbatelné množství režie, že to prostě nestojí za zvážení?
Bill Ellis: Jo, takže si myslím, že v databázové vrstvě víte, každá technologie je trochu jiná. Na úrovni databáze je přesně známo, že překonává nejnižší režii. Ve střední vrstvě je, víte, je tu nějaký druh vyvažování, víte, není to jen přesné, platí to pro všechny, pokud jde o viditelnost a režii. Jednou z věcí je, že nabízíme řadu sofistikovaných nástrojů pro kontrolu toho, co je režie. Jsme navrženi pro výrobu a, jak víte, je rozhodně užitečné zmírnit tolik problémů v zárodku vývoje a QA, ale víte, není nic jako vědět, co se děje ve výrobě.
Dez Blanchfield: Eric, máš pro vás nějaké poslední otázky?
Eric Kavanagh: Jo, jen řeknu, že si myslím, že jsi odvedl skvělou práci, když poukazoval na to, že kon je opravdu klíč, a je to skoro jako kdybychom se posunuli směrem k této éře internetu věcí, chceš všechno vybaveno. A myslím, že nyní ve výrobě je standardem to, což je dobrá zpráva, že? Protože chcete mít možnost stahovat informace ze všech těchto různých prostředí a spojovat je dohromady. A myslím, že vám to jen předám, abych vám dal další připomínky. Na to se zaměřujete, je poskytnutí vizuálního rozhraní, pomocí kterého může nějaký analytik, analytik IT v podstatě, sledovat a analyzovat, co se děje v tomto komplexním prostředí, a pak přijít na to, co se má změnit. Protože to není jen nástroj. Musíte mít tento nástroj, ale potřebujete toho člověka, který se chystá kopat do tohoto detailu a najít odpovědi, že?
Bill Ellis: Jo, vidím to tak, že se vaří na vrchol a upřednostňuje, kde je nejvíce zpětného odkupu, víš? Pokud se ukáže, že je to jiná situace, protože ne každý problém je v databázi. Pokud je databáze, víte, věci se provádějí za desetinu sekundy, ale na aplikační vrstvě to trvá tři sekundy, to je místo, kde je nejvíce zpětného odkupu. A takový druh schopnosti izolovat problémovou úroveň a pak to, co se děje v rámci této úrovně, se opravdu soustředit na to, kde je zpětný odkup. To opravdu urychluje řešení a optimalizaci aplikace a je to mnohem rychlejší a mnohem lepší a mnohem zábavnější než lidé, kteří se shromáždili v konferenční místnosti, která chodí: „No to nejsem já, musí to být někdo jiný.“
Eric Kavanagh: To je správně. Druhý den jsem viděl skvělou pomluvu, která řekla něco jako: „Buďte informováni, ne jen s názorem.“ Vstupujete na schůzku, máte informace, můžete ukázat na data. To je klíč a my se tam dostáváme, díky bohu. Dobře lidi, jdeme do toho a zabalíme, ale všechna tato webová vysílání archivujeme pro pozdější prohlížení. Neváhejte a podívejte se na to kdykoli. Seznam všech našich webcastů nyní, série Hot Tech a série Briefing Room na Techopedia.com, takže hop online a podívejte se na tyto lidi ven. S tím se ti rozloučíme. Díky za dnešní čas, Bille. Díky vám a všem vaší tvrdé práci, Dez. A povíme vám příště, lidi. Opatruj se. Ahoj.