Odnést: Host Eric Kavanagh diskutuje o výkonu aplikací a o tom, jak zlepšit efektivitu s Dr. Robinem Bloorem, Dezem Blanchfieldem a IDERAs Billem Ellisem.
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ítáme vás znovu 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, která se stala doplňkem naší série Briefing Room. Název je „Akcelerace aplikací: vyšší výkon pro koncové uživatele“. No tak, lidi, kdo to nechce? Pokud jsem ten chlap tam venku, který pomáhá vaší aplikaci běžet rychleji, přemýšlím, že ten chlap, co mi po práci koupil piva, je po baru. Musí to být docela cool věc, do které se vcházíme a zrychlí kdokoli aplikaci.
Skutečně jde o snímek, zasáhni mě na @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 mluvili o akceleraci aplikací. Chtěli jsme slyšet od Dez Blanchfielda a také doktora Robina Bloora - byli dnes po celém světě - a potom se Bill Ellis připojuje z větší Virginie. S tím jsem to předal 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 v průběhu let udělal spoustu práce, ve smyslu, že jsem ve skutečnosti vykonal strašnou práci při sledování výkonu a nějakým způsobem, jak vyzkoušet a spočí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 podstatě, množství práce, kterou ve skutečnosti musí udělat, aby systém fungoval přiměřeně dobře, pokud 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é jste museli 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, skutečně mluvíte o několika věcech, které soutěží o počítačové prostředky. 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 k možnostem 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še, 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 vlastně přemýšlíte o pokusu o to vše zorganizovat, pokud jde o data, která se mění, změní se výkonnost softwaru, protože se změní hardware, atd. A tak dále, skutečně se díváte na neuvěřitelně obtížnou situaci s různými variantami. Toto je křivka složitosti. Samozřejmě její složitost křivky pro téměř všechno, ale já jsem viděl to kreslil znovu a znovu, když mluví 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. Téměř nezáleží na tom, jaké uzly a připojení jsou a co 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 - tedy č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 nemůžu to pojmenovat. Ve skutečnosti se na to díváte a vy se vlastně snažíte tak či onak získat úrovně služeb, které budou přiměřeně napříč celou řadou uživatelů, s různými, pokud chcete, očekáváními. Je to složitá situace a vše, co ve skutečnosti říkám, je tento komplex. Čí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. Zde 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 reagovat za jednu 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 tu chvíli. 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 jeho pokles a mnoho dalších lidí si myslí, že jeho pokles, 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, to je druh skleněného stropu pro lidskou reakci. Jakmile bude mít tento software-to-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 to je 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. Musíš jít nahoru na levou stranu, máš správu systému, což je sada softwaru, který slouží do správy služeb, která se snaží spravovat úroveň služeb. Nad tím máte řízení obchodní výkonnosti. Když se podíváte dolů, oblast 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 věcí, které se vyvinou 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 u velkých organizací a úrovní 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, jdu dál na Dez Wholl a doufejme, že mluví o něčem jiném.
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 jeho součástí naší DNA je chtít výkon, získat ze všeho 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 auta, jak rychle obcházejí kola. Každý jednotlivý aspekt, není žádným aspektem vzorce 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 jste splnili svou 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. Nesnažili jsme se už 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, 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 aktivní 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 v 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ásadní, víte. Pak pár zábavných - je help desk zelená? Protože pokud ne, pak všechno běží v pořádku a kdo dostane koblihy? Život byl v těchto dnech opravdu jednoduchý. Dokonce i v těch dnech, a pak jsem mluvil před 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 naznačil Robin. 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 čelit tomu každý den administrativním způsobem.
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 se procházeli internetovým rozmachem, můžete se jednoduše jen rozhlédnout a uvědomit si, že v každodenním životě, že nyní připojíme vše k internetu. Věřím, že jsme dostali topinkovač, který zřejmě 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.
Její rok 2016 nyní čelil 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 obrázků a sociálních médií. Nebo v některých případech, v dopravní a přepravní logistice, vše v oblasti bankovnictví, 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 se chystala čelit, je to velmi těžká výzva internetu věcí.
Pokud to nebylo dost špatné, chystali se vybudovat 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 Amazonky dostali jeden ze svých. Baidu mají jedno z těchto zařízení, se kterými můžete hovořit, převádějí jej na běžný systém, 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 současných standardních aplikačních balíčků 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řevede to na, spustí to celou cestu k internetu do back-end systému, front-end obdrží, že , převede jej na dotaz, spustí dotaz přes zásobník aplikací, prochází databází, zasáhne disk, vrátí se a uprostřed je nosná síť, nachází se zde stavové centrum 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. Weve dostal technologii na místě, weve dostal technologii na místě, Weve dostal řadu možností datových center; fyzický a virtuální. Weve dostal fyzické a virtuální servery, weve 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 jsme dostali softwarově definované sítě, virtualizaci síťových funkcí, pod kterou máme pravděpodobně pravděpodobně více než nyní, nyní jsme dostali mikro služby a aplikace aktivních služeb. Když kliknete na adresu URL, je zde spousta obchodní logiky, která je umístěna na konci této adresy URL a která popisuje, co je potřeba k jejímu skutečnému dodání. Nemusí to nutně mít předem vytvořenou logiku, která na ni čeká. Weve dostal tradiční databáze na jedné straně, které jsou škálovány velmi, velmi velké. Weve měl rád 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. Weve získal mobilitu složitosti, pokud jde o zařízení, která přenášejí, notebooky a telefony a tablety.
Weve dostal 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. Ať už přes internet nebo přes Wi-Fi, máme zdarma kavárnu v kavárně dole, protože mají kávu. 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, co teď hrálo, 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, co se nazývá Olli, což je 3-D ed bus který zabírá asi šest lidí a dokáže se projet městem a můžete k němu mluvit prostou angličtinou, a to se vám ozve zpět. Pokud zasáhne provoz, rozhodne se odbočit doleva nebo doprava z hlavní oblasti, kde je provoz. Jak se točí a vy si děláte starosti, proč se jeho odbočka vlevo nebo vpravo od hlavní silnice, řekne vám: "Neboj se, já se chystám odbočit doleva." Je tu dopravní provoz a já se 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 řízení 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 by si jen myslel, že by bylo hezké mít nástroj - je to předpoklad; je to naprosto nezbytné. Zde 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, Ill jen vložil několik screenshotů jen značek. Když přemýšlíte o všech kusech, které zde má spravovat, nemluvilo to nutně pouze o jedné značce, jedná se o všechny značky v prostředí velkých dat a o nejlepší značku, nejen o každou malou malou nebo otevřený zdroj. Vypadáte a myslíte si, že je to docela ohromující graf.
Podívejme se jen na pár vertikál. Umožňuje například marketing. Zde 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ř, ne různá aplikace a web a vývoj a síť a všechny ostatní. Jen značka. Je tu dříve, před pěti lety a dnes zde. Je to jen zhorší. V tomto okamžiku, kdy je realita, lidé jednoduše 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 toho, jak monitorovací konzole nyní 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. Nyní je zde 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 stateč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, který tyto nástroje používá, je výkon aplikací pro lidi ztracenou hrou a musí 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ěkuju. Zde sdílím svou obrazovku. Myslím, že někdo může potvrdit, že vidíte moji obrazovku?
Dr. Robin Bloor: To jo.
Eric Kavanagh: Vypadá to dobře.
Bill Ellis: Děkuju. Jedinou věcí, na kterou se zmínil, bylo, že opravdu 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: Líbí se mi to, budu si to pamatovat.
Eric Kavanagh: Typická míle za hodinu.
Bill Ellis: Byly zde hovořeny 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 ke stejné minci a chystali se na ně podívat. 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 kon. Con 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é mluvili 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í inventáře, 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ěl, 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 zdravotním stavu vypočteném podle souladu a dostupnosti SLA. 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ž jsme schopni zjistit Internet Explorer, Chrome, Firefox atd., Odpovídá na první otázku: má koncový uživatel problém?
Pojďme se ponořit a uvidíme, co dalšího o tom můžeme ukázat. Lidé, kteří se zajímají o představení, by otevřeli Precise. Vyhodnotí transakce. Prohlédli si sloupec SLA a identifikovali transakce, které nebyly v souladu s SLA. Mohli by vidět koncových uživatelů, kteří byli ovlivněni, a také to, 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 to je míra spotřeby zdrojů. Je to velmi šikovný; její druh jediné metriky, která je nejdůležitější pro hodnocení výkonu. Když je tento problém předán DBA, není to jen problém s databází, je to tento příkaz SQL. To je o čem jsem mluvil.
Nyní vyzbrojený těmito informacemi, jsem schopen vstoupit 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 k tomuto toku, vyzvedněte 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 databázové úrovni je jeho prováděcí plán. Všimněte si, že Precise vybral skutečný prováděcí plán, který byl použit v době provedení, což se liší od odhadovaného plánu, což by bylo, když byl plán dán, a nikoli během doby 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 příkaz SQL i zprávu o zjištěních. Příkaz SQL skutečně 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čili jsme 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 této sadě aplikací je hodně složitosti. Z mnoha aplikací ve skutečnosti všichni, s nimiž jsme mluvili, spouštěli 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 korelují ji se zpomalením je událost virtualizace. 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 vaši hostující VM, v souvislosti s aplikací zákaznického serveru. Nyní jsem schopen vrtat a získávat informace a vidím skutečně 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. Umožňuje jít do samotného kódu, kódu aplikace. Přesné vám umožní ukázat, co se děje v jazycích Java, .NET, ABAP kód, E-Business, PeopleCode atd. Toto jsou vstupní body, v tomto případě do WebLogic. Tady dole je zpráva o nálezech, která mi říká 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, aby se ukázalo, 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 jeho procházení se snaží přijít na to, co se děje, stačí mít stopu zásobníku přímo tady. Byli také 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 přesných nálezech, se nezabývá jen protokoly nebo stavem čekání - zaměřuje se na všechny stavy provádění včetně CPU a vrací informace 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í - znovu, jeho hluboká viditelnost; jeho široký rozsah - aby vám poskytl tolik informací, abyste měli více pákového efektu jako profesionál v oblasti výkonu aplikací, takže můžete své aplikace optimalizovat na úrovni 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 jsem v pořádku. Když už mluvíme o úložišti, každý čas mění hardware. Má hardwarovou záruku. 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 docela vysoká. S novou skladovací jednotkou jsme ve skutečnosti zvýšili propustnost na šest, sedm set megs za sekundu, v podstatě dvojnásobnou, a dokázali jsme snížit podíl skladovací úrovně na dobu transakce na polovinu. Jsem schopen skutečně graf, který se dříve, je to období cutover, a pak po.
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í, existuje celá řada věcí, které se mohou stát. 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. Jste druh převýšení vinu 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 přichází do styku s transakcemi typu end-to-end, a to je místo, kde přichází do hry Precise. Ty věci v podstatě ukončíš.
Když se podívám 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ý; nemůžou běžet 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 tam, 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 to nemohlo být ve fyzickém měřítku.
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ý 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 nejste schopni splnit obchodní SLA, a všichni jsou jako: „Pomozte nám.“ V tomto obchodě se vyskytla situace, kdy je obchodní SLA v objednávkách přijatých do 15:00, dodáno v 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ží v pravý čas. Prázdné police jsou v maloobchodě nepřijatelné. Musím tam mít zboží, abych ho mohl prodat. Udělali jsme, že jsme se potápěli, v tomto případě jsme se dívali na databázi serveru SQL. Vzhled a vzhled je stejný, ať už jeho SQL, Oracle, DB2 nebo Sybase.
Identifikovali jsme výběr z PS_PROD a byli 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 provádění, 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átek š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, přeskočí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. Přesná 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ě teď 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 ukazoval skládaný sloupcový graf zobrazující klienta, webový server, Javu, 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é z viditelností, které je Precise schopen 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, její systém byl široký. 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 zajímavého z hlediska počtu přístupů a připojení. Zde byly pouze škálovány na asi 5 000 a vy jste se na to dívali, to je vrchol na 100 souběžných připojeních. 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, s klasickým uživatelským rozhraním, jste se dívali na 30 současných spojení.
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. Je to vlastně 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ž už mluvíme o složitosti, je tu vlastně vrstva Tuxedo, která vám zobrazuje frontu, a v této úrovni také vidíte snížení výkonu. 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ám na levné, nízkorizikové, na rozsáhlé, vysokorizikové a nákladové změny typu. Já vlastně bude tweet z tohoto snímku poté, pokud lidé chtějí zkusit a podívat se na to. Myslím, že je to docela velký průvodce pro ladění problémů. Heres the Precise for Oracle expert view. 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. Můžu se podívat na tento výběry, 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. Když jsem se dostal k tomuto odbornému pohledu - a já jsem velmi rychle - dělal jsem, že jsem se podíval na stůl, 100 000 řádků, 37 000 bloků. Dělali jsme celý stůl, 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 tato klauzule dělá, je to, že ve skutečnosti převádí sloupec na velká písmena a jeho přísloví, kde je stejné jako velké, 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ž to 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 divizi firem Oracle, ale také v standardním dělení. 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, při pohledu na dobu jedné sekundy, se agreguje až 9 hodin 54 minut, se stejným přesným příkazem SQL, ale s tím, že se tento index sestaví velkými písmeny pro 58 000 provedení, doba odezvy klesne na sub-milisekundy, agregovat 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 nejsem kvůli aktualizaci serveru, jsem schopen žít na tomto serveru. 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. Existuje také několik dalších věcí, na které bychom se mohli podívat, proč máte všechny tyto indexy, pokud se nepoužívají? Mohou s tím pokračovat. Je tam architektura, a já ji zabalím, protože se dostávali na špičku. Jsem opravdový věřící 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, jsme schopni provést hodnocení na vašem webu.
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, že v některých dalších webových přenosech, které byly vytvořeny s IDERA, jsem to zmínil - - ve skutečnosti jsem sledoval přesnost, protože předtím, než ji IDERA získala, až do roku 2008 , Myslím, nebo 2009. To mě tehdy fascinovalo. Jsem zvědavý, kolik práce zbývá zůstat na vrcholu nových vydání 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: Tam jste položili spoustu otázek.
Eric Kavanagh: Vím, promiň.
Bill Ellis: Poskytl jsem mnoho podrobností, protože pro tyto aplikace, při pohledu na kód, je ďábel v detailu. Musíte mít takovou úroveň detailů, abyste mohli mít něco, co lze činit. 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 produktový management. Nemám do týmu hodně viditelnosti, která nás v podstatě udržuje v aktuálním stavu. Pokud jde o HANA, jedná se vlastně o 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 replikaci databáze pro účely reportingu. Pak musíte 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 nebyly by synchronizovány na různých úrovních. Je tu jen hodně času a úsilí, plus hardware, software a lidé, aby vše udržovali.
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 vždy aktuální, takže se vyhnete potřebě udělat vše smíření. Důležitost výkonu databáze HANA stoupá - řeknu 10x nebo alespoň hodnotnější než součet všech těchto jiných databází, hardware, zdroje si lze koupit. Vzhledem k tomu, že je nyní možné spravovat HANA, nyní je tato komponenta ve skutečnosti v beta testování, je to něco, co brzy půjde GA. Pro společnost IDERA a pro nás tedy v podstatě podporujeme platformu SAP. Nejsem si jistý, jaké další části vaší otázky jsem zkrátil, ale -
Eric Kavanagh: Ne, to jsou všechny dobré věci. 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? Pokud se budete hlouběji věnovat těmto nástrojům a pochopíte, jak interagují mezi sebou navzájem a k vaší věci, musíte příběh trochu spojit do hlavy. Musíte kombinovat 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řesné nasazení je trochu složitější. 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šimnete si, že jsem neřekl nic o instrumentaci koncového uživatele, a to proto, že to, co děláme, je vlastně 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é ji vyvolá, což má za následek zachycení JVC z databáze. Byli jsme schopni v podstatě zachytit tyto přirozené body připojení a poté je prezentovat na obrazovce transakce, 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 con s tím, že celý aplikační zásobník je vybaven, takže můžete vidět, že závislost mezi jednotlivými úrovněmi 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 dále o tom trochu diskutovat.
Eric Kavanagh: Dovolte mi hodit 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 i jako podniková entita. Jinými slovy, myslím, že modelování scénářů je to, na co Im narážím. Je to tak? Opravdu udržujete určitý druh úložiště běžných scénářů, abyste mohli navrhovat koncové uživatele, když se do hry dostanou 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: Takový druh informací je zabudován do zprávy o zjištěních. Zpráva o zjištěních uvádí, jaké jsou výkonnostní překážky a které jsou založeny 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 téměř jako černá magie, ale ve skutečnosti není. Její velmi specifickou technologii, kterou jste sestavili, abyste porozuměli velmi, velmi složitým prostředím 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řejít online na Techopedia nebo insideanalysis.com a páni, děkujeme za váš čas, příště vás budeme dohonovat. Dávejte pozor, sbohem.