Od zaměstnanců Techopedia, 2. listopadu 2016
Take away : Host Eric Kavanagh diskutuje o výkonu aplikací a o tom, jak zlepšit efektivitu s Dr. Robinem Bloorem, Dezem Blanchfieldem a Billem Ellisem IDERA.
Momentálně nejste přihlášeni. Chcete-li zobrazit video, přihlaste se nebo se zaregistrujte.
Eric Kavanagh: Dámy a pánové, ahoj a vítejte zpět v Hot Technologies. Ano vskutku! Jmenuji se Eric Kavanagh, dnes budu vaším hostitelem pro další webové vysílání v této opravdu zábavné a vzrušující sérii, kterou máme jako kompliment naší série Briefing Room. Název je „Akcelerace aplikací: rychlejší výkon pro koncové uživatele.“ No tak lidi, kdo to nechce? Pokud jsem tam venku a pomáhám vám, aby vaše aplikace běžela rychleji, myslím, že jsem ten chlap, který pro mě po práci kupuje piva v baru. Musí to být docela cool věc, do které se vcházíme a urychlíme něčí aplikaci.
Je tu snímek o vás, zasáhněte mě na Twitteru @ Eric_Kavanagh. Vždy se snažím sledovat zpět a vždy opakuji pípání, pokud mě zmiňuješ, tak mě klidně zmiň.
Celým účelem této show je zaměřit se na různé aspekty podnikové technologie a opravdu pomoci definovat určité disciplíny nebo určité tváře, pokud budete chtít. Prodejci mnohokrát vyzvednou určité marketingové podmínky a budou hovořit o tom, jak to či ono či o něčem jiném dělají. Tato show byla navržena tak, aby pomohla našemu publiku pochopit, co softwarový nástroj musí mít, aby byl lídrem ve svém prostoru. Formátem jsou dva analytici. Každý jde první, na rozdíl od Briefing Room, kde je prodejce na prvním místě. Každý z nich přijme to, co považuje za důležité, abyste věděli o konkrétním druhu technologie.
Dnes mluvíme o akceleraci aplikací. Budeme slyšet od Dez Blanchfielda a také doktora Robina Bloora - dnes jsme na celém světě - a potom se Bill Ellis vytočí z větší oblasti Virginie. S tím to předám našemu prvnímu moderátorovi, Dr. Bloorovi. Mimochodem jsme tweetovali hashtag #podcast, takže neváhejte a tweetujte. Vzít to pryč.
Dr. Robin Bloor: Dobře, díky za úvod. Výkon aplikací a úrovně služeb - to je druh oblasti, v této oblasti jsem za ta léta odvedl spoustu práce, ve smyslu, že jsem vlastně odvedl spoustu práce při sledování výkonu a zpracování v jednom tak či onak, jak se pokusit vypočítat tyto úrovně. Je třeba říci, že dokud - dříve jsme měli tuto éru, kdy lidé stavěli systémy v silech. V zásadě množství práce, kterou skutečně musí udělat, aby systém fungoval přiměřeně dobře, kdyby to bylo v sila, nebylo ve skutečnosti příliš těžké, protože existuje velmi malé, velmi malé množství proměnných, které musíte vzít v úvahu. Jakmile jsme se dostali správně do sítě, do rovnice vstoupila interaktivní a servisní orientace. Bylo to trochu obtížné. Výkon může být jednorozměrný. Pokud si jen vzpomenete na aplikaci, která opakovaně provádí určitou cestu kódu, dělá to rozumně a včas, je to jako jednorozměrná věc. Jakmile začnete hovořit o úrovních služeb, mluvíte vlastně o několika věcech o počítačové zdroje. Velmi rychle se stává vícerozměrným. Pokud začnete hovořit o obchodních procesech, mohou být obchodní procesy spojovány dohromady z více aplikací. Pokud mluvíte o architektuře orientované na služby, pak daná aplikace může ve skutečnosti přistupovat ke schopnostem více aplikací. Pak se to stane velmi komplikovanou věcí.
Podíval jsem se - dávno jsem nakreslil tento diagram. Tento diagram má nejméně 20 let. V zásadě to nazývám Diagramem všeho, protože je to způsob, jak se podívat na všechno, co v IT prostředí existuje. Je to opravdu jen čtyři kusy: uživatelé, data, software a hardware. Samozřejmě se v průběhu času mění, ale ve skutečnosti si uvědomíte, když se podíváte na to, že v každém z těchto kusů existuje hierarchická exploze. Hardware ano, hardware může být server, ale server se může skládat z možná více procesorů, síťové technologie a paměti, a to jakousi hroznou spousty řadičů, jak se to stane. Pokud se na to skutečně podíváte, vše se rozpadne na kousky. Pokud skutečně přemýšlíte o pokusu o to vše zorganizovat, pokud jde o data, která se mění, mění se výkonnost softwaru, protože se mění hardware, atd. A tak dále, ve skutečnosti se díváte na neuvěřitelně obtížnou situaci s různými variantami. Toto je křivka složitosti. Samozřejmě je to křivka složitosti téměř pro všechno, ale viděl jsem ji znovu a znovu, když mluvím o počítačích. V zásadě pokud umístíte uzly na jednu osu a důležitá spojení na druhou osu, skončí se křivka složitosti. Skoro nezáleží na tom, jaké uzly a připojení jsou, a to bude dělat, pokud chcete reprezentovat nárůst objemu v telefonní síti.
Ve skutečnosti, když mluvíte o uzlech v počítačovém prostředí, mluvíte o jednotlivých věcech, které se o sebe starají. Ukázalo se, že složitost je věcí rozmanitosti a různých omezení, která se snažíte dodržovat. Také čísla. Když čísla stoupají, zblázní se. Včera jsem měl zajímavý chat, mluvil jsem s někým - nemůžu zmínit, kdo to je, ale na tom vlastně nezáleží - mluvili o webu, který měl 40 000 - to jsou čtyři nuly, 40 000 - instance databází na webu. Jen o tom přemýšlejte - 40 000 různých databází. Samozřejmě jediné, co jsme měli - měli samozřejmě mnoho, mnoho tisíc aplikací. Mluvíme o velmi velké organizaci, ale nemohu ji pojmenovat. Ve skutečnosti se na to díváte a ve skutečnosti se snažíte tak či onak získat úroveň služeb, která bude pro některé více uživatelů přiměřeně přeshraniční, s několika různými, pokud chcete, očekáváními. Je to složitá situace a vše, co opravdu říkám, je, že je to složité. Čísla se vždy zvyšují. Omezení jsou určena obchodními procesy a obchodními cíli. Všimli jste si, že se očekávání změnily.
Pamatuji si, jakmile Gmail, Yahoo mail a Hotmail, všechny tyto poštovní systémy přišly, lidé začali mít očekávání, že jejich interní poštovní systémy v rámci organizace by si zasloužily úroveň služeb těchto obrovských operací s rozsáhlými serverovými farmami venku organizace a začal být pod tlakem, aby se všechno podobné stalo. Dohody o úrovni služeb jsou ve skutečnosti jedna věc, ale očekávání jsou další věc a bojují proti sobě v rámci organizace, trapná věc. Tady je jen obchodní perspektiva. V některých systémech je optimální doba odezvy jedna desetina sekundy lidské doby odezvy. Jedna desetina vteřiny je doba, po kterou vás kousne kobra. Pokud stojíte před kobrou a rozhodnete se kousnout vás, je příliš pozdě, bude to proto, že nemůžete odpovědět za desetinu sekundy. Jedna desetina sekundy je o čase, kdy míč opustí ruku džbánu, aby dosáhl chlapa s pálkou. V podstatě, když vidí, jak se míč hází, musí reagovat přesně v tom okamžiku. Lidská odpověď, něco zajímavého. Software-to-software, může samozřejmě mít vyšší očekávání.
Pak se dostanete do některých situací, o kterých si myslím, že jsou ty situace na trhu, kde je první, kde je obchodní hodnota. To je, jako kdybyste chtěli prodat konkrétní akci na akciovém trhu je pravděpodobně méně, například proto, že si myslíte, že to klesá a mnoho dalších lidí si myslí, že to klesá, dostanete nejlepší cenu, pokud se dostanete na trh první. Existuje mnoho situací, zobrazování reklam a podobné věci, velmi podobná situace. Tento pohyb máte, pokud jde o očekávání na úrovni služeb. Máte jednu věc, která je druh skleněného stropu pro lidskou reakci. Jakmile se jedná o software na software, pokud máte tuto stropní situaci, pak neexistuje žádná nejlepší úroveň služeb. Rychlejší než všichni ostatní je nejlepší.
Dobře, myslím, že je to poslední snímek, který jsem dělal, ale je to jen proto, abych vám poskytl obrázek o složitosti, jakmile se skutečně podíváte na požadavky organizace, na službu. Máte tu, po levém boku, máte správu systému, což je sada softwaru, který slouží k řízení služeb, který se snaží spravovat úroveň služeb. Nad tím máte řízení obchodní výkonnosti. Pak, když se podíváte dolů, tady, v oblasti automatizace správy služeb, máte roztříštěné služby, které se vyvinou ve standardizované služby, pokud skutečně chcete investovat do tohoto druhu, který se vyvine v integrované služby, které se vyvinou v optimalizované služby. . Většinou to, co lidé udělali, je pouze v levém dolním rohu. Možná trochu správy služeb. Řízení obchodní výkonnosti, velmi vzácné. Fragmentovaný, téměř všechno. Tuto mřížku naplnil dokonalý svět. Instrumentace - zmínila jsem se o problému sub-optimalizace. Můžete optimalizovat části systému a není to dobré pro celý systém. Pokud uděláte srdce optimální, může vám krev krve po zbytek orgánů příliš rychle. To je problém s velkými organizacemi a úrovněmi služeb. Bez sofistikovaných nástrojů se zjevně nedosáhne, protože proměnné se právě dostaly - dobře existuje příliš mnoho proměnných, které by bylo možné zkusit a optimalizovat.
Poté, co to řeknu, předám Dezovi, který bude mluvit o něčem jiném, doufejme, že.
Dez Blanchfield: Děkuji, Robine. Stejně jako Dr. Robin Bloor jsem strávil příliš mnoho let přemýšlením o výkonu velmi složitých systémů ve velkém měřítku. Pravděpodobně ne úplně stejné měřítko jako Robin, ale výkon je každodenním tématem a je součástí naší DNA, aby chtěl výkon, abychom ze všeho dostali to nejlepší. Ve skutečnosti jsem použil grafiku jedné z mých nejoblíbenějších věcí na světě, automobilových závodů Formule I, kde celá planeta ještě chvíli sedí a sleduje, jak auta rychle obcházejí kola. Každý jednotlivý aspekt, neexistuje žádný aspekt Formule I, který není konkrétně o získávání výkonu. Mnoho lidí poo-poo sport, protože si myslí, že je to ztráta peněz. Ukázalo se, že auto, které jezdíme každý den, o víkendech a ve škole děti ve fotbale, je odvozeno z vývoje a výzkumu založeného na výkonu. Je to druh života automobilových závodů Formule I. Každodenní technologie, každodenní věda, často pochází z něčeho, co bylo zaměřeno čistě na vysoký výkon.
Realita je však taková, že náš nový „vždy na“ svět, který vyžaduje 100 procent uptime - jak Robin zmínil dříve - s věcmi, jako je zavedení webmailu a dalších služeb, které považujeme za samozřejmost v nepřetržitém prostoru, a nyní očekáváme, že v naše podnikové a pracovní prostředí. Realita je taková, že být nahoru neznamená vždy, že splňujete dohodu o úrovni služeb. Mám za to, že je třeba spravovat výkon aplikací a dostupnost dohod o úrovni služeb prošlo v posledním desetiletí zásadním posunem. Už se nesnažíme jen starat o výkon jednoho systému. Když byl svět o něco jednodušší, mohlo by dojít k situaci, kdy jediný server, na kterém běží více služeb, bude možné sledovat živě a podpora byla relativně jednoduchá. Mohli bychom - a tady je moje maličko, věci, které jsme si dělali starosti, když jsem byl například systémovým administrátorem, například před mnoha lety - bychom se rozhlíželi kolem, je služba obvykle v provozu a reaguje? Mohu se například přihlásit do terminálu? Odpovídá operační systém a mohu napsat příkazy? Jsou aplikace spuštěny? Mohu vidět procesy a paměť při dělání věcí a I / O po síti atd.? V dobách sálových počítačů jste slyšeli, jak se pásky rozeznávají na zip-zip a vypadává papír.
Odpovídají aplikace a můžeme se k nim přihlásit a dělat na nich věci? Jsou uživatelé schopni připojit se k některým z těchto serverů? Pokračuje to. Jsou docela základní, víte. Pak pár zábavných - je help desk zelená? Protože pokud ne, pak všechno běží dobře a kdo dostane koblihy? Život byl v těchto dnech opravdu jednoduchý. Dokonce i v těch dnech, a pak mluvím s 20–30 lety, byla složitost stále opravdu vysoká. Mohli bychom relativně jednoduchým způsobem spravovat dohody na úrovni služeb a sledovat výkon. Už to nemůžeme dělat ručně, jak to Robin naznačil. Výzva je příliš velká. Faktem je, že několik dobrých aplikací, administrátorů, systémové sítě a databáze, administrátoři mohou monitorovat a plnit SLA výkonu. SLA jsou tak daleko pryč, že jsem včera v noci bojoval, když jsem dával své poslední poznámky dohromady, abych si vzpomněl na rok, kdy jsem se naposledy dokázal podívat na systém velmi složitého zásobníku, abych to pochopil a dokonce pochopil, co bylo děje pod kapotou a já pocházím z hluboce technického zázemí. Nedokážu si představit, jaké to je každodenně čelit administrativě.
Co se stalo? V roce 1996 byly aplikace založené na databázi transformovány internetovým rozmachem. Mnoho z nás to prošlo. I když jste nebyli kolem internetového rozmachu, můžete se jednoduše jen rozhlédnout a uvědomit si, že v každodenním životě, že teď všechno připojujeme k internetu. Věřím, že máme topinkovač, který zjevně přichází s možností připojení k Wi-Fi, což je směšné, protože nepotřebuji svůj topinkovač připojený k internetu. V roce 2000, zejména na začátku roku 2000, jsme se museli vypořádat s tímto masivním nárůstem složitosti a poskytovat výkonnost služeb v boomu dot-com. Pak další směšná nepříjemná jiskra na webu 2.0, kde se objevily chytré telefony a nyní byly aplikace v našich rukou 24/7 a byly vždy v zapnutém režimu.
Nyní je rok 2016, čelíme dalšímu quagmiru v podobě cloudu a velkých dat a mobility. Jedná se o systémy, které jsou tak velké, že je často obtížné porozumět a dát je do prosté angličtiny. Když přemýšlíme o skutečnosti, že některé z velkých jednorožců, o kterých mluvíme, mají desítky stovek petabajtů dat. Toto je celé patro místa na disku a úložiště jen pro uložení vašich e-mailů, obrázků a sociálních médií. Nebo v některých případech, v přepravní a přepravní logistice, je to všechno v bankovnictví, je to tam, kde jsou vaše peníze, kde je váš příspěvek nebo kde je to, co jste si na eBay zakoupili. Další velká vlna, které se chystáme čelit, je tato velmi těžká výzva internetu věcí.
Pokud to nebylo dost špatné, chystáme se zabudovat umělou inteligenci a kognitivní výpočetní techniku do téměř všeho. Dnes mluvíme se stroji Siri a Google. Vím, že Amazon má jeden ze svých. Baidu mají jedno z těchto zařízení, se kterými můžete mluvit, převádějí jej na text, který jde do normálního systému, databáze vytvoří dotaz a vrátí se a obrátí proces. Přemýšlejte o složitosti, která s tím souvisí. Skutečností je, že složitost dnešního standardního aplikačního zásobníku je daleko za lidskými schopnostmi. Když přemýšlíte o všem, co se stane, když stisknete tlačítko na vašem smartphonu nebo tabletu, promluvíte s ním, převedete to na text, spustí to až k internetu na back-end systém, front-end obdrží to převede na dotaz, spustí dotaz pomocí zásobníku aplikací, prochází databází, zasáhne disk, vrátí se a uprostřed je síť dopravce, kde je centrum stavu místní sítě. Složitost je šílená.
Efektivně to uplatňujeme jako hyperscale. Složitost a rychlost hyperscale je jen zalévání očí. Aplikace a databáze se staly tak rozsáhlé a složité, že řízení výkonu je ve skutečnosti věda sama o sobě. Mnozí to označují jako raketovou vědu. Máme technologii na místě, máme technologii na místě, máme řadu možností datových center; fyzický a virtuální. Máme fyzické a virtuální servery, máme cloud, máme infrastrukturu jako službu a platformu, protože služba a software jako služba je věc, kterou nyní považujeme za samozřejmost. Ten, software jako služba, se před několika lety stal děsivým, když si finanční ředitelé a části organizace uvědomili, že si mohou vyzvednout svou kreditní kartu a koupit si věci sami a jít kolem CIO a efektivně jsme to nazvali „stínem“ IT “a CIO se nyní snaží navinout zpět a ovládat zpět kontrolu.
V infrastruktuře máme softwarově definované sítě, virtualizaci síťových funkcí, pod kterou máme, pravděpodobně více, nyní máme mikro služby a aplikace aktivních služeb. Když kliknete na adresu URL, na konci této adresy URL je spousta obchodní logiky, která popisuje, co ji skutečně potřebuje. Nemusí to nutně mít předem vytvořenou logiku, která na ni čeká. Na jedné straně máme tradiční databáze, které jsou velmi, velmi velké. Máme podobnou infrastrukturu a ekosystémy Hadoop v jiném spektru, které je tak velké, že, jak jsem řekl, víte, lidé teď mluví o stovkách petabajtů dat. Máme mobilitu složitosti, pokud jde o zařízení, která přenášejí, notebooky a telefony a tablety.
Máme BYOD v některých uzavřených prostředích a stále více, protože lidé zkušení v Gen Y přinášejí svá vlastní zařízení. Prostě jsme je nechali mluvit o webových rozhraních. Buď přes internet, nebo přes Wi-Fi, máme v kavárně dole, když mají kávu, bezplatné Wi-Fi. Nebo naše interní Wi-Fi. Stroj-to-machine je nyní stále přítomen. To není přímo součástí internetu věcí, ale také s tím souvisí. Internet věcí je zcela nová hra složitosti, která je ohromující. Umělá inteligence, a pokud si myslíte, že to, s čím teď hrajeme, se všemi Siri a dalšími souvisejícími zařízeními, se kterými mluvíme, je složité, počkejte, až se dostanete do situace, kdy uvidíte něco zvaného Olli, což je 3D-D tištěný autobus, který pojme asi šest lidí a může se sám projet městem a můžete s ním mluvit prostou angličtinou, a bude to s vámi mluvit zpět. Pokud zasáhne provoz, rozhodne se odbočit doleva nebo doprava z hlavní oblasti, kde je provoz. Když se to otočí a vy si děláte starosti, proč je odbočeno vlevo nebo vpravo od hlavní silnice, řekne vám: „Neboj se, chystám se odbočit doleva. Před námi je provoz a já to budu obcházet. “
Řízení výkonu všech systémů tam a veškerá složitost, sledování, kam tato data směřují, ať už jde do databáze, všech propojení a všech příslušných bitů, je pouhou záhadou. Realita je taková, že správa výkonu a SLA při dnešní rychlosti a měřítku vyžaduje nástroje a systémy, a ve výchozím nastavení už to není něco, co byste si mysleli, že by bylo hezké mít nástroj - je to předpoklad; je to naprosto nezbytné. Tady je něco jako malý příklad, seznam diagramů návrhů aplikací na vysoké úrovni pro cloud s otevřeným zdrojovým kódem OpenStack. Je to jen velký kus. Nejde jen o servery a databázi. To je místo, kde každá malá modrá skvrna představuje shluky věcí. V některých případech běží logika souborů a serverů nebo stovek databází nebo samozřejmě ne více než desítky tisíc malých kousků aplikací. To je malá verze. Je to opravdu docela ohromující, když začnete přemýšlet o složitosti, která se v tom objevuje. Dnes, dokonce i ve velkém datovém prostoru, vložím jen screenshoty jen značek. Když přemýšlíte o všech kusech, které tady máme spravovat, nemluvíme jen o jedné značce, jedná se o značky v oblasti velkých dat a o nejlepší značce, nejen o každé malé malé velikosti nebo open source. Vypadáte a myslíte si, že je to docela ohromující graf.
Pojďme se podívat na pár vertikál. Vezměme si například marketing. Tady je podobný graf, ale z technologických balíčků, které jsou dostupné pouze v marketingové technologii. Toto je graf 2011. Zde je verze 2016. Jen přemýšlejte o tom, je to jen počet značek produktů, které můžete provozovat pro technologii s ohledem na marketingové technologie. Ne složitost systémů uvnitř, nikoliv odlišná aplikace a web a vývoj a síť a všechny ostatní. Jen značka. Jsou před, před pěti lety a tady je dnes. Jen se to zhorší. Nyní jsme v místě, kde je realita, lidé prostě nemohou zajistit všechny dohody na úrovni služeb. Nemůžeme se ponořit do dostatečných detailů, dostatečně rychle a v míře, kterou potřebujeme. Zde je příklad, jak nyní monitorovací konzole vypadá. Je to jako téměř dvacet lichých obrazovek slepených dohromady a předstírá, že jsou jedna velká, velká promítaná obrazovka monitorující každý malý kousek. Teď je to tady zajímavé, nezmíním se o značce, ale tato monitorovací platforma monitoruje jednu aplikaci v logistickém a přepravním prostředí. Pouze jedna aplikace. Pokud přemýšlíte o tom, o čem Robin mluvil, kde organizace nyní mohou mít v produkčním prostředí 40 000 databází. Dokážete si jen představit, jaké by mohlo být 40 000 verzí této kolekce obrazovek monitorujících jednu aplikaci? Je to velmi odvážný svět, ve kterém žijeme. Jak řekl Robin a já absolutně, stoprocentně zazvoní, že bez správných nástrojů, bez správné podpory a lidu na stole pomocí těchto nástrojů je výkon aplikací pro lidi ztracenou hrou a musí to být provedeno pomocí nástrojů a softwaru.
S tím přejdu k našim přátelům v IDERA.
Eric Kavanagh: Dobře, Bille.
Bill Ellis: Děkuji. Zde sdílím svou obrazovku. Myslím, že někdo může potvrdit, že vidíte moji obrazovku?
Dr. Robin Bloor: Jo.
Eric Kavanagh: Vypadá dobře.
Bill Ellis: Děkuji. Jedinou věcí, na kterou se zmínil, bylo, že na ni nemůžu čekat, bylo auto s vlastním pohonem. Jediná věc, o které jsem nikoho neslyšel, je, co se stane, když sněží? Zajímalo by mě, jestli si inženýři v Kalifornii uvědomili, že v jiných částech země trochu sněží.
Dez Blanchfield: To se mi líbí, budu si to pamatovat.
Eric Kavanagh: Typická míle za hodinu.
Bill Ellis: Jsme tu, abychom hovořili o řízení výkonu aplikací ve složitém prostředí. Jedna věc, o které rád mluvím, je, že mnoho lidí, když mluví o výkonu, povaha reakce je, hej více serverů, více CPU, více paměti atd. Druhou stranou této mince je efektivita zpracování. Opravdu, to jsou dvě strany téže mince a my se na ně oba podíváme. Konečným cílem je splnit dohody o úrovni služeb pro obchodní transakce. Nakonec všechny tyto technologie existují pro podnikání. Mluvili jsme o tom, že budeme mít první databázi správy výkonu v oboru. Ideální je zapadnout do ideální formy výkonu a řídit ji od začátku životního cyklu aplikací.
Témata se skutečně scvrknou na čtyři kusy; jeden je proces řízení výkonu. Mluvili jsme se všemi a každý má nástroje. Pokud nemají nástroje, mají skripty nebo příkazy, ale chybí jim kontext. Kontext jednoduše spojuje tečky přes hromádky aplikací. Tyto aplikace pro - jsou založeny na prohlížeči. Jsou velmi pevně spojeny z úrovně na úroveň. Interakce úrovní je také zásadní. Poté mluvíme o obchodní transakci. Zajistíme viditelnost nejen pro technické pracovníky, ale také pro vlastníky aplikací a provozní manažery.
Mám pár případových studií, abych se s vámi jen podělil o to, jak je zákazníci použili. Toto je velmi praktická část prezentace zde. Pojďme se podívat na to, co se obvykle děje. Líbí se mi diagram - bylo to jako neuvěřitelná koláž technologií. Počet technologií v datovém centru právě rostl, rostl a rostl. Mezitím se o to koncový uživatel nestará a je mu nevšímavý. Chtějí pouze provést transakci, mít ji k dispozici, nechat ji rychle dokončit. Obvykle se stává, že odborníci v oblasti IT nevědí, že koncoví uživatelé dokonce měli problém, dokud se sami nepřihlásí. To odstartuje druh časově náročného, pomalého procesu a často frustrujícího. Stane se to, že lidé otevřou své nástroje a podívají se na podmnožinu svého aplikačního zásobníku. S touto podmnožinou je velmi obtížné odpovědět na nejjednodušší otázku. Je pro vás obvyklé mít problém? Co je to za transakci? Kde v zásobníku aplikací je úzký profil? Tím, že trávíte celou tu dobu, díváte se na úroveň po vrstvě a nejste schopni na tyto otázky odpovídat, nakonec utratíte spoustu času a energie, spoustu personálu, finančních prostředků a energetického druhu.
Abychom to vyřešili, abychom zajistili lepší způsob, co přesně dělá, je ve skutečnosti provést transakci sledování koncového uživatele, zachytí o tom metadata, sleduje transakci přes síť, do webového serveru, do obchodní logické úrovně a Podporujeme .NET a ABAP a PeopleCode a E-Business Suite ve vícevrstvých aplikacích, které nakonec všechny transakce budou interagovat se systémem záznamu. Ať už se jedná o vyhledávání zásob, odpracovaný čas hlášení, vždy s databází interagují. Databáze se stává základem obchodního výkonu. Databáze se zase opírá o úložiště. Jaká metadata o transakcích odpovídají, kdo, jaká transakce, kde v zásobníku aplikací, a pak máme hlubokou viditelnost na úrovni kódu, abychom vám ukázali, co se provádí. Tyto informace jsou zaznamenávány nepřetržitě, ukládány do databáze správy výkonu - to se stává jediným hudebním listem pro každého, aby viděli, co se děje. Existují různí lidé a organizace, které se zajímají o to, co se děje: techničtí odborníci, vlastníci aplikací, nakonec samotný podnik. Když se objeví problém, chcete mít možnost získat informace o této transakci.
Než se podíváme na investiční transakci, chci vám ukázat, jak by se to mohlo zdát různým lidem v organizaci. Na úrovni správy můžete mít přehled o více aplikacích. Možná budete chtít vědět o zdraví, které se počítá na základě dodržování SLA a dostupnosti. To zdraví neznamená, že všechno funguje stoprocentně. V tomto případě je místo, kde můžete vidět, že je investiční transakce ve stavu varování. Teď, trochu hlouběji, možná v oblasti podnikání, chcete mít nějaké další podrobnosti o jednotlivých transakcích, když poruší SLA, počty transakcí atd. Operační tým bude chtít být informován o tom prostřednictvím upozornění na některé třídit. Máme zabudovaná upozornění na výkon. Ve skutečnosti měříme výkon v prohlížeči koncového uživatele. Ať už se jedná o Internet Explorer, Chrome, Firefox atd., Jsme schopni to zjistit, to odpovídá na první otázku: má koncový uživatel problém?
Pojďme se ponořit a uvidíme, co dalšího můžeme o tom ukázat. Lidé, kteří se zajímají o představení, by otevřeli Precise. Vyhodnotili transakce. Prohlédli si sloupec SLA a identifikovali transakce, které nebyly v souladu se SLA. Mohli by vidět koncových uživatelů, kteří byli ovlivněni, a co tato transakce udělala, když probíhala v celé aplikaci. Způsob, jakým tyto hieroglyfy dešifrujete, je prohlížeč, adresa URL, adresa U je adresa URL, což je vstupní bod do JVM. Nyní tento konkrétní JVM provede volání webového serveru do druhého JVM, který poté provede příkaz SQL. Toto je zjevně problém s databází, protože tento příkaz SQL byl zodpovědný za 72 procent doby odezvy. Zaměřujeme se na čas. Čas je měna výkonu. Je to, jak koncoví uživatelé zažívají, zda věci běží pomalu nebo ne, a je to míra spotřeby zdrojů. Je to velmi užitečné; je to druh jediné metriky, která je nejdůležitější pro hodnocení výkonu. Když je tento problém předán DBA, nejedná se pouze o problém s databází, ale o tento příkaz SQL. To je kontext, o kterém jsem mluvil.
Nyní vyzbrojený těmito informacemi, mohu jít dovnitř a analyzovat, co se stalo. V první řadě vidím, že osa y je časem přes den. Promiňte, osa y je doba odezvy, osa x je čas přes den. Vidím, že existuje problém s databází, existují dva výskyty, vraťte se do tohoto toku, vyzvedněte si tento příkaz SQL a přejděte do expertního pohledu, kde vám Precise dokáže ukázat, co se děje, jeho ovládací prvky, jak dlouho tento kód trvá vykonat. V úrovni databáze je to plán provádění. Všimněte si, že Precise vybral skutečný prováděcí plán, který byl použit v době provádění, což se liší od odhadovaného plánu, který by byl v okamžiku, kdy byl daný plán poskytnut, a nikoli v době provádění. Může nebo nemusí odrážet, že databáze skutečně byla.
Tady dole je analýza doby odezvy pro příkaz SQL. Devadesát procent času stráveného v úložišti; deset procent bylo použito v procesoru. Vidím text příkazu SQL i zprávu o výsledcích. Text příkazu SQL ve skutečnosti začíná odhalovat některé problémy s kódováním. Je vybrána hvězda; který vrací všechny řádky - promiňte, všechny sloupce z řádků, které byly vráceny. Otočíme zpět další sloupce, které aplikace může nebo nemusí potřebovat. Tyto sloupce spotřebovávají prostor a prostředky ke zpracování. Pokud spustíte SAP, jednou z velkých změn, protože databáze HANA je sloupcová, je to, že v podstatě přepisuje SAP tak, aby nevybral vybranou hvězdu, takže může výrazně snížit spotřebu zdrojů. To je v podstatě něco, co se děje hodně času také v domácích aplikacích, ať už Java, .NET atd.
Tato obrazovka ukazuje, kdo, co, kdy, kde a proč. Proč se to dostane, jako příkaz SQL a plán provádění, který vám umožní řešit problémy. Protože Precise běží nepřetržitě, můžete ve skutečnosti měřit před a po, na úrovni příkazů SQL, na úrovni transakcí, takže buď můžete měřit pro sebe, stejně jako prostřednictvím majitelů aplikací a pro správu, že jste problém vyřešili . Tato dokumentace je opravdu užitečná. V tomto zásobníku aplikací je hodně složitosti. Z mnoha aplikací ve skutečnosti všichni, s nimiž jsme hovořili, provozují alespoň část aplikačního zásobníku pod VMware. V tomto případě se dívají na aplikaci zákaznických služeb, dívají se na dobu transakce a korelaují se zpomalením s virtualizační událostí. Přesné sledování všech virtualizačních událostí. Máme plug-in do vCenter to vyzvednout.
Jsme také schopni odhalit tvrzení. Obsah je jiný než využití. Ve skutečnosti ukazuje, kdy možná hlučný soused ovlivňuje hostujícího VM, v souvislosti s aplikací zákaznického serveru. Nyní jsem schopen vrtat a získávat informace a skutečně vidím dva virtuální počítače, které v tomto případě bojují o prostředky CPU. To mi umožňuje viditelnost, abych se mohl podívat na plánování. Mohu dát hostujícího VM na jiný fyzický server. Všechny tyto typy věcí, na které byste mohli reagovat, a kromě toho se ve skutečnosti mohu podívat na účinnost kódu, abych možná nechal použít méně CPU. Myslím, že mám v této prezentaci docela dobrý příklad toho, jak někdo dokázal snížit spotřebu procesoru o řádovou velikost.
To byl VMware. Pojďme do samotného kódu, kódu aplikace. Přesné vám umožní ukázat, co se děje v Java, .NET, ABAP kódu, E-Business, PeopleCode atd. Toto jsou vstupní body do, v tomto případě, do WebLogic. Tady dole je zpráva o zjištění, která mi říká, že je to tyto EJB, na které se musíte podívat, a řekne mi, že se v tomto systému děje také uzamykání. Opět, vrtání dolů v rámci logiky obchodní logiky, abych ukázal, co se děje. V tomto případě se dívám na konkrétní případy; Podporuji také sdružování. Pokud máte spuštěno mnoho JVM, můžete se buď podívat na klastr jako celek, nebo se podívat na úzká místa v jednotlivých JVM.
Jak se dostanete do zamykání, mohu se dostat do výjimek. Výjimka je trochu jiná než problém s výkonem. Výjimky jsou obvykle velmi rychlé. Protože existuje logická chyba a jakmile ji zasáhnete, končí. Dokázali jsme zachytit stopu zásobníku v hlavní výjimce, mohlo by to ušetřit spoustu času, protože to prochází pokusem přijít na to, co se děje, stačí mít stopu zásobníku přímo tady. Také jsme schopni zachytit úniky paměti. Řešení také zahrnuje databázovou vrstvu, mohu jít dovnitř, umím vyhodnotit instanci databáze. Opět platí, že osa y je místem, kde byl čas stráven, osa x je čas přes den. Existuje zpráva o zjištění, která mi automaticky řekne, co se v systému děje a na co bych se mohl podívat.
Jedna z věcí, které se týkají zprávy o nálezu Precise, je nejen pohled na protokoly nebo stav čekání - ale také pohled na všechny stavy provádění včetně CPU a vracení informací z úložiště. Úložiště je velmi důležitou součástí aplikačního zásobníku, zejména s příchodem solidního stavu. Mít informace v tomto směru může být velmi užitečné. U některých paměťových jednotek můžeme ve skutečnosti provést rozbor a ukázat, co se děje na úrovni jednotlivých zařízení. Tento druh informací - opět je to hluboká viditelnost; má široký rozsah - poskytnout vám pouze tolik informací, aby bylo možné více využít jako profesionála v oblasti výkonu aplikací, takže můžete své aplikace optimalizovat na základě end-to-end pro splnění těchto obchodních transakcí.
Mám pár případových studií, které jsem s vámi chtěl sdílet. Plavíme se docela rychle; Doufám, že jdu v pořádku. Když už mluvíme o úložišti, každý čas mění hardware. Existuje hardwarová záruka. Poskytlo to skutečně to, co vám řekl prodejce? Můžete to vyhodnotit pomocí Precise. Vstoupíte, a co se zde stalo, v podstatě vložili novou paměťovou jednotku, ale když se správci úložišť podívali jen na úroveň úložné jednotky, viděli mnoho sporů a domnívali se, že s touto novou úložnou jednotkou může být problém. . Při pohledu na více z pohledu end-to-end, přesně ukázat, kde by se to skutečně stalo. Ve skutečnosti šli z propustnosti asi 400 megabajtů za sekundu, kde úložiště odpovídalo za 38 procent doby odezvy, takže je dost vysoká. S novou úložnou jednotkou jsme ve skutečnosti zvýšili propustnost na šest, sedm set stovek megs za sekundu, v podstatě dvojnásobnou, a my jsme schopni snížit podíl skladovací úrovně na době transakce na polovinu. Dokážu to vlastně grafovat dříve, toto je období přerušení a poté další.
Takže znovu, dokumentace prokazující, že investice do hardwaru stála za to, a dodali tak, jak tento konkrétní prodejce očekával. Je tu všechno, kvůli složitosti, množství věcí, mohou se vyskytnout všechny druhy věcí. V tomto případě skutečně měli situaci, kdy každý obviňoval DBA, DBA byla jako „No, ne tak rychle.“ Tady se vlastně díváme na aplikaci SAP, myslím, že tento typ scénáře je docela běžný . Stalo se to, že vyvíjeli vlastní transakci pro uživatele. Uživatel je jako: „To je tak pomalé.“ Kodér ABAP - to je programovací jazyk v SAP - řekl: „Toto je problém s databází.“ Nakonec otevřeli Precise; měřili tohoto koncového uživatele 60 sekund, tedy dobře za minutu. Padesát tři sekundy bylo stráveno na zadním konci. Vrtali se do zadního konce a ve skutečnosti dokázali odhalit příkaz SQL uvedený v sestupném pořadí.
Tento nejvyšší příkaz SQL, který je zodpovědný za 25 procent spotřeby prostředků, je jeho průměrná doba provádění dvě milisekundy. Nemůžete vinit databázi. Víš, hej, ne tak rychle, chlapče. Otázka zní, proč je tolik poprav? No, odrazili to zpět do ABAP, vešel dovnitř, podíval se do vnoření smyčky, zjistil, že volají do databáze na špatném místě, v podstatě provedli změnu, testovali změnu a nyní je nová doba odezvy pět sekund. Trochu pomalu, ale mohli s tím žít. Mnohem lepší než 60 sekund. Někdy, jen fretkou ven, je to kód aplikace, je to databáze, je to úložiště? To jsou oblasti, kde Precise má kontext transakcí typu end-to-end, a proto přichází do hry Precise. Ty věci v podstatě ukončíš.
Dívám se na ten čas, vypadá to, že máme ještě trochu času na to, abychom si jich prošli ještě pár. Přes ně proudím. Tato aplikace byla vyvíjena více než rok. Když šli do QA, viděli, že webové servery byly vyvýšeny na 100 procent a vypadalo to, že aplikace nemůže běžet pod VMware. První, co všichni řekli, bylo: „Dej to na fyzický; nelze jej spustit pod VMware. “Přesné řešení jim ve skutečnosti nabídlo další způsoby řešení problému. Podívali jsme se na transakce, viděli jsme volání webového serveru, přichází jako ASMX v IIS.NET. Ve skutečnosti odhalil základní kód. Vidíš to, kam směřuji? To je 23 dní, 11 hodin. Páni, jak je to možné? Každá vyvolání tedy trvá 9, 4 sekundy a tato věc je vyvolána 215 000krát. Pro každé vyvolání používá 6 sekund CPU. To je důvod, tento kód je důvod, proč by se tato věc nemohla nikdy škálovat. Ve skutečnosti se nemohlo fyzicky přizpůsobit.
Co udělali, je to, že se vrátili ke svým vývojářům a řekli: „Může někdo změnit?“ Měli druh soutěže, vyzkoušeli různé návrhy a přišli s návrhem, který byl schopen běžet hodně efektivněji. Nový dokončil jeden bod, o něco méně než dvě sekundy, se dvěma stotinami sekundy v CPU. Nyní by se to mohlo přizpůsobit a mohlo by to běžet na farmě VMware. Dokázali jsme to v podstatě dokumentovat na úrovni kódu i transakce. Tohle je druh dřívějšího a potom následného. Nyní, když zde vidíte sloupcový sloupcový graf, který ukazuje web, .NET a databázi, nyní interagujete s databází. Toto je profil, který byste očekávali u aplikace, která byla běžnější.
Dobře, vybírám a vybírám další věci, které ti mohu ukázat. Mnoho lidí, jako je tento, protože to bedazzles mnoho obchodů. Pokud nemůžete splnit obchodní SLA a všichni jsou rádi: „Pomozte nám.“ V tomto obchodě se vyskytla situace, kdy je obchodní SLA v objednávkách přijatých do 15:00, je dodáno ten den. Je opravdu důležité, aby dostávali objednávky, a sklad je velmi zaneprázdněn. Tato obrazovka prodejních objednávek společnosti JD Edwards byla zmrazená a můžete získat velmi dobrý nápad, že se jedná o systém řízení zásob drobného zboží just-in-time. Prázdné police jsou v maloobchodě nepřijatelné. Musím tam mít zboží, abych ho mohl prodat. Udělali jsme, že jsme se ponořili, v tomto případě se díváme na databázi serveru SQL. Vzhled a vzhled je stejný, ať už je to SQL, Oracle, DB2 nebo Sybase.
Identifikovali jsme výběr z PS_PROD a jsme schopni zachytit dobu trvání, skutečnost, že vykonávají tolik. Tmavě modrá se shodovala s klíčem, který řekl, že nečekají na nějaký čekací stav nebo na protokolování nebo dokonce na úložiště - tato věc je vázána CPU. Sledovali jsme příkaz SQL do roku 34301, takže pokaždé, když je to provedeno, zvyšujeme naše čítače, abychom ho udrželi. To znamená, že máme podrobnou historii a já k ní mám přístup kliknutím na toto tlačítko ladění. Zde je karta historie. Tato obrazovka zobrazuje průměrné trvání versus změny. Středa, čtvrtek, pátek byla průměrná doba trvání asi dvě desetiny sekundy. Velmi málo obrazovek zamrzne, jsou schopny splnit obchodní SLA. Přijďte 27. února, něco se změní a najednou je tu doba provedení, a to je vlastně dost pomalé, aby způsobilo časový limit, což má za následek zamrznutí obrazovky. Přesné, udržováním podrobné historie, včetně plánu provádění a obecných změn indexů tabulky, pokud se tento SQL používá. Podařilo se nám zjistit, že přístupový plán se změnil 27. února. Pondělí až páteční špatný týden. Přijďte 5. března, přístupový plán se znovu změnil. To je dobrý týden. Tato růžová hvězda nám říká aktualizovaný objem.
Zde vidíte, že počet řádků v podkladových tabulkách roste, což je typické pro firmu. Chcete, aby vaše tabulky rostly. Jde o to, že příkazy jsou analyzovány, příkazy SQL přicházejí, optimalizátor se musí rozhodnout, co dělat a zvolit, když je plán provádění rychlý, zvolit jiný plán provedení, když je pomalý, což způsobí zamrznutí obrazovky. Na základě hlubokých technologií potřebuji vědět, co je plán provádění, a precizně jej zachytím kompletní s datem a časovým razítkem. To je ten, který byl rychlý a efektivní, to je ten, který byl pomalý a neefektivní. Toto spojení filtru jednoduše používá mnohem více CPU k sladění, k provedení tohoto konkrétního příkazu SQL. Stále mají stejný konečný účinek, ale tento má v zásadě pomalejší a méně efektivní recept na doručení sady výsledků. Takže projdeme. Hej, máme čas na pár dalších?
Eric Kavanagh: Jo, jdi na to.
Bill Ellis: Dobře, skočím dopředu. Jedna věc, kterou chci, abyste si vzali na vědomí, mluvili jsme o hardwaru, mluvili jsme o SAP, mluvili jsme o .NET, mluvili jsme o prostředí JD Edwards a prostředí Java-SQL Server. Toto je SAP, tady se díváme na PeopleSoft. Precizní podpůrná matice je široká a hluboká. Pokud máte aplikaci, více než pravděpodobné, můžeme ji vybavit tak, aby poskytovala tuto úroveň viditelnosti. Jednou z největších změn, která se právě děje, je mobilita. PeopleSoft zavedl mobilitu pomocí svého Fluid UI. Fluid UI používá systém velmi odlišně. Tato aplikace se vyvíjí. Fluid UI - to, co dělá z pohledu správy, je to, že umožňuje koncovým uživatelům používat svůj telefon a výrazně zvyšuje produktivitu. Pokud máte stovky nebo tisíce nebo více zaměstnanců, pokud můžete zvýšit jejich produktivitu, 1–2 procenta, můžete mít obrovský dopad na mzdy a všechno ostatní. Co se stalo, tento konkrétní obchod vyšel z uživatelského rozhraní PeopleSoft Fluid UI. Když už mluvíme o složitosti, jedná se o zásobník PeopleSoft. Jedna aplikace, minimálně šest technologií, mnoho koncových uživatelů. Jak to začnete?
Ještě jednou bude Precise schopna tyto transakce sledovat. Zde vám ukážeme skládaný sloupcový graf zobrazující klienta, webový server, Java, databázi Tuxedo, zásobník aplikací PeopleSoft. Zelená mapuje na J2EE, což je druh fantastického způsobu, jak říci WebLogic. Tohle je škrt. Koncoví uživatelé začínají používat tekuté uživatelské rozhraní a doba odezvy se může pohybovat od jedné a půl, dvou sekund, až kolem devíti, deseti sekund. To, co tato jedna obrazovka neukazuje, je počet lidí, kteří „neodpovídají“. Ve skutečnosti v aplikaci mrznou. Pojďme se podívat na některé viditelnosti, které je Precise schopna poskytnout tomuto zákazníkovi.
Nejprve, když se podívám na transakce PeopleSoft, v podstatě vidí, viděli jsme tento druh věcí napříč deskou. Byly ovlivněny všechny transakce i všechna místa. Mimochodem, když se na to podíváte, můžete skutečně vidět místa po celém světě. Z Asie a Tichomoří, do Evropy a Severní Ameriky. Problém s výkonem nebyl lokalizován pro konkrétní transakci nebo konkrétní geografickou polohu, je to široký systém. Je to způsob, jak říci, že změna nebo způsob, jakým má UI tekutin globální dopad. Můžete vidět zde z hlediska škálovatelnosti, lidé se pokoušejí dělat stejný druh aktivity, ale doba odezvy je v podstatě jen degradována a degradována. Můžete vidět, že se věci nemění. Věci se dějí velmi, velmi špatně. Když se podívám na počet os a souběžná připojení, uvidíte něco, co je velmi zajímavé, pokud jde o počet přístupů a spojení. Zde se rozšiřujeme pouze na asi 5 000 a vy se na to díváte, což vede k 100 současným připojením. To se provádí poté; to je dříve. Takže moje skutečná poptávka v systému, pokud by se tato věc mohla přizpůsobit, je v rozsahu 300 000. Ve starých časech se s klasickým uživatelským rozhraním díváte na 30 současných připojení.
Nyní vám to říká, že uživatelské rozhraní Fluid používá nejméně 10x počet souběžných připojení. Začneme stahovat, co se děje pod kryty s PeopleSoft, takže můžete začít vidět dopad na webové servery, skutečnost, že SLA začínají porušovat. Nebudeme chodit do všeho, ale nakonec se stane, že se v podstatě spoléhají na zasílání zpráv. V zásadě cvičí, je WebLogic a způsobují řazení do Tuxedo. Ve skutečnosti se objevil problém s víceúrovňovými závislostmi, který se objevil u uživatelského rozhraní Fluid UI, ale Precise dokázal, že celou řadou různých věcí se můžeme soustředit na to, o co jde. Ukazuje se, že se vyskytl také problém v samotné databázi. Ve skutečnosti existuje soubor protokolu zpráv a kvůli všem současným uživatelům byl tento soubor protokolu zamykán. V podstatě to mělo co vyladit, v každé jednotlivé vrstvě v zásobníku aplikací. Když mluvíme o složitosti, tady je ve skutečnosti vrstva Tuxedo, která vám zobrazuje frontu, a můžete vidět také snížení výkonu v této úrovni. Viděl jsem procesy; Viděl jsem domény a servery. V Tuxedu, pro lidi, kteří to používají, obvykle otvíráte další fronty, domény a servery, stejně jako v supermarketu, abyste ulehčili přetížení, abyste minimalizovali čas čekání ve frontě. Poslední a poslední možnost, Precise zobrazuje spoustu informací.
Jak jsem již zmínil dříve, každá významná transakce interaguje se systémem záznamů. Viditelnost do databáze je prvořadá. Precise ukazuje, co se děje v databázi, v rámci WebLogic, v Java, .NET, v prohlížeči, ale místo, které Precise opravdu vyniká, je v databázové vrstvě. To se stává slabost našich konkurentů. Dovolte mi ukázat vám jeden ze způsobů, jak vám Precise může pomoci projít. Nebudu trávit čas na trojúhelníku optimalizace databáze, ale v zásadě se díváme na nízkonákladové, nízkorizikové, rozsáhlé, vysokorizikové a vysokorychlostní změny typu. Já vlastně bude tweet z tohoto snímku poté, pokud lidé chtějí zkusit a podívat se na to. Je to docela velký průvodce, myslím, pro problémy s laděním. Zde je odborný pohled na Precise for Oracle. Nejlépe ve zprávě o nálezu je 60% dopad tohoto konkrétního příkazu SQL. Pokud otevřete tuto obrazovku aktivity, zobrazí se tam. Mohu se podívat na toto prohlášení, existuje jeden plán provedení. Každé spuštění trvá druhé - 48 000 poprav. To přidává až 48 000 dalších hodin poprav.
Tmavě modrá je opět CPU. Tato věc je vázána na CPU, ne na čekací stav, ani na protokol. Zdůrazňuji, že protože někteří z našich konkurentů sledují pouze stavy čekání a protokolování událostí, ale obecně řečeno, CPU je nejrušnější stav provádění a nabízí nejvíce zpětného odkupu. Do tohoto expertního pohledu - a jdu velmi rychle - jsem udělal to, že jsem se podíval na stůl, 100 000 řádků, 37 000 bloků. Děláme plnou tabulku, ale v této věci máme šest indexů. Co se tam děje? Když se podívám na klauzuli where, to, co dělá, je to, že ve skutečnosti převádí sloupec na velká písmena a říká, kde je stejná jako velká písmena, najděte proměnnou. Co se děje, je pokaždé, když se tato věc spustí, Oracle musí tento sloupec převést na velká písmena. Spíše než téměř padesát tisíckrát je mnohem efektivnější vytvořit tento index velkými písmeny funkčního indexu a je k dispozici nejen v podnikové divizi Oracle, ale také ve standardní divizi. Když to uděláte, pak můžete ověřit prováděcí plán, který vydává novému uživateli velkého indexového uživatele indexu, což byla jen moje věc.
Poté, z měření před a po, se díváte na jednu sekundu prováděcího času, agreguje až 9 hodin 54 minut, se stejným přesným příkazem SQL, ale s tím, že tento index byl vytvořen velkými písmeny pro 58 000 spuštění, odpověď čas klesne na sub milisekundy, agreguje se dohromady, přijde až na sedm sekund. V podstatě jsem na svém serveru ušetřil deset hodin CPU. To je obrovské. Protože pokud nechci obnovit server, můžu na tomto serveru žít. Vlastně jsem pokles využití serveru o 20 procent a vy můžete skutečně vidět předchozí a následující. To je typ viditelnosti, který může Precise poskytnout. Mohli bychom se také podívat na několik dalších věcí, proč máte všechny tyto indexy, pokud se nepoužívají? Mohou s tím pokračovat. Tam je architektura, a já ji zabalím, protože jsme dosáhli vrcholu hodiny. Jsem opravdovým věřícím v tomto řešení a chceme, abyste byli opravdovým věřícím. V společnosti IDERA věříme, že zkušenost přinese zákazníkovi, takže pokud máte zájem, můžeme na vašem webu provést hodnocení.
S tím přejdu maják zpět.
Eric Kavanagh: Jo, tohle byl obrovský detail, který jste tam ukázali. Je to opravdu docela fascinující. Myslím, že jsem se vám v minulosti zmínil o tom, že - a vím v některých dalších webových přenosech, které jsme udělali s IDERA, zmínil jsem to - skutečně jsem sledoval přesnost od doby, než jej IDERA získala, celou cestu zpět do roku 2008, myslím, nebo 2009. Byl jsem tehdy fascinován tím. Jsem zvědavý, kolik práce zbývá na nových verzích aplikací. Zmínili jste, že SAP HANA, což je podle mého názoru docela působivé, že se můžete skutečně kopat do architektury HANA a dělat tam nějaké řešení problémů. Kolik máte lidí? Kolik úsilí je z vaší strany a kolik toho lze udělat trochu dynamicky, což znamená, že když se nástroj nasadí, začnete procházet a vidět různé věci? Kolik z toho může být dynamicky, tak nějak zjištěno nástrojem, abyste mohli lidem pomoci při řešení složitých prostředí?
Bill Ellis: Položili jste tam spoustu otázek.
Eric Kavanagh: Já vím, promiň.
Bill Ellis: Poskytl jsem mnoho podrobností, protože pro tyto aplikace je při pohledu na kód ďábel v detailu. Musíte mít takovou úroveň detailů, abyste mohli mít něco, co je možné uskutečnit. Bez měřitelných metrik stačí vědět o symptomech. Ve skutečnosti nevyřešíte problémy. IDERA je o řešení problémů. Zůstat na vrcholu nových verzí a věcí je velká výzva. Otázka, co to znamená, to je opravdu pro správu produktů. Nemám moc viditelnosti do týmu, který nás v podstatě udržuje v aktuálním stavu. Pokud jde o HANA, je to vlastně nový přírůstek do produktové řady IDERA; je to velmi vzrušující. Jedna z věcí HANA je - dovolte mi, abych si o tom chvíli promluvil. V rámci úkolu by obchody SAP provedly to, že replikují databázi pro účely reportování. Pak byste museli mít lidi, aby se smířili s tím, co je ve skutečnosti aktuální. Měli byste tyto různé databáze a byly by synchronizovány různými úrovněmi. Je tu jen spousta času a úsilí, plus hardware, software a lidé, kteří vše udržují.
Myšlenka HANA mít vysoce paralelní paměťovou databázi, která se v zásadě vyhýbá nutnosti duplicitní databáze. Máme jednu databázi, jeden zdroj pravdy, je to vždy aktuální, takže se vyhnete potřebě udělat vše, co smíření. Důležitost výkonu databáze HANA stoupá - řeknu 10x nebo alespoň cennější než součet všech těchto dalších databází, hardware, zdroje, které si lze koupit. Vzhledem k tomu, že je tato komponenta nyní schopna spravovat HANA, nyní je ve verzi beta testování, brzy to půjde GA. Je to docela vzrušující pro IDERA a pro nás, abychom v podstatě podporovali platformu SAP. Nejsem si jistý, jaké další části vaší otázky jsem zkrátil, ale -
Eric Kavanagh: Ne, to je všechno dobré. Hodil jsem na vás celou hromadu najednou, takže se omlouvám. Jsem prostě fascinován, opravdu, myslím, že to není velmi jednoduchá aplikace, že? Vykopáváte se hluboko do těchto nástrojů a chápete, jak spolu navzájem a k vašemu bodu interagují, musíte příběh nějakým způsobem složit do hlavy. Musíte zkombinovat kousky informací, abyste pochopili, co se ve skutečnosti děje a co vám způsobuje potíže, takže tam můžete jít a tyto problémy vyřešit.
Jeden účastník se ptá, jak obtížné je implementovat Precise? Další osoba se zeptala, kdo jsou lidé - samozřejmě DBA - ale kdo jsou další role v organizaci, kteří by tento nástroj použili?
Bill Ellis: Přesnost je trochu složitější na nasazení. Musíte mít určitou znalost aplikačního prostředí, pokud jde o, víte, tato aplikace běží v této databázi, potřebuje nebo - webové servery střední úrovně atd. Myslím, že vzhledem ke složitosti některých z těchto aplikací, je to vlastně relativně snadné. Pokud mohu webový server vybavit až do vaší databáze, mohu to udělat od začátku do konce. Všimli jste si, že jsem neřekl nic o instrumentaci koncového uživatele, a to proto, že to, co děláme, je skutečně zahrnuto dynamicky, takže nemusíte měnit svůj kód ani nic jiného. Do rámce stránky aplikace vstoupí JavaScript. Bez ohledu na to, kde se uživatel nachází na světě, když přistupuje k URL z vaší aplikace a tuto stránku sklopí, je vybaven nástrojem Precise. To nám umožňuje vybrat ID uživatele, jejich IP adresu, také dobu prvního bajtového vykreslení každé doby spuštění skriptu komponent stránky v prohlížeči koncového uživatele.
Pokud jde o transakce, nemusíte transakce mapovat, protože jsou pevně spojeny. Tato adresa URL se stává vstupním bodem do JVM a poté vyvolá tuto zprávu, což má za následek zachycení JVC z databáze. V podstatě jsme schopni zachytit tyto přirozené body připojení a poté je prezentovat na této transakční obrazovce, kterou jsem vám ukázal, kde jsme také spočítali, kolik času nebo procenta času, který byl stráven v každém jednotlivém kroku. To vše se provádí automaticky. Obecně řečeno, přidělíme 90 minut na to - v podstatě nainstalovat Precise jádro a pak začneme implementovat aplikaci. V závislosti na znalostech aplikace může trvat několik dalších relací, než se celá aplikace vybaví. Mnoho lidí používá pouze komponentu databáze Precise. To je v pořádku. V zásadě to můžete rozdělit, rozdělit na komponenty, které máte pocit, že vaše stránky potřebují. Rozhodně věříme, že kontext instrumentace celého aplikačního zásobníku, takže vidíte, že závislost mezi vrstvami skutečně zvyšuje hodnotu monitorování jednotlivé úrovně. Pokud někdo chce prozkoumat vybavení svých aplikačních balíčků dále, přejděte na naši webovou stránku - myslím, že je to nejjednodušší způsob, jak požádat o další informace, a my o tom budeme hovořit o něco dále.
Eric Kavanagh: Dovolte mi, abych vám hodil jednu nebo dvě rychlé otázky. Hádám, že v průběhu času shromažďujete a budujete úložiště interakce mezi různými aplikacemi a různými databázemi, a to jak pro jednotlivé klienty, tak jako pro firemní společnost. Jinými slovy, myslím si, modelování scénářů, na co se zmiňuji. Je to tak? Opravdu udržujete určitý druh úložiště běžných scénářů, abyste mohli navrhovat koncovým uživatelům návrhy, když se začnou hrát určité věci? Stejně jako tato verze sady E-Business Suite, tato verze této databáze atd. - děláte to hodně?
Bill Ellis: No, tento druh informací je zabudován do zprávy o zjištění. Zpráva o zjištěních uvádí, jaké jsou výkonnostní překážky a je založena na době provedení. Součástí této zprávy o zjištění je více informací a co uděláte dále. Informace nebo zkušenosti od zákazníků atd. Jsou v zásadě začleněny do této knihovny doporučení.
Eric Kavanagh: Dobře, to zní dobře. Lidi, fantastická prezentace dnes. Bille, miloval jsem, kolik detailů jsi tam měl. Jen jsem si myslel, že to bylo opravdu fantastické, odvážné, podrobné informace, které ukazují, jak se to všechno dělá. V určitém okamžiku je to skoro jako černá magie, ale ve skutečnosti to tak není. Je to velmi specifická technologie, kterou jste dali dohromady, abyste pochopili velmi, velmi složitá prostředí a učinili lidi šťastnými, protože nikdo nemá rád, když aplikace běží pomalu.
Lidi, budeme toto webové vysílání archivovat. Můžete přeskočit online na Techopedia nebo insideanalysis.com a páni, díky za váš čas, příště vás budeme dohonovat. Dávejte pozor, sbohem.
