Odnést: Host Eric Kavanagh diskutuje v této epizodě Hot Technologies o řízení výkonu PeopleSoft s Mattem Sarrelem a Billem Ellisem.
Eric Kavanagh: Dobře, dámy a pánové. Dobrý den, vítejte znovu. Je středa ve 4 hodiny východní a za posledních několik let, to znamená v tomto světě IT a velkého podnikání a dat, je čas na Hot Technologies. Ano, jmenuji se Eric Kavanagh. Budu vaším moderátorem dnešní akce.
Budeme mluvit o systémech, které řídí podnikání, lidi; mluvíme o PeopleSoft, o tom, jak řídit výkon složitých prostředí. Vždycky ráda zmiňuji, že v těchto událostech hrajete velkou roli, takže se nemusíte stydět. Zeptejte se kdykoli; můžete tak učinit pomocí okna chatu nebo otázek a odpovědí - ať už se tak stane. Rád bych slyšel, co chcete vědět, a to je nejlepší způsob; získáte nejlepší hodnotu za svůj čas. Všechna tato webová vysílání archivujeme pro pozdější poslech, takže mějte na paměti.
Pokud systémy běží pomalu, mějte na paměti, jak býval život. Tato fotografie je ve skutečnosti z roku 1968, s laskavým svolením dámy jménem Danelle, a musím říci, že toto je ostře připomínka toho, jak se věci změnily. Svět se stal pozoruhodně složitějším a samozřejmě obchodní potřeby a uživatelské zkušenosti mají tendenci jít ruku v ruce. Ale v těchto dnech je trochu odpojení. Jak často říkáme, existuje nesoulad a faktem je, že podnikatelé vždy chtějí věci rychleji a rychleji, týmy IT, které musí dodávat, jsou ty, které jsou vystaveny tlaku, aby tuto práci dokončily, a je to tam intenzivní svět.
Musím říct, že konkurence se všude zahřívá. Pokud se jen podíváte na jakékoli odvětví, můžete vidět, že v současnosti dochází k významným změnám - například Amazon kupuje Whole Foods. Můžete si být jisti, že potravinářský průmysl se na to tvrdě podívá.Vidíme to všude, takže je skutečně na vedoucích obchodních firmách, aby se ujistili, že přijdou na to, jak - a tady je v dnešní době bzučení - digitálně přeměnit, jak se přesunout ze starého rozvaděče k mnohem novým a robustnějším systémům. O tom dnes mluvíme.
Jedním z problémů, kterým čelí mnoho organizací, zejména těch, které již nějakou dobu existují, jsou tyto starší systémy. To je starý mainframe IBM zezadu. Všude jsou staré systémy. Jedním z vtipů je, že starší systém je systém, který je ve výrobě, což znamená, že ve chvíli, kdy jde do výroby, technicky je to starý systém. Vždy budou existovat nové způsoby, jak dělat věci.
A v posledních několika letech došlo k některým velmi zajímavým vývojům, pokud jde o nalezení způsobů, jak virtuálně sladit systémy, a to nejen nutně ke zlepšení výkonu jednoho systému, ale také k nalezení způsobu, jak vytvořit určitý druh odnože nebo taktiky pro nakládání s výkonem. jinak. Dnes budeme mluvit více o tom, jak zlepšit výkon systému, jako je PeopleSoft, což je samozřejmě neuvěřitelně složité. Ale když se to povede dobře, když se načte, když se implementuje, když se dobře zvládne, může to dělat skvělé věci. Ale když se to nepodaří dobře, pak máte všechny druhy problémů.
Co se tedy stane? Musíte být realističtí o věcech a v jakémkoli prostředí, pokud uživatelé nedostanou to, co chtějí, dříve či později jdou do stínových systémů. Stává se to pořád. Stínové systémy mohou být velmi produktivní, mohou lidem pomoci dokončit práci. Ale samozřejmě existuje spousta problémů. Určitě v celé oblasti dodržování předpisů a regulace jsou stínové systémy velkým ne-ne. Ale jsou tam a myslím si, že je důležité si uvědomit, že vaše systémy, pokud váš hlavní systém nefunguje rychle nebo nefunguje efektivně, dříve či později budou existovat zástupná řešení a tato zástupná řešení mohou být velmi těžko odhalitelná, může být obtížné zapadnout, protože se pro firmu rozhodují. Mohou být obtížně integrovatelné, takže mějte na paměti, že je tam venku, a je to jen další důvod ke zlepšení výkonu.
Nedávno jsem o tomto výrazu slyšel a musím ho vyhodit: „tyranie naléhavosti“. Myslím, že právě slyším, že asi víte, o čem mluvím a co se ve většině organizací děje, že pracovní vytížení dosáhne kritického množství a lidé dělají, co mohou, a je velmi obtížné něco změnit. Skončíte trpící „tyranií naléhavosti“ - všechno se musí hned udělat. Aktualizace systému se neprobíhá hned.
Každý, kdo kdy prožil upgrade ERP z jedné verze na druhou, ví, že se jedná o relativně bolestivý proces, takže na to nezapomeňte: Pokud to vidíte ve své organizaci, uznejte to. Doufejme, že se s někým můžete projít, nebo pokud jste starší člověk jako CIO nebo CTO nebo CEO, uvědomte si, že je to velmi nebezpečný scénář, protože jakmile jste za osmi míčem, je opravdu těžké se dostat zpoza osm míč.
Je to jako celé maratónské hlavolam: Pokud skončíte daleko za závodem nějakého druhu a všichni jsou před vámi a vy stále běháte, bude opravdu těžké dohnat je, pokud příliš zaostáváte. Jen si na to dejte pozor a mějte na paměti.
A s tím se chystám podat Mattovi Sarrelovi, abych získal několik poznatků o tom, jak zvládat složitost s prostředím PeopleSoft. Matte, vezmi to pryč.
Matt Sarrel: Dobře, děkuji, Ericu. Ahoj všichni. A tak, uvidíme, začnu tím, že ti řeknu, proč si myslím, že jsem ta pravá osoba, která s tebou mluví o řízení výkonu. Takže mám 30 let zkušeností v technologii. Ráda bych řekla, že jsem se při několika start-upech postavil na ruce, jako správce sítě, ředitel IT, viceprezident pro techniku. Pak jsem tento přechod učinil technickým ředitelem ve společnosti PC Mag. Tam je můj obrázek, ale v podstatě vypadám jako malé dítě.
A poté pokračoval a byl novinářem v řadě různých publikací, jako jsou eWeek a InfoWorld, jako analytik v Gigahome, navazování kontaktů se skupinou Bloor Group a také vedení konzultace. A tady jsem: Tento obrázek vlevo je to, co teď vypadám. Tento obrázek uprostřed je jakýmsi místem, kde jsem velmi šťastný - v místnosti plné drátů a blýskavých světel a tam, kde je jeho zima - musí být velmi zima a všichni ostatní musí být nepříjemní, abych se cítil příjemně z hlediska teploty. A moje kontaktní údaje, pokud máte nějaké další otázky.
Chci zde uvést pódium a mluvit jen o výkonu, jak Eric mluvil. Nyní jsme vstoupili do tohoto světa, kde uživatelé očekávají očekávání stanovené spotřebitelskými aplikacemi a weby. A lidé byli ochotni chodit do práce a sedět tam a čekat na své systémy, protože je to to, co potřebovali, a teď lidé tam opravdu nejsou ochotni sedět. Je tedy otázkou, zda chtějí, aby tento motocykl létal po trati. Pravděpodobně nechtějí, aby ten chlap jezdil na kole a nosil jeho dceru do školy. Ale co budete poskytovat?
A je to těžké, protože - ve skutečnosti jsem byl tak štědře s touto jednou až třemi vteřinami dobrými - lidé chtějí také okamžitou reakci a chtějí přístup odkudkoli. To, že kdekoli ve vaší budově nebo na kampusu může být kdekoli, nebo to může být kdekoli na světě kdykoli v závislosti na tom, jak dobře funguje vaše firma. A myslím, že to, co buduji, je to, že když mluvíme o výkonu, je důležité myslet na výkon z úhlu uživatelské zkušenosti.
Je důležité definovat výkonnostní cíle před měřením a laděním. Mám tento obrázek tuneru a pak tuneru. Skutečný muž, který je tunerem, potřebuje vědět, na co ladí, nebo nemá smysl vlastně klást ruce na klavír a naladit ho. Takže definování cílů předem, bude to určitě udržet realitu namísto přizpůsobení cílů tak, aby odpovídaly aktuální situaci. Je důležité monitorovat metriky v průběhu času a uvědomit si, jak se systémy mění s výkonem aplikace pro načítání uživatelů, což je ovlivněno scénami zdrojů a vzory využití.
Vždy je důležité sladit to vše společně s uživatelskými zkušenostmi nebo incidenty podpory, stanovit základní hodnotu pro výkon, který očekáváte, že bude schopen poskytovat, a když se blížíte k odchylkám od této základní linie, máte aktivní upozornění, abyste mohli jednat dříve, než zasáhnout stav „selhání velryby“. A víte, že to vyžaduje schopnost rychle a snadno určit a řešit hlavní příčinu problému s výkonem. A znovu, toto je dřívější, tím lepší, že?
Víme, že z minulé historie při pohledu na vývojové úsilí, čím dříve můžete najít a opravit problémy s výkonem, tím lépe jste. Pokud počkáte, až bude celý váš kód nebo váš systém živý, než začne testovat výkon nebo odhalovat problémy, nebudu říkat příliš pozdě, ale znovu, nyní jste chlap, který dostal špatný start do maratonu a nyní hrajete chytit -up místo skákání přímo ven a dostat se dopředu. Jak na to? Očekáváte svůj průměr a maximální zatížení?
A jdete do toho a změníte velikost svých fyzických serverů nebo virtuálních serverů nebo cloudových instancí nebo kontejnerů a zdrojů kontejnerů a poté spustíte důkaz konceptu a spustíte pilota? To jsou časy, kdy je to takový druh, konec místa, kde byste chtěli něco chytit, i když stále jste lepší chytit to ve výrobě než jej ignorovat ve výrobě. Ale opravdu, v době, kdy jste ve svém pilotním projektu, byste již měli mít stanovenou metodiku a postupy týkající se nepřetržitého monitorování a zlepšování.
Dobře, takže mnoho společností - mluvíme o digitální transformaci. DevOps, v revoluci DevOps hraje obrovskou roli v této digitální transformaci. A to je proces end-to-end, který se nikdy nezastaví. Je to jako by se obě ruce navzájem přitahovaly, a to je dobrá věc. Je to nekonečná smyčka mezi těmito dvěma rukama plánu, kódu, sestavení, testování, uvolnění, nasazení, provozu, sledování, zpět k plánu. Živí se samo a my jej automatizujeme, takže to jde rychle. Vytváří smyčku zpětné vazby pro sledování výkonu výroby a používá ji k proaktivnímu odhalení problémů s výkonem a jejich opravě, než ovlivní celou vaši uživatelskou základnu.
A další věc, nyní, když ji máte, vývojáři IT a provozní pracovníci se pohybují velmi rychle a vyrovnaně, můžete také snadno sladit toto úsilí s obchodními zaměstnanci. Výkon podnikového softwaru je komplexní zvíře. Dalo by se to přirovnat k fotbalovému týmu, který seděl před tabulí směřujícím směrem, a všechno funguje samostatně a všechno funguje společně. Vždycky na to myslím jako na starý příběh, když jsem dostal své první auto a opravil jsem jednu věc. Opravil jsem klimatizaci a pak se stalo, že pak zbytek chladicího systému selhal. Takže máte body bolesti a všechno, co jdou společně a upravujete. Všechno musíte uspořádat takovým způsobem a procesy sestavovat tak, aby při provádění změn rozumíte tomu, jak všechno ovlivňuje všechno ostatní.
A také buďte opatrní a důkladně zkontrolujte. Otestujte, zneplatněte, implementujte. A opět se dostáváme k tomuto problému budování programů kontinuálního monitorování a zvyšování výkonu. A to je ve skutečnosti můj poslední snímek. I když mluvíme o této složitosti a je to krásná složitost stejně jako uvnitř těchto hodinek, máme tolik pohyblivých kusů do PeopleSoft. Každá věc má vliv na všechno ostatní až do zásobníku. A existuje mnoho různých míst, kde můžete hledat klíče k problémům s výkonem, které byste se mohli snadno snadno ztratit bez správného nástroje a bez správného procesu. A opět na všechno, v mnoha případech se domnívám, že jsme se naučili, že můžete řešit infrastrukturu, ale obrovskou proměnnou bude váš vlastní kód aplikace. Klíčem proto bude mít správné procesy pro testování a neustálé zlepšování kódu aplikace.
A to je konec mé části a já to předám Billa.
Eric Kavanagh: Dobře, Bille, dovolte mi, abych vám dal klíče pro WebEx zde. Líbí se mi ta krásná složitost - to je pěkné. Měl jsi tam pár opravdu dobrých nabídek, Matte. Dobře, Bille, vezmi to pryč. Pokud chcete sdílet obrazovku, přejděte na „rychlý start“. Všichni vy.
Bill Ellis: Děkuji, Matte, a děkuji, Ericu. Jen pro potvrzení, vidíte teď všichni moji obrazovku?
Eric Kavanagh: Ano vskutku.
Bill Ellis: Takže se chystáme mluvit o produktu IDERA Precise for PeopleSoft a viditelnosti, které vám mohou pomoci uspět při správě složité sady aplikací. Způsob, jak umístit obtížnost, je, že jedna aplikace, minimálně šest technologií, mnoho koncových uživatelů a je velmi obtížné odpovědět i na jednoduché otázky. Má koncový uživatel problém? Kdo je koncový uživatel, co dělají, co je hlavní příčinou?
To, co obvykle vidíme, je tato situace - a to se může týkat aplikace PeopleSoft, jakož i dalších aplikací nebo aplikace PeopleSoft spolupracujících s jinými aplikacemi - je v rámci datových sad, nebo by to mohl být cloud v těchto dnech, koncový uživatel se o to nestará ta složitost. Chtějí pouze dokončit transakci, přístupy, vyhledávání inventáře, hlášení časového výkazu, ty typy věcí. Pokud jsou věci pomalé nebo nejsou dostupné, obvykle všichni tito inteligentní, dobře mínění lidé nevědí, dokud si koncový uživatel nestěžuje.
Je to druh mezery ve viditelnosti a pak se může stát, že může nastartovat časově náročný a frustrující proces, kdy lidé mohou otevřít nástroj a podívají se, bohužel, pouze na podmnožinu aplikačního zásobníku. Zůstávají tak potíže s odpovědí na tyto základní otázky.
A mnohokrát se může jednat o problém a půjdete k administrátorovi WebLogic a on řekne: „No, paměť, kolekce odpadků vypadají skvěle. Opravdu si nemyslím, že je to WebLogic. “Jdete k administrátorovi DBA a říkají:„ No, databáze, běží přesně tak, jak to bylo včera. Prvních deset vypadá dobře. Možná vás správce úložiště zasáhl několika metrikami, jako jsou I / O za sekundu nebo propustnost, což jsou metriky na úrovni rámce a nemusí se odrážet na vaší konkrétní aplikaci, mnohem méně na databázi nebo na konkrétní proces. “
A tak všichni mají tyto metriky, které podle všeho ukazují, že problém je jinde, přesto má tento koncový uživatel problém nebo ohlásil problém, ale jak můžeme tento problém vyřešit lépe? A lepší způsob, přesný způsob - nebo to je jeden způsob, který nabízíme - je měřit uživatelské transakce začínající v prohlížeči přes síť, do webového serveru, do Java Jolt, do Tuxedo, do databáze včetně DB2 a nakonec do úložiště.
A to ukazuje, že celkový čas říká: „No, kdo má problém?“ A pak můžeme identifikovat koncového uživatele podle toho, jak se přihlásili na PeopleSoft, a pomocí překladu Tuxedo můžeme také zachytit, co panely PeopleSoft provádějí.
Načasování se tedy vkládá do historického úložiště, které nazýváme databází správy výkonu, a to se stává jediným kusem hudby, který výrazně zjednodušuje kdo, co, kdy, kde, proč. Přesné také obsahuje doporučení. Pravděpodobně nejdůležitější je, že všechny informace zachycujeme po celou dobu - na úrovni technického personálu IT - můžete měřit před a po. Takže můžete přinést měření měřením nebo Six Sigma k celé operaci výkonu.
A tak se pojďme podívat na „den v životě“. Nejprve si můžete otevřít obrazovku s přesným upozorněním a tam se dostanete včasné varování. Úplné nejvyšší upozornění je, že máte upozornění na aktivitu. To znamená, že uživatelé provádějící transakce a v zásadě nesplňujeme naše SLA. Stejně tak máme stav, kdy dostupnost - a to v podstatě říká, že část naší aplikační infrastruktury není k dispozici - takže se můžeme vrhnout a můžeme skutečně vidět, jak instance Tuxedo ve formě, a můžete skutečně vidět, že jeden z instance jsou dole. Veškerá činnost je tlačena do této jedné instance a musí se s tím vypořádat. V podstatě jsme vytvořili úzký profil.
Nyní, stejně jako věc, pro činnost, která na tom běží, se můžete skutečně začít zabývat zjištěními, že i když máme tento celkový problém s infrastrukturou, existují způsoby, jak zlepšit efektivitu zpracování v tomto konkrétním JVM pro WebLogic. A tady je to opravdu důležitá věc: Mnohokrát se lidé pohybují jako do cloudu a říkají: „No, kolik CPU a kolik paměti potřebujete?“
Druhou stranou této mince známé jako kapacita je efektivita zpracování. Pokud používám méně paměti, pokud využívám méně CPU, prostě prostě nepotřebuji tolik. A tak, jak Matt řekl dříve, všechno souvisí. Nyní mohu otevřít obrazovku transakce PeopleSoft a na obrazovce je osa y doba odezvy, osa x je čas přes den.
Máme zde sloupcový sloupcový graf, který ukazuje čas klienta. To je vlastně prohlížeč, webový server. Zelená je čas Java, druh růžové je Tuxedo, tmavě modrá je čas databáze. Tento profil se sám nestal; stalo se to kvůli konkrétním panelům PeopleSoft - byly provedeny a jsou vám prezentovány podle doby odezvy. Je to vlastně načasování každého kroku v aplikaci, stejně jako sloupcový sloupcový graf, který zobrazuje aplikaci zde po jednotlivých panelech. Jsem také schopen vrtat a najít konkrétního uživatele nebo pořadí mých uživatelů.
Tato obrazovka mi umožňuje určit konkrétního uživatele podle přihlašovacího jména. Přemýšlejte o tom, jak pozoruhodné nebo jak moc je to. Mnohokrát to není jen o infrastruktuře a o jejím nastavení, o tom, jak koncoví uživatelé systém používají. Můžete mít novou výpůjčku nebo někdo má novou funkci úlohy: Nemusí vědět, jak správně používat aplikaci. To ve skutečnosti může pomoci určit příležitosti k školení.
Druhou stranou mince je, pokud se mohu soustředit na konkrétního uživatele - zde se dívám na daného uživatele v jeho konkrétních transakcích a na dobu odezvy, kterou zažili - jsem schopen přímo oslovit uživatelský zážitek konkrétního uživatele. Nejde již o obecné metriky na systémové úrovni, o zážitek koncového uživatele a to je velmi silné. Části vašeho prostředí budou určitě interní, personální, atd. Mohou existovat i další části, které jsou orientovány na zákazníka. Ať tak či onak, chcete poskytnout co nejlepší a nejproduktivnější zkušenosti zákazníků.
Nyní pro konkrétní panel mohu jít dovnitř a promítat, abych odpověděl na otázky. Je to druh hlubokého ponoru, který můžeme udělat, abychom odhalili, co se děje, a tento hluboký ponor byste mohli udělat předtím, než zavoláte koncovému uživateli, nebo kdyby vás koncový uživatel zavolal, mohli byste zahájit proces, který říká: "No, kde přesně je hlavní příčina?" A nebude to jako využití CPU a převažující, bude to v aplikačním kódu, který vykonávají.
Podívejme se na tuto správu obsahu a dobře se podíváme na tuto správu obsahu a ve skutečnosti si můžeme prohlédnout analýzu této transakce: spuštění prohlížeče, vstupního bodu webového serveru do Java Jolt a vlastně zobrazování kódu, který se provádí dolů do panelu Tuxedo, nakonec do příkazu SQL, kde Precise odhalí příkaz SQL, který je proveden tímto konkrétním panelem PeopleSoft.
Všichni, se kterými mluvíme, mají nástroje, ale to, co nemají, je kon. Spojování teček nebo sledování transakce z prohlížeče až k příkazu SQL je kon. To, co to dělá, jako vaše DBA, je spíše než pohled na věci na úrovni instance nebo databáze, nyní mohu vyšetřovat na úrovni příkazů SQL.
Takže mohu říci: „No, jaké jsou překážky pro jednotlivé příkazy SQL,“ a to je nesmírně silné. Uvědomte si prosím, že tato transakce nemůže probíhat rychleji než příkaz SQL a každá významná obchodní transakce interaguje se systémem záznamu. Databáze, ať už se to líbí nebo ne, je základem výkonu, a pokud mohu být natolik zrnitý, že se mohu soustředit na jednotlivé příkazy SQL, které jsou životně důležité pro obchodní transakci, mohu svou hru opravdu posunout na další úroveň.
Další věc, kterou byste si zde mohli všimnout, je výpočet procentního podílu, který poskytuje Precise. Samotný prohlížeč je ve skutečnosti významnou součástí zásobníku aplikací.Máte spuštění JavaScriptu, máte čas vykreslování, máte komponenty stránky, GIF, JPEG. Ve skutečnosti zjistíte, že se vaše aplikace může chovat v Chrome v porovnání s IE a různými verzemi velmi odlišně. Přesné bude moci ukázat, že vám také, a tam mohou být časy, kdy je vlastně úzký profil nebo soupeření v prohlížeči, které mohou způsobit takové věci, jako je zmrazení obrazovky.
Být schopen identifikovat, který umožňuje IT, aby neštěkával nesprávný strom, ale aby řešilo základní příčinu různých problémů, které mohou nastat. Nyní, co mohu udělat, je pro konkrétní příkaz SQL, mohu pak analyzovat přesně, co se děje v tomto příkazu SQL. Takže zde jsme se dostali do pohledu odborníka na databázi.
Jedna z věcí, která rozlišuje preciznost na úrovni databáze, je to, že vzorkujeme na základě druhé vteřiny. To je ve srovnání s našimi konkurenty, kteří vypadají pouze jednou za 10, jednou za každých 15 minut. Aby byla úroveň podrobnosti, úroveň rozlišení je řádově lepší než naši konkurenti.
A znovu, protože databáze je součástí naší nadace, umožníme vaší DBA, aby skutečně posunula výkon na další úroveň. Takže vidím, že tento příkaz SQL skutečně strávil 50 procent, pokud jeho čas praktikoval přístup k uloženému subsystému, 50 procent svého času pomocí CPU. Klikněte na tlačítko naladit a pak se mohu dostat dovnitř a podrobně rozebrat plány provádění a přesně to, co řídilo tento vzorec použití.
Nyní citát od jednoho z našich zákazníků - pokud nebyli v Oracle Shopu, použili nástroj Oracle s názvem OEM a OEM je opravdu druhem databáze nebo instance - je to DBA, které neustále hledají, jaké jsou 10 nejlepších? Ale s přesností dokážeme spojit tečky s jednotlivými příkazy SQL, takže granularita umožňuje DBA opravdu naladit na úrovni transakce a ne jen na mnohem vyšší úrovni databáze.
Druhým bodem, který byl pro tohoto zákazníka skutečně důležitý, je to, že přesným přeložením své komplikované adresy URL do jména panelu PeopleSoft - pokud jsem v IT a já můžu mluvit o stromovém manažeru, správci obsahu, konkrétní stránce HR, tímto způsobem osoba, kterou se snažím pomoci, zná Im vlastně dívám se a rozumím tomu, na co se dívají, protože už to nejsou tyto hieroglyfy, je to jméno, se kterým jsou obeznámeni.
Jedna z otázek, které jsme položili - zdá se, jako vždy, a tak jsem si myslel, že Id prostě proaktivně odpovídá na otázky - jak na světě zachycujete ID uživatele PeopleSoft? Dovolte mi projít kroky. Zde je přihlašovací obrazovka aplikace PeopleSoft. Pro přístup jsem musel přejít na svůj webový server a objeví se tato obrazovka. Když je aplikace vybavena Precise, tato obrazovka ve skutečnosti obsahuje přesný skript a mohu odhalit provedením pravého kliknutí a zobrazení zdroje. A to mi skutečně ukáže, že kód, který tvoří podkladovou stránku a až sem v rámečku stránky, je ve skutečnosti přesný pro webový kód, což mi umožňuje zachytit přihlašovací obrazovku, IP adresu, typ prohlížeče, celek banda informací o vykreslování a skutečné zkušenosti koncových uživatelů. A tak, když vložím své uživatelské jméno a kliknu na přihlášení, bude Precise schopen měřit, co dělám.
Otevřu se, jdu do stromu, chci provést operaci vyhledávání, vyplním pole a kliknu na vyhledávání. Sada výsledků je mi předložena, takže jsem jasně prošel celým aplikačním balíčkem až do databáze. Jak to ukazuje Precise? Pojďme se na to podívat. Otevřít Přesně, jdu dovnitř, vidím aktivitu, mohu kliknout na kartu aktivity, která vyvolá tuto obrazovku. Toto jsou nepřekládané adresy URL. Mohu ukázat uživatelům a zde je moje uživatelské ID, ke kterému jsem se právě přihlásil, a zde je moje aktivita.
Viděli jste, že k tomu používám Firefox verze 45. Aplikaci jsem uplatnil 12krát a opuštění je v podstatě, když někdo opustí webovou stránku dříve, než se zcela vykreslí, což naznačuje obchodní problém. Takto jsme mohli vyzvednout ID koncového uživatele. Je to velmi pěkné, lidé opravdu ocení, když přesně víte, co se děje.
Nyní chceme řadit rychlost trochu divně. Transakci jsme se dívali později. Udělali jsme hluboký ponor na konkrétní transakci a podívali jsme se na její příkazy SQL. Nyní chci řadit rychlost a podívat se na některé další technologie v aplikačním zásobníku PeopleSoft počínaje WebLogic.
Tady je tedy instance WebLogic a aktivitu můžete vidět v průběhu času. Máte finanční zprávu. Říká mi to hned z netopýra, paměť se používá téměř na maximum. Jednou z věcí, které najdeme, je, že většina lidí spouští celý aplikační zásobník nebo alespoň část ve sdíleném prostředí, často jeho VMware. Musíte se vyrovnat, kolik zdrojů požadujete a kolik potřebujete. Nechcete být prase zdrojů. Stejně tak nechcete dát omezení zpracování tím, že v tomto případě nepožadujete dostatek paměti.
Konfigurace je nezbytná také pro správu výkonu. Můžeme se tedy skutečně dostat do paměti paměti a všech čítačů JMX WebLogic, takže přesně vím, jaké zdraví má forma WebLogic.
Teď do Tuxeda. Tuxedo v mnoha obchodech je druh černé skříňky a je velmi důležitou součástí programu PeopleSoft. Je to druh lepidla, který drží všechno pohromadě, a tak si ho téměř představuji jako rozšíření operačního systému. Je to něco, co velmi pečlivě používáte a konfigurujete. Mimochodem - toto je malá vedlejší poznámka - v úvodních komentářích Eric zmínil „tyranii naléhavosti“, a myslím si, že to opravdu začíná hrát, když obchody PeopleSoft uvažují o přechodu z klasického uživatelského rozhraní na tekuté uživatelské rozhraní, protože zjistíte, že jste za křivkou kvůli způsobu, jakým tekuté uživatelské rozhraní cvičí prostředí PeopleSoft.
Nyní máte problémy ve WebLogic, v Tuxedu, v databázi a v úložišti právě proto, že HTML5 provádí obrovské množství zpráv. Je to pravděpodobně alespoň 10x to, co dělá klasické UI a že další zprávy znamenají další provoz. Takže konfigurace Tuxedo musí být upravena tak, aby vyhovovala dalšímu provozu. Několik věcí na této obrazovce skončilo na pravé straně máme grafy s časem pro váženou dobu odezvy, průměrnou dobu odezvy a počet provedení.
Tady máme informace o všech doménách Tuxedo v prostředí. Rozdělili jsme služby, uživatele, serverové procesy a také IP. Mohu to přesunout na počet provedení a uvést ty v sestupném pořadí, abych viděl, co se popravuje nejčastěji. Mohu také posunout dolů a odhalit domény; většina lidí má ve svém prostředí více domén, aby v podstatě rozložila aktivitu, a jsem schopna nastavit soulad se SLA, proto upozornění na vrstvu Tuxedo.
Pokud máte ve frontě, máte kvůli konfiguraci různé problémy. Obvykle - protože je to dopad na celý svět - obvykle nebudete provádět změny za chodu. Chtěli byste postupně zvyšovat systém jako součást procesu QA, který skáče zpět do bodu, který Matt učinil dříve o řešení problémů s výkonem na začátku procesu. Je mnohem lepší mít správnou konfiguraci, když jdete do výroby, než do výroby a zjistíte, že konfigurace neodpovídá vzorům použití. Moc se mi líbí úvod, který Eric a Matt dnes poskytli. Myslel jsem, že jsou opravdu na cíli, pokud jde o výzvy, kterým čelíte při řízení a vývoji prostředí PeopleSoft.
Teď jsem to už jednou řekl - myslím, že stojí za to říci znovu: Každá významná obchodní transakce interaguje s databází. Pojďme tedy prozkoumat, jak může Precise poskytnout další informace. Zde je konkrétní instance Oracle. Stejný přesný přístup, jaký jsme viděli - osa y je doba provádění, osa x je čas během dne, ale nyní jsou sloupcové sloupcové grafy stavy provádění v rámci Oracle. To nám ukazuje, jaká jsou omezení zpracování v systému. Tady dole je vlastně zpráva o nálezech, která mi říká, že máš tento vysoký redo log buffer.
Také se dívám na tuto vybranou verzi z PSVersion. Ve skutečnosti spotřebovává spoustu zdrojů. Mimochodem, protože odebíráme vzorky a poskytujeme tento pohled ve vysokém rozlišení na to, co se v systému skutečně děje, můžete být překvapeni, kdo jsou skuteční spotřebitelé zdrojů ve vašem systému, protože pokud se jen každých 10 minut díváte, nebude to ukázat, co tito spotřebitelé zdrojů jsou. A tak, že víte, co jsou skuteční spotřebitelé zdrojů, můžete ve skutečnosti řešit skutečné zpracování na úzkých místech nebo v systému.
Tady jsme přeskočili na kartu aktivity a toto je aktivita. Uvidíte, že se společně podíváme na procesor, úložný subsystém, aplikační zámky, čekání na OS, RAC, potvrzení, server Oracle, komunikaci a interní agregaci. Toto je osa y, jedná se o celkovou dobu provádění.
Tady dole jsou příkazy SQL, které řídily tento profil, a jedna z věcí, které vidíte, jsou tyto nízké latence - dvě milisekundy, ale s téměř 4 500 spuštěními znamená, že příkaz SQL je ve vašem systému skutečně spotřebitelem číslo jedna a je dobré vědět. Je to také nečeká na zámek nebo čekat. Využívá CPU na 100% času. To neznamená, že tam nejsou věci, které s tím nemůžu dělat. Existuje spoustu věcí, které s tím mohu udělat, pokud vím, k jakým příkazům a objektům SQL se přistupuje. A tak to jsou některé ze způsobů, jak vám můžeme pomoci.
Tady dole je tato podrobná analýza, která nás může zapojit do jednotlivých programů PeopleSoft a každý z těchto programů slouží v rámci programu PeopleSoft odlišně. Ve skutečnosti můžete začít na úrovni databáze řešit, jak se aplikace používá.
A pokud vyberu konkrétní program, pak mohu izolovat příkazy SQL, které tento program odeslal, abych mohl být zaměřen spíše na aplikace než na databázové technologie, když jsem v podstatě hledal a prohlížel optimalizaci databáze a konfiguraci databáze. Chci to jen upozornit. Mnoho velkých organizací se často dělí na infrastrukturní DBA a aplikační DBA. Přesné, tím, že ukazuje aplikace, stejně jako spotřeba zdrojů, jsme skutečně schopni překlenout mezeru a toto řešení je užitečné pro oba typy nahoru DBA v systému.
Nyní je tato část opravdu naší ukázkou toho, co můžeme udělat na úrovni databáze. A to, co se stalo, je, že jsme měli zmrazení obrazovky, došlo k výběru z PS_Prod a udělali jsme to, že klikneme na toto tlačítko naladění a co to dělá, je to, že nás přivádí do tohoto pracovního prostoru SQL. Nyní, pro vás lidi, kteří nejsou DBA, to nemusí vypadat opravdu vzrušující. Pro lidi, kteří jsou DBA, možná zjistíte, že je to docela vzrušující. Zde se zobrazovalo trvání tohoto konkrétního příkazu SQL versus změny v systému. A to ukazuje středa, čtvrtek, pátek, doba trvání je asi 2/10 sekundy. Sobota a neděle tato společnost nefunguje - štěstí je. Přijďte v pondělí, došlo ke změně: Přístupový plán se změnil. Nový přístupový plán je zde najednou. To je vlastně dost pomalé, což má za následek zmrazení obrazovky.
Nyní, když jsem DBA, potřebuji další informace, abych poznal pravou příčinu. Potřebuji znát výběr optimalizátoru databází. Takže Precise nabízí toto srovnání, které ukazuje plán provádění, který byl rychlý a efektivní, když se věci vyvíjely skvěle, stejně jako plán provádění, který byl pomalý a neefektivní. Toto připojení filtru je společné pro DBA, které spouští PeopleSoft. Filtr dělá to, že hledá každý řádek v jedné tabulce, dívá se na každý jeden řádek ve spojovací tabulce - to zabírá hodně CPU. Je to extrémně neefektivní, protože neexistuje žádné filtrování jen při pohledu na podmnožinu řádků, které jsou potřeba, ale příkazem SQL a tato neefektivnost vede k pomalejšímu času provádění. Proto nakonec zpomalí panel PeopleSoft při zmrazení obrazovky a program Precise se mohl dostat ke skutečné kořenové příčině, o které byste se nikdy nedozvěděli, pokud nemáte nástroj, který odhalí kód aplikace, příkazy SQL a tak dále.
To byl druh hlubokého ponoru. Nyní se podíváme na dashboardy až na 10 000 čtverečních stop. V rámci přesnosti nejsou dashboardy pro technický tým opravdu - je to opravdu pro vás, abyste sdíleli informace s operacemi, možná s aplikačním týmem, možná s vaší velitelskou sítí. Jedna sada řídicích panelů tedy může zobrazovat panely PeopleSoft a čas klienta, takže víte, co je to zážitek koncového uživatele. Mohl být nakonfigurován další ovládací panel pro operace a tento ovládací panel by se mohl podívat, zda došlo k zmrazení výstrah? Vlastně máme upozornění na úrovni OS, webu, WebLogic, Tuxedo a databáze. Žádná upozornění, průměrná doba odezvy. Vidíte, že běžel asi třetinu sekundy. Zde se ve skutečnosti mohu podívat na svou infrastrukturu, ukážu mi všechny virtuální počítače v mém prostředí a můžu se začít zabývat zpracováním, vyvažováním zátěže a také se mohu dívat na své domény Tuxedo. Toto konkrétní prostředí má šest různých domén, takže tyto domény vidím a ve skutečnosti se mohu dostat do vyvážení webu.
Nyní je v historickém úložišti Precise, že databáze správy výkonu PMDB má spoustu metrik. Někdy se někdo chce dozvědět něco o počtu přístupů do prohlížeče, nebo byste mohli udělat počet přístupů podle typu prohlížeče nebo výkonu podle typu prohlížeče. Existuje celá řada věcí, které lze udělat pro zajištění větší viditelnosti vašeho systému.
Tadyhle se ve skutečnosti díváme na využití paměti WebLogic a vidíte tento pěkný pilový vzor, využití paměti. K dispozici je kolekce odpadků, která získává odkazy. Vrátí se nahoru, takže je to velmi pěkný vzor, který se vám líbí. Jedná se tedy o druh pohledu na prostředí PeopleSoft jako soubor subsystémů, což by bylo vhodné pro provoz. Nejzákladnější otázkou je: „No, co se děje na serveru?“ Přesnost má všechny tyto viditelnosti. Poskytuje také metriky serveru. A tak zde můžete skutečně měřit CPU, paměť, I / O, server, uživatele v systému a máte tak plnou viditelnost. A to je způsob, který - v kombinaci s dlouhodobým trendem - je to, jak lidé používají přesné plánování kapacit.
A já tam jen chci hodit malou notu. Obchod bude mít obvykle tolik rozpočtu na hardware, na server, tolik rozpočtu na zaměstnance. Jak budete investovat, kam budete sázet? Pomocí Precise získáte výhodu, protože vidíte, jak se používá úložný subsystém. Pokud děláte hodně náhodných V / V, Precise vám to ukáže. Pomůže to ospravedlnit investice do polovodičového úložiště. To může být pro váš obchod důležitější než nákup dalšího procesoru, pokud je využití procesoru nízké.
Chcete investovat tam, kde jsou skutečná úzká místa ve zpracování, kde můžete skutečně získat návratnost. A přesným řešením všeho od účinnosti zpracování kódování aplikací až po kapacitu vám umožníme posoudit a dokumentovat, kde jsou tyto potřeby, čísly.
Nyní je poslední položka upozorněna a upozornění je vlastně způsob, jakým se to začalo. Pamatuj si to? Viděli jsme varování, že došlo k výkonu SLA a viděli jsme, že instance WebLogic byla zrušena. Pojďme se tedy podívat na výstražné rozhraní. A ještě jednou, co se děje? Jednou z věcí, na kterou bych chtěl v tomto pohledu poukázat, je, že přesná nejen tato upozornění na výkon a upozornění na stav dostupnosti, jsou také trendová. Důvodem, proč jsou upozornění na trendy důležitá, je to, že pokud je váš systém nečinný nebo má jednoho nebo dva uživatele, pravděpodobně se vše spustí skvěle. Teprve když začnete přidávat uživatele a začnou dělat více a více aktivit, začnete se potýkat s daty, za zdroje na úrovni Tuxedo, na úrovni WebLogic, na úrovni sítě, na úrovni databáze. A toto tvrzení má za následek zhoršení výkonu a nakonec můžete překročit čáru a to je upozornění na výkon, což v podstatě nesplňuje cíle SLA pro organizaci. Tyto sady upozornění jsou tedy velmi pěkné.
Webová vrstva, na levé straně, webová vrstva skutečně měří zážitek koncového uživatele a poté se dostanete do technologií v rámci základního aplikačního zásobníku. Toto je druh naší obrazovky architektury, jak to všechno děláme. V ideálním případě byste chtěli mít přesný server, který je nezávislý na sledovaném prostředí nebo prostředích. Jeden přesný server dokáže zpracovat řadu aplikací.
Pro PeopleSoft a pro databáze Oracle a DB2 vyžadujeme místního agenta. Pokud je vaše prostředí PeopleSoft back-endem SQL Server, existuje možnost provádět agentless. Máme také agenta pro Sybase. Srdcem našeho bezpečnostního modelu je to, že se zde shromažďují data, zatímco uživatelé Precise se autentizují do Precise. Jsou to zcela oddělené procesy, oddělené přihlašovací údaje, samostatné ověřování, a to je součást našeho modelu zabezpečení. A další podrobnosti.
Myslím si, že toto je prozatím dost úvod do architektury. Pokud existují nějaké pálivé otázky, zeptejte se jich, jak Eric zmínil.
Stejně jako rychlá rekapitulace je toto řešení navrženo pro produkci 24 x 7. Je vysoce doporučeno, abyste nás používali v QA. Pokud provádíte vlastní vývoj, začněte nás používat ve vývoji. Chystali jsme se přeložit komplikovanou URL, URI do jména panelu PeopleSoft. Když mluvím o produkci, máme extrémně nízkou režii, takže máte přehled, vždy víte, co se děje, identifikujete koncového uživatele.
Nemusel jsem chodit a definovat tyto transakce - jedná se pouze o přirozené body připojení z prohlížeče, URL, vstupních bodů, připojení webového serveru do WebLogic, pozvání se omezuje na to, které poskytuje příkaz SQL. Potom jsme schopni zachytit příkaz SQL a co dělá. Precizní je inteligentní databáze a myslím si, že to je pro nás rozlišující faktor, který umožňuje vaší DBA spolupracovat a zlepšit viditelnost aplikací.
Konečný bod je ten, že vždy jsme byli, vždy sbíráme, můžete vždy měřit před a po a kvantifikovat vylepšení nebo, ve výjimečném případě jste možná změnili výkon, byste to věděli a mohli byste jej okamžitě vrátit zpět . Většina našich konkurentů, to, co dělají, je, pokud potřebujete vidět další informace, musíte zapnout další viditelnost a obvykle to další viditelnost vyžaduje mnoho režijních nákladů.S přesností máte vždy přehled a můžete problém vždy vyřešit. Pokud se chystáte přejít na web Precise, zkontrolujte prosím některý z produktů Precise, zda jde o produkt Precise for Oracle. Jsme na seznamu jako Precise Application Performance Platform a je zde tlačítko pro vyžádání ukázky.
Vlastně, pokud sdílím svou obrazovku, myslím, že bych tam mohl jen navigovat, abych vám ukázal, jak to vypadá, abyste to viděli hned na začátku. Zde je web IDERA. Jdete na produkty. Mohu si vybrat kteroukoli z těchto přesných součástí a chci ji vidět pouze v akci. Tím se zahájí náš proces sdílení dalších informací, které mohou být pro váš web důležité. Nebo pokud se chcete dozvědět více o přechodu na tekuté uživatelské rozhraní, můžete nás kontaktovat.
A které, Eric, Id, rád předá obušek zpět tobě.
Eric Kavanagh: Dobře, hodně. Musím ještě jednou říci - poměrně komplexní a působivá prezentace, Bille. Zmínil jsi celou spoustu věcí, na které se Id rád zeptá. Nemáme moc času - asi devět minut - a jako Matt máme šanci položit pár otázek a mít alespoň jednu nebo dvě posluchače.
Ale zmínili jste něco, co jsem si myslel, že to bylo velmi, velmi zajímavé s ohledem na to, jak může Precise pomoci při zadávání zakázek pro tým IT, protože můžete poukázat na to, že každému, kdo učiní toto rozhodnutí, můžete učinit případ, že to, co potřebujete, je solidnější stát. například úložiště nebo to, co potřebujete, je vylepšení sítě nebo cokoli jiného. Ale to je hodně. Vidíte společnosti často to uznávat a používat to, nebo se to snažíte evangelizovat ještě víc?
Bill Ellis: Vlastně obojí a věc je taková, že vzorce použití, a to i pro aplikaci balíčku, jako je PeopleSoft, jsou vzory použití na každém webu odlišné. Měl jsem štěstí, že jsem provedl migraci PeopleSoft v bance a banky používají systém hlavní knihy velmi odlišně než většina organizací. Ve skutečnosti byste mohli mít individuální transakce, které byly provedeny v pobočce, všechny zaúčtují do hlavní knihy.
A místo toho, abyste zveřejňovali desítky nebo stovky obecných účetních knih, vlastně účtujete stovky tisíc. A tak jsem se do programu Precise zapojil díky způsobům použití a umožnil nám to řešit, ale potřeby aplikace jak na úrovni kódu, konfigurace, tak i na úrovni infrastruktury. Takže absolutně jsem velký věřící a já to chci evangelizovat, protože byste neměli dělat hardwarová rozhodnutí jednoduše na základě využití. Měli byste to založit na potřebách vašeho prostředí.
Eric Kavanagh: A je tu otázka od účastníka a potom, Matte, předám ti to na otázku nebo dvě. No, to je dobrý a to je vtipné, protože je to velká, dlouhá odpověď, kterou byste mohli dát. Účastník se zeptá: „Jak shromažďujete metriku výkonu na konci uživatele po nasazení a během testování?“
Myslím, že jste odvedli docela dobrou práci, když jste se ponořili do toho, jak hluboké a bohaté jsou tyto metriky výkonu. O některých z těchto věcí jste hovořili dokonce o vteřině v porovnání s každých pět minut nebo 10 minut. To je, když se dostanete na úroveň detailů nezbytných k nalezení vašich odpovědí, že?
Účtovat Ellis: Jo, takže zásadní věcí je, že jednotliví sběratelé informací o výkonu jsou založeni na technologii. Když tedy provádíme nasazení, potřebujeme vědět, jak se sestavuje váš aplikační zásobník, počínaje operačním systémem, jeho verzí, jakou verzí Tuxedo, WebLogic, jakou verzí nástrojů People, které používáte.
A je to opravdu design těch agentů, kteří to dělají, sběr dat, který nám umožňuje odhalit, že úroveň viditelnosti poskytuje přesnost. A ta viditelnost, myslím, někdy může být pro lidi trochu zastrašující. Ale pokud je vaším cílem opravdu vstoupit a zlepšit věci a dosáhnout výkonu na 11, je to skutečně úroveň viditelnosti, kterou byste chtěli mít. A pokud to dokáže přesnost a její nízká režie, je otázkou, proč ne? Takže si myslím, že je to skvělá otázka, a pokud byste o tom chtěli dále diskutovat, kontaktujte nás.
Eric Kavanagh: OK dobře. A Matte, měl jsi nějaké otázky?
Matt Sarrel: Myslím, že jsem v pořádku. Chci říct, že jsem se tady vypořádal s pádem WebExu.
Eric Kavanagh: Ach ne. Potřebujeme přesné, abychom přesně pochopili proč.
Matt Sarrel: Jo, myslím, že otázka, o které jsem přemýšlel, když jsi mluvil, Bille, byla, kdybys mohl diskutovat o tom, jak se více týmů může dostat na stejnou stránku při řešení problémů s výkonem, protože vím, že to je něco, co se objeví a znovu je to, kdo je zodpovědný za to, co a jak mohou všichni spolupracovat, aby zaměstnancům poskytovali nejlepší kvalitu.
Účtovat Ellis: Ano, personál IT bývá tedy drahý. Ve většině obchodů jste vzhledem ke složitosti technologie rozděleni do týmů založených na technologii. Jednou z velkých věcí, která se stane, je problém s výkonem a mnohokrát konflikt, svolává válečná místnost. A to je místo, kde každý má metriku, aby nějak osvobodil svou úroveň, protože nemají konv. Sledují spíše to, co se děje na úrovni WebLogic, než co se děje na úrovni transakčního kódu. Nebo se dívají spíše na databázovou úroveň než na jednotlivý příkaz SQL transakce.
A tím, že dokáže určit problémovou úroveň a kód problému v rámci této úrovně, uvolňuje to ostatním týmům, aby nechodili nebo trávili čas zdroji hledáním problému, který není v jejich oblasti. Pokud jde o problém s databází, vydejte se do databáze DBA s informacemi, které potřebují k vyřešení problému. Budou rádi, když to udělají.
Ale také neztrácejte Tuxedo, tým podpory WebLogic se zaměřením na problémy v databázi. Podobně, pokud se problém stane v konfiguraci WebLogic, nenechte si čas DBA v nějakém válečném pokoji pokusit se bránit. Stačí jít a opravit problém ve WebLogic.
Zjistili jsme, že IT pracovníci oceňují preciznost kvůli časové úspoře, protože obvykle tyto válečné místnosti nejsou zahrnuty do časového plánu pro každou organizaci FTE. Je to jako další čas. A proto, abychom byli schopni tyto problémy řešit efektivněji, je skutečně nezbytné. A pro organizaci, která zaváděla tekuté uživatelské rozhraní, byla schopnost škálovat výrobu a řešit problémy, se kterými se ve výrobě skutečně potýkají, byla opravdu životně důležitá nejen pro jednotlivé zaměstnance nebo týmy, ale ve skutečnosti pro správu IT celkově, protože by to byla opravdu špatná zpráva kdyby se museli vrátit. Skvělá otázka, protože to není jen technologie. Je to opravdu vždy o lidech.
Matt Sarrel: Správně, jsou to lidé a procesy. Jo, to byla jediná otázka, která se mi při demonstraci objevila. Pokud existují další publikum?
Eric Kavanagh: Jo, jen na tebe hodím poslední, Bill a Matt o tom stručně hovořil ve své prezentaci. Začali jsme vidět tuto plodinu. Je to stále velmi prozíravé, ale kontejnery a použití kontejnerizace a Dockera a věcí té povahy, jak velká je curveball, která vás to hodí?
Bill Ellis: Slovo znamená různé věci v závislosti na různých technologiích. Naše produkty vyvíjíme proto, abychom se starali o kontejnery na úrovni databáze a na úrovni aplikací. A jako součást toho je to celé prostředí s pohybem, mrakem a my pracujeme v oblaku. Existuje však proces zjišťování a v závislosti na tom, jak se tyto aplikace - včetně PeopleSoft - vyvíjejí, vyvíjíme naše monitorovací řešení, abychom mohli poskytnout úroveň hloubky, která byla v minulosti tak cenná.
Eric Kavanagh: To jo. A musím říct, že pokaždé, když vidím tato dema, jsem ohromen granularitou, kterou máte, a to je to, co potřebujete, abyste mohli dokopy porozumět, a musíte mít nějaké vzdělání o tom, jaká je normální situace, co je Standard.
A vy kolem toho nabízíte spoustu obsahu - pomáhat lidem zjistit, co je normální, co není normální. Hovořili jste například o trendových výstrahách, to jsou všechny mechanismy, které můžete použít k lepšímu porozumění, je něco špatného, není něco špatného, a pak se odtamtud samozřejmě musíte podrobit, abyste je našli, ale máte všechna data.
Bill Ellis: Jo, a to je opravdu důležitá věc; Myslím, že o tom Matt mluvil. Co je normální? Různá prostředí mají jinou normální úroveň. Pokud běžíte s hardwarem špičkové úrovně, logikou Oracle a daty, bude to, co je v obchodě normální, nebo co je v obchodě dosažitelné, jiné, než kdybyste provozovali méně výkonnou infrastrukturu. První věcí je tedy zjistit, co je normální, začít vypočítávat tuto základní linii a odtud můžete začít provádět vylepšení.
Eric Kavanagh: Dobře, to je dobré. Vypadá to, že máme ještě jednu poslední otázku. Ještě jednu poslední otázku, kterou ti dám, Bille. Jaký je rozdíl mezi sledováním výkonu SQL a databází z hlediska údajů na úrovni systému a aplikací? Jaký je rozdíl mezi sledováním výkonu SQL a databází z vašeho pohledu?
Účtovat Ellis: V databázi se nic neděje, dokud se nespustí příkaz SQL. Konflikt příkazu SQL je co - řízení zamykání, čekání, soupeření o prostředky na úrovni dat a na úrovni serveru SQL. A pokud tedy dokážu vidět jak ovladač příkazu SQL, tak jeho dopad na systém, způsobil jsem účinek; Dokážu propojit, o co se aplikace DBA stará, s čím se stará infrastruktura DBA, dokud nebudu moci z nástroje Precise opravdu získat maximum.
Pokud jsem infrastruktura DBA a dívám se na věci, jako je využití, jsem opravdu druh řízení pomocí širokého štětce versus, pokud se mohu podívat na jednotlivé příkazy SQL a dokážu skutečně minimalizovat zdroje spotřeba - ať už je to procesor, paměť, V / V - jsem schopen oslovit obě strany téže mince.
Eric Kavanagh: Dobře, lidi. Spalovali jsme něco přes hodinu. Velké, velké díky našim přátelům na IDERA. Velké poděkování Mattovi Sarrelovi, že jste se k nám dnes připojili. Veškerá tato webová vysílání archivujeme pro pozdější prohlížení, takže neváhejte a vraťte se zpět. Obvykle za pár hodin archiv pokračuje. Takže to zkontrolujte a vše, co musím říct, je to, že miluji tyto věci, miluji přesné, miluji možnost proniknout do plevelů. A já nevím, žádný jiný nástroj, který vám umožní kopat do všech těch různých kusů a částí aplikačního zásobníku, než to, co tito lidé mají v IDERA s Precise.
S tím vám nabízíme rozloučení, lidi. Ještě jednou díky, promluvíme si s tebou příště.