Od zamestnancov Techopedia, 2. novembra 2016
Jedlo so sebou: Host Eric Kavanagh diskutuje o výkonnosti aplikácií a o tom, ako zlepšiť efektívnosť s Dr. Robinom Bloorom, Dezom Blanchfieldom a Billom Ellisom IDERA.
Momentálne nie ste prihlásení. Ak chcete vidieť video, prihláste sa alebo sa zaregistrujte.
Eric Kavanagh: Dámy a páni, pozdravte sa a privítajte späť v Hot Technologies. Ano, naozaj! Moje meno je Eric Kavanagh, budem vaším hostiteľom pre ďalšie webové vysielanie dnes v tejto skutočne zábavnej a vzrušujúcej sérii, ktorú sme dostali ako kompliment našej série Briefing Room. Názov je „Akcelerácia aplikácií: Vyšší výkon pre koncových používateľov“. No tak, ľudia, ktorí to nechcú? Ak som tam vonku a pomáham vám bežať rýchlejšie, myslím, že som ten chlap, ktorý si po práci kúpil pivo v bare. Musí to byť celkom v pohode, ak chcete vstúpiť a urýchliť niekoho aplikáciu.
Je tu nejaká snímka o vás, zasiahla ma na Twitteri @ Eric_Kavanagh. Vždy sa snažím sledovať to, čo sa týka mňa, a vždy ma opakujem, ak ma spomínaš, tak ma neváhaj spomenúť.
Účelom tejto show je zamerať sa na rôzne aspekty podnikovej technológie a skutočne pomôcť definovať určité disciplíny alebo určité tváre, ak budete chcieť. Dodávatelia mnohokrát vyzdvihnú určité marketingové podmienky a budú hovoriť o tom, ako to robia alebo o čomkoľvek inom. Táto relácia bola navrhnutá tak, aby pomohla našim divákom pochopiť, čo softvérový nástroj musí mať, aby bol lídrom vo svojom priestore. Tento formát tvoria dvaja analytici. Každý je na prvom mieste, na rozdiel od briefingu, kde je predajca na prvom mieste. Každý z nich sa ujme toho, čo považuje za dôležité, aby ste vedeli o konkrétnom druhu technológie.
Dnes hovoríme o akcelerácii aplikácií. Budeme počuť od Dez Blanchfielda a tiež doktora Robina Bloora - dnes sme na celom svete - a potom sa Bill Ellis vytočí z väčšej oblasti Virginie. S tým ju odovzdám nášmu prvému moderátorovi, Dr. Bloorovi. Mimochodom sme tweetovali hashtag #podcast, takže neváhajte a tweetujte. Vziať to preč.
Robin Bloor: Dobre, ďakujem za úvod. Výkon aplikácií a úrovne služieb - to je druh oblasti, v tejto oblasti som v priebehu rokov vykonal veľa práce, v tom zmysle, že som skutočne vykonal strašnú prácu pri monitorovaní výkonnosti a vypracovaní v jednom tak či onak, ako sa pokúsiť vypočítať tieto úrovne. Je potrebné povedať, že dovtedy - predtým sme mali túto éru, keď ľudia stavali systémy v silách. V podstate množstvo práce, ktorú v skutočnosti musia urobiť, aby systém fungoval primerane dobre, ak to bolo v zásobníku, nebolo v skutočnosti príliš ťažké, pretože existuje veľmi malé množstvo premenných, ktoré musíte vziať do úvahy. Hneď, ako sme sa správne zapojili do siete, do rovnice vstúpila interaktívna a servisná orientácia. Je to trochu ťažké. Výkon môže byť jednorozmerný. Ak uvažujete len o aplikácii, ktorá opakovane vykonáva určitú cestu kódu, rozumne a včas sa cíti ako jednorozmerná vec. Hneď ako začnete hovoriť o úrovniach služieb, skutočne hovoríte o viacerých veciach súťažiacich o počítačové zdroje. Veľmi rýchlo sa stáva viacrozmerným. Ak začnete hovoriť o podnikových procesoch, podnikové procesy sa môžu spájať z viacerých aplikácií. Ak hovoríte o architektúre orientovanej na služby, daná aplikácia môže skutočne získať prístup k možnostiam viacerých aplikácií. Potom sa stáva veľmi komplikovanou vecou.
Pozrel som sa - dávno som nakreslil tento diagram. Tento diagram má najmenej 20 rokov. V podstate tomu hovorím Schéma všetkého, pretože je to spôsob, ako sa pozrieť na všetko, čo existuje v IT prostredí. Je to naozaj iba štyri kusy: používatelia, dáta, softvér a hardvér. Samozrejme, že sa časom menia, ale keď sa na to pozriete, v skutočnosti si uvedomíte, že v každej z týchto častí existuje hierarchická explózia. Hardvér áno, hardvér môže byť server, ale server sa môže skladať z možno viacerých procesorov, sieťových technológií a pamäte, a to je druh hrozného množstva radičov, ako sa to stane. Ak sa na to skutočne pozriete, všetko sa rozdelí na kúsky. Ak skutočne premýšľate o tom, že sa snažíte všetko zorganizovať, čo sa týka údajov, ktoré sa menia, zmeny výkonu softvéru, pretože sa mení hardvér, atď. A tak ďalej, v skutočnosti sa pozeráte na neuveriteľne ťažkú situáciu s rôznymi variantmi. Toto je krivka zložitosti. Samozrejme je to krivka zložitosti pre takmer všetko, ale videl som to kresliť znova a znova, keď hovorím o počítačoch. V zásade, ak umiestnite uzly na jednu os a dôležité spojenia na druhú os, skončíte krivkou zložitosti. Takmer nezáleží na tom, aké sú uzly a spojenia a čo urobí, ak chcete reprezentovať nárast objemu v telefónnej sieti.
V skutočnosti, keď hovoríme o uzloch v počítačovom prostredí, hovoríte o jednotlivých veciach, ktoré sa navzájom zaujímajú. Ukázalo sa, že zložitosť je otázkou rozmanitosti a rôznych obmedzení, ktoré sa snažíte dodržať. Tiež čísla. Keď čísla stúpajú, zbláznia sa. Včera som mal zaujímavý rozhovor, rozprával som sa s niekým - nemôžem spomenúť, kto to bol, ale na tom nezáleží - hovorili o webe, ktorý mal 40 000 - to sú štyri nuly, 40 000 - príklady databáz na webe. Len o tom premýšľajte - 40 000 rôznych databáz. Samozrejme jedinú vec, ktorú sme mali - mali samozrejme mnoho, tisíce aplikácií. Hovoríme o veľmi veľkej organizácii, ale nemôžem ju pomenovať. Naozaj sa na to pozeráte a vlastne sa snažíte tak či onak dosiahnuť úrovne služieb, ktoré budú pre všetkých viacerých používateľov adekvátne všade s rôznymi očakávaniami, ak budete chcieť. Je to zložitá situácia a všetko, čo skutočne hovorím, je, že tieto veci sú zložité. Čísla sa vždy zvyšujú. Obmedzenia sú určené obchodnými procesmi a obchodnými cieľmi. Všimli ste si, že sa očakávania zmenili.
Pamätám si, len čo Gmail, Yahoo mail a Hotmail, všetky tieto poštové systémy prišli, ľudia začali mať očakávania od svojich interných poštových systémov v rámci organizácie, ktoré si zaslúžia úroveň služieb týchto obrovských operácií s rozsiahlymi serverovými farmami mimo organizácii a začal byť pod tlakom, aby sa všetko také stalo. Dohody o úrovni služieb sú v skutočnosti jedna vec, ale očakávania sú ďalšou vecou a navzájom si navzájom bojujú v rámci organizácie, trápne. Toto je len obchodná perspektíva. V niektorých systémoch je optimálny čas odozvy jedna desatina sekundy ľudského času odozvy. Jedna desatina sekundy je doba, ktorú vám vyžaduje uhryznutie kobra. Ak stojíte pred kobrou a rozhodnete sa vás uhryznúť, je príliš neskoro, bude to preto, že nemôžete zareagovať ani o jednu desatinu sekundy. Jedna desatina sekundy je o čase, keď lopta opustí ruku nadhadzovača, aby sa dostal k chlapovi s pálkou. V podstate, keď vidí loptu hodenú, musí na ňu presne odpovedať. Ľudská reakcia, niečo zaujímavé. Softvér na softvér môže mať samozrejme vyššie očakávania.
Potom sa dostanete do niektorých situácií, o ktorých si myslím, že sú také situácie na trhu, kde je na prvom mieste miesto, kde je hodnota podniku. Je to ako by ste chceli predať konkrétnu akciu na akciovom trhu, napríklad, pravdepodobne preto, že si myslíte, že klesá a veľa ďalších ľudí si myslí, že klesá, dostanete najlepšiu cenu, ak sa dostanete na trh ako prvý. Existuje veľa situácií, zobrazovanie reklám a podobné veci, veľmi podobná situácia. Tento pohyb máte, pokiaľ ide o očakávania na úrovni služieb. Máte jednu vec, ktorá je akýsi sklenený strop pre ľudskú reakciu. Akonáhle je to softvér na softvér, ak máte túto stropnú situáciu, potom neexistuje žiadna najlepšia úroveň služieb. Rýchlejší ako každý iný je najlepší.
Dobre, myslím, že toto je posledná snímka, ktorú som robil, ale je to len preto, aby som vám poskytol obraz o komplexnosti, keď sa skutočne pozriete na požiadavky organizácie, službu. Máte, po ľavej strane tu máte správu systému, čo je sada softvéru, ktorý slúži na správu služieb, ktorý sa snaží spravovať úroveň služieb. Nad tým máte riadenie podnikovej výkonnosti. Ak sa pozriete sem dole, v oblasti automatizácie riadenia služieb, máte rozdrobené služby, ktoré sa vyvíjajú na štandardizované služby, ak skutočne chcete investovať do tohto druhu, ktorý sa vyvinie do integrovaných služieb, ktoré sa vyvinú na optimalizované služby., Ľudia väčšinou robia to, iba v ľavom dolnom rohu. Možno trochu riadenia služieb. Riadenie obchodného výkonu, veľmi zriedkavé. Roztrieštené, takmer všetko. Túto mriežku by vyplnil dokonalý svet. Prístrojové vybavenie - Spomenul som problém s optimalizáciou. Môžete optimalizovať časti systému a nie je to dobré pre celý systém. Ak urobíte srdce optimálnym, vaša krv môže cirkulovať príliš rýchlo po zvyšok vašich orgánov. To je problém s veľkými organizáciami a úrovňami služieb. Bez sofistikovaných nástrojov sa jednoznačne nedosiahne, pretože premenné sa práve dostali - nuž je príliš veľa premenných na to, aby sa dali optimalizovať.
Po tom, čo to povediem, dúfam, že pôjdem na Deza, ktorý bude hovoriť o niečom inom.
Dez Blanchfield: Ďakujem, Robin. Rovnako ako Dr. Robin Bloor som strávil príliš veľa rokov premýšľaním o výkone veľmi komplexných systémov vo veľmi veľkom meradle. Pravdepodobne nie úplne v rovnakom rozsahu ako Robin, ale výkon je dennou témou a je súčasťou našej DNA, aby chcel výkon, aby zo všetkého získal to najlepšie. V skutočnosti som použil grafiku jednej z mojich najobľúbenejších vecí na svete, závodných automobilov Formule I, kde celá planéta na chvíľu sedí a sleduje autá, ktoré veľmi rýchlo obchádzajú kolesá. Každý jeden aspekt, neexistuje žiadny aspekt vzorca I, ktorý nie je špecificky o získavaní výkonu. Mnoho ľudí športuje poo, pretože si myslia, že je to strata peňazí. Ukázalo sa, že auto, ktoré ideme každý deň, o víkendoch a škole do školy deti, je odvodené z vývoja a výskumu založeného na výkone. Je to druh života automobilových závodov Formuly I. Každodenná technológia, každodenná veda, často pochádza z niečoho, čo sa zameriava výlučne na vysoký výkon.
Realita je však taká, že náš nový „vždy na“ svet, ktorý si vyžaduje 100 percentnú dostupnosť, ako už bolo spomenuté Robina, s vecami, ako je zavedenie webmailu a ďalších služieb, ktoré považujeme za samozrejmé v nepretržitom priestore, a teraz očakávame, že v naše podnikateľské a pracovné prostredie. Realita je taká, že byť hore neznamená vždy, že spĺňate dohodu o úrovni služieb. Beriem to na vedomie, že je potrebné riadiť výkonnosť aplikácií a dohody o dostupnosti služieb, ktoré prešli v poslednom desaťročí zásadným posunom. Už sa nesnažíme len starať o výkon jedného systému. Keď bol svet o niečo jednoduchší, mohli by sme sa ocitnúť v situácii, keď jeden server so spustením viacerých služieb môže byť sledovaný naživo a podpora bola pomerne jednoduchá. Mohli by sme - a tu je moje, to, čo sme sa obávali, keď som bol napríklad pred mnohými rokmi správcom systému - by sme sa rozhliadali, je služba zvyčajne v poriadku a reaguje? Môžem sa napríklad prihlásiť do terminálu? Reaguje operačný systém a môžem zadávať príkazy? Sú aplikácie spustené? Môžem vidieť procesy a pamäť pri robení vecí a I / O v sieti atď.? V dňoch sálových počítačov ste počuli pásky, ktoré sa rozprestierajú na zips a vypadáva z nich papier.
Reagujú aplikácie a môžeme sa prihlásiť a robiť s nimi veci? Môžu sa používatelia pripojiť k niektorým z týchto serverov? Ide to. Sú dosť zásadné, viete. Potom pár z nich - je služba technickej podpory zelená? Pretože ak nie, potom všetko beží dobre a kto dostane šišky? Život bol v tých časoch naozaj jednoduchý. Dokonca aj v tých dňoch, a potom hovorím s 20–30 rokmi, bola zložitosť stále veľmi vysoká. Mohli by sme pomerne jednoduchým spôsobom riadiť dohody na úrovni služieb a dohliadať na výkon. Už to nemôžeme robiť ručne, ako na to Robin pripomenul. Výzva je príliš veľká. Faktom je čas, keď niekoľko dobrých aplikácií, správcov, systémovej siete a databázy môžu správcovia monitorovať a plniť výkonnostné SLA. SLA sú tak ďaleko, že som včera v noci zápasil so záverečnými poznámkami, aby som si dokonca pomyslel na rok, keď sa mi naposledy podarilo pozrieť sa na systém veľmi zložitého zväzku a dať mu zmysel a dokonca pochopiť, čo bolo deje pod kapotou a ja pochádzam z hlboko technického zázemia. Neviem si predstaviť, aké to je každodenne čeliť administratívnym spôsobom.
Čo sa stalo? V roku 1996 sa aplikácie založené na databáze transformovali pomocou internetového boomu. Mnoho z nás to prešlo. Aj keď ste neboli na internetovom rozmachu, môžete sa jednoducho len rozhliadnuť a uvedomiť si, že v každodennom živote, že teraz všetko pripojíme na internet. Myslím, že máme hriankovač, ktorý zjavne prichádza s možnosťou pripojenia na sieť Wi-Fi, čo je smiešne, pretože nepotrebujem svoj hriankovač pripojený na internet. V 2000-tych rokoch, najmä na začiatku 2000-tych rokov, sme sa museli vyrovnať s týmto masívnym nárastom komplexnosti pri poskytovaní služieb v boomu dot-com. Potom nasledovala ďalšia smiešna nepríjemná iskra na webe 2.0, kde prišli smartfóny a teraz aplikácie boli v našich rukách 24/7 a boli vždy zapnuté.
Teraz je rok 2016, konfrontujeme sa s ďalším dopytom vo forme cloudu a veľkých dát a mobility. Sú to také systémy, ktoré sú také veľké, že je často ťažké porozumieť im a dať ich do jasnej angličtiny. Keď premýšľame o skutočnosti, že niektoré z veľkých jednorožcov, o ktorých hovoríme, majú desiatky stoviek petabajtov údajov. Toto je celé poschodie miesta na disku a úložný priestor len na uloženie vašich e-mailov, obrázkov a sociálnych médií. Alebo v niektorých prípadoch, v dopravnej a prepravnej logistike, je to všetko v bankovníctve, kde sú vaše peniaze, kde je váš príspevok alebo kde je to, čo ste si kúpili na eBay. Ďalšou veľkou vlnou, ktorej sa chystáme čeliť, je táto veľmi ťažká výzva internetu vecí.
Ak to nebolo dosť zlé, chystáme sa vybudovať umelú inteligenciu a kognitívne výpočty na takmer všetko. Dnes hovoríme so strojmi Siri a Google. Viem, že Amazon má jeden svoj vlastný. Baidu majú jedno z týchto zariadení, s ktorými môžete hovoriť, prevádzajú ho na text, ktorý ide do normálneho systému, databáza vytvorí dotaz a vráti sa a obráti proces. Zamyslite sa nad zložitosťou, ktorá s tým súvisí. Realita je taká, že zložitosť dnešného štandardného aplikačného balíka je ďaleko nad ľudskými schopnosťami. Keď premýšľate o všetkom, čo sa stane, keď stlačíte tlačidlo na vašom smartfóne alebo tablete, hovoríte s ním, prevádza to na text, spúšťa celú cestu na internet do back-end systému, front-end dostane to prevádza na dopyt, spúšťa dotaz cez aplikačný zásobník, prechádza databázou, zasiahne disk, vráti sa späť a v strede je sieť operátora, kde je centrum stavu miestnej siete. Zložitosť je šialená.
Efektívne to tvrdíme ako hyperscale. Zložitosť a rýchlosť hyperskály je len zavlažovanie očí. Aplikácie a databázy sa stali takými rozsiahlymi a komplexnými, že riadenie výkonnosti je v skutočnosti veda sama o sebe. Mnohí to označujú ako raketovú vedu. Máme technológiu na mieste, máme technológiu mimo pracoviska, máme celý rad možností dátového centra; fyzické a virtuálne. Máme fyzické a virtuálne servery, máme cloud, máme infraštruktúru ako službu a platformu, pretože služba a softvér ako služba je vec, ktorú teraz považujeme za samozrejmosť. Ten, softvér ako služba, sa na chvíľu pred desiatimi rokmi stal strašidelným, keď si finanční riaditelia a časti organizácie uvedomili, že si môžu vyzdvihnúť svoju kreditnú kartu a kúpiť si veci sami a ísť okolo CIO a skutočne sme to nazvali „tieňom“ IT “a vedúci oddelenia IT sa teraz snažia previnúť túto kontrolu späť a zápasiť späť.
V infraštruktúre máme softvérovo definované siete, virtualizáciu sieťových funkcií, pod ktorými máme pravdepodobne viac ako teraz, teraz máme mikro služby a aplikácie aktívnych služieb. Keď kliknete na adresu URL, na konci tejto adresy URL je veľa obchodných logík, ktoré popisujú, čo je potrebné na jej skutočné doručenie. Nemusí to nevyhnutne mať vopred zostavenú logiku. Na jednej strane máme tradičné databázy, ktoré sú veľmi, veľmi veľké. Infraštruktúru a ekosystémy Hadoop máme v druhom spektre, ktoré je také veľké, že, ako som už povedal, viete, ľudia teraz hovoria o stovkách petabajtov údajov. Pokiaľ ide o zariadenia, ktoré prenášajú počítače, notebooky a telefóny a tablety, máme komplexnú mobilitu.
Máme BYOD v niektorých uzavretých prostrediach a stále viac, pretože skúsení ľudia z Gen Y prinášajú svoje vlastné zariadenia. Len sme im umožnili hovoriť o webových rozhraniach. Buď cez internet alebo cez Wi-Fi, v kaviarni na prízemí máme bezplatné Wi-Fi pripojenie na internet, keď majú kávu. Alebo naše interné Wi-Fi. Stroj-to-machine je vždy prítomný. To nie je priamo súčasťou internetu vecí, ale tiež s tým súvisí. Internet vecí je úplne nová hra zložitosti, ktorá je ohromujúca. Umelá inteligencia, a ak si myslíte, že to, s čím teraz hráme, so všetkými Siri a ďalšími súvisiacimi zariadeniami, s ktorými hovoríme, je zložité, počkajte, kým sa nedostanete do situácie, keď uvidíte niečo, čo sa volá Olli, čo je trojrozmerný objekt. tlačený autobus, ktorý pojme asi šesť ľudí a môže sa sám riadiť mestom, môžete s ním hovoriť po anglicky a bude vám hovoriť späť. Ak zasiahne premávku, rozhodne sa odbočiť doľava alebo doprava z hlavnej oblasti, kde je premávka. Keď sa to zmení a vy sa obávate, prečo je odbočený vľavo alebo vpravo od hlavnej cesty, povie vám: „Neboj sa, idem doľava. Je tu doprava a ja sa budem obísť. “
Riadenie výkonu všetkých systémov v ňom a všetka komplexnosť, sledovanie, kam tieto údaje idú, či ide o databázu, všetky prepojenia a všetky príslušné bity, je iba záhadou. Realita je taká, že riadenie výkonu a SLA pri dnešnej rýchlosti a rozsahu vyžaduje nástroje a systémy a v predvolenom nastavení to už nie je niečo, čo by ste si mysleli, že by bolo pekné mať nástroj - je to nevyhnutný predpoklad; je to absolútne nevyhnutné. Tu je niečo, čo je len malý príklad, zoznam vývojových diagramov aplikácií na vysokej úrovni pre cloud s otvoreným softvérom OpenStack. Toto je iba veľký kus. Nejde iba o servery a databázu. To je miesto, kde každá malá modrá škvrna predstavuje zhluky vecí. V niektorých prípadoch logika súborov a serverov alebo stovky databáz alebo samozrejme nie viac ako desiatky tisíc malých častí aplikácií. To je malá verzia. Keď začnete premýšľať o zložitosti, ktorá sa v tomto objavuje, je to celkom šokujúce. Dnes, dokonca aj vo veľkom dátovom priestore, vložím iba niekoľko obrazoviek iba značiek. Keď premýšľate o všetkých kúskoch, ktoré tu musíme zvládnuť, nehovoríme iba o jednej značke, jedná sa o značky v oblasti veľkých dát a o najlepšej značke, nielen o každej malej alebo otvorenom zdroji. Vyzeráte a myslíte si, že je to docela ohromujúci graf.
Pozrime sa na pár vertikálov. Zoberme si napríklad marketing. Toto je podobný graf, ale zo stohov technológií, ktoré sú k dispozícii iba v marketingovej technológii. Toto je graf za rok 2011. Tu je verzia 2016. Len premýšľajte o tom, je to len počet značiek výrobkov, ktoré môžete prevádzkovať pre technológiu v súvislosti s marketingovou technológiou. Nie zložitosť systémov vo vnútri, nie rozdielna aplikácia a web, vývoj a sieť a všetky ostatné. Len značka. Pred rokom, pred piatimi rokmi, tu je dnes. Bude to len horšie. Teraz sme v realite, ľudia jednoducho nemôžu zabezpečiť všetky dohody na úrovni služieb. Nemôžeme sa ponoriť do dosť podrobností, dostatočne rýchlo av potrebnom rozsahu. Tu je príklad toho, ako monitorovacia konzola vyzerá teraz. Je to ako takmer dvadsať nepárne obrazovky zlepené dokopy, že sú jednou z veľkých, veľkých premietaných obrazoviek monitorujúcich každý malý kúsok. Teraz je to zaujímavé tu, nespomeniem značku, ale táto monitorovacia platforma monitoruje jednu aplikáciu v logistickom a prepravnom prostredí. Iba jedna aplikácia. Ak uvažujete o tom, o čom Robin hovoril, kde organizácie teraz môžu mať v produkčných prostrediach 40 000 databáz. Viete si len predstaviť, aké by mohlo byť 40 000 verzií tejto zbierky monitorov monitorujúcich jednu aplikáciu? Je to veľmi odvážny svet, v ktorom žijeme. Ako povedal Robin a ja absolútne, stopercentne sa ozýva, že bez správnych nástrojov, bez správnej podpory a ľudu na stole, ktorý tieto nástroje používa, je výkon aplikácií stratená hra pre ľudí a musí sa to robiť pomocou nástrojov a softvéru.
S tým pôjdem k našim priateľom v IDERA.
Eric Kavanagh: Dobre, Bill.
Bill Ellis: Ďakujem. Tu zdieľam svoju obrazovku. Myslím, že niekto môže potvrdiť, že vidíte moju obrazovku?
Robin Bloor: Áno.
Eric Kavanagh: Vyzerá to dobre.
Bill Ellis: Ďakujem. Jednu vec, o ktorej hovoril, bolo, že na ňu naozaj nemôžem čakať. Jedna vec, o ktorej som nikoho nepočul, je, čo sa stane, keď sneží? Zaujímalo by ma, či si inžinieri v Kalifornii uvedomili, že v iných častiach krajiny trochu sneží.
Dez Blanchfield: Páči sa mi to, budem si na to pamätať.
Eric Kavanagh: Typická míľa za hodinu.
Bill Ellis: Sme tu, aby sme hovorili o správe výkonnosti aplikácií v zložitom prostredí. Jedna vec, o ktorej by som rád hovoril, je veľa ľudí, keď hovoria o výkone, povaha reakcie je, hej viac serverov, viac CPU, viac pamäte atď. Druhou stranou tejto mince je efektivita spracovania. Naozaj, to sú dve strany tej istej mince a my sa na ne pozrieme. Konečným cieľom je splniť dohody o úrovni služieb pre obchodné transakcie. Nakoniec všetka táto technológia existuje pre podnikanie. Hovorili sme o tom, že máme prvú databázu riadenia výkonnosti v odvetví. Ideálne je zapadnúť do ideálnej formy výkonu a riadiť ju od začiatku životného cyklu aplikácií.
Témy sa skutočne scvrknú na štyri kusy; jeden je proces riadenia výkonnosti. Hovorili sme so všetkými a každý má nástroje. Ak nemajú nástroje, majú skripty alebo príkazy, ale chýba im kontext. Kontext jednoducho spája bodky cez aplikačné balíčky. Tieto aplikácie pre - sú založené na prehliadači. Sú veľmi pevne spojené od úrovne k úrovni. Interakcia úrovní je tiež nevyhnutná. Potom hovoríme o obchodnej transakcii. Zabezpečíme zviditeľnenie nielen pre technických pracovníkov, ale aj pre vlastníkov aplikácií a manažérov operácií.
Mám pár prípadových štúdií, aby som sa s vami podelil o to, ako ich zákazníci použili. Toto je veľmi praktická časť prezentácie. Pozrime sa, čo sa zvyčajne deje. Páči sa mi diagram - bolo to ako neuveriteľná koláž technológií. Počet technológií v dátovom centre sa práve rozrástol, rozrástol a rozrástol. Medzitým sa o to konečný užívateľ nezaujíma a je mu nevšímavý. Chcú len vykonať transakciu, mať ju k dispozícii, mať ju rýchlo dokončenú. Typicky sa stáva, že odborníci v oblasti IT nevedia, že koncoví používatelia dokonca mali problém, kým sa sami neodhlásia. To začína akýsi časovo náročný, pomalý proces a často frustrujúci. Deje sa to, že ľudia otvoria svoje nástroje a pozerajú sa na podmnožinu svojho súboru aplikácií. S touto podmnožinou je veľmi ťažké odpovedať na najjednoduchšiu otázku. Je pre vás obvyklé mať problém? Aká je to transakcia? Kde v zásobníku aplikácií je úzke miesto? Keď trávite celý čas, hľadáte rad po vrstvách a nie ste schopní odpovedať na tieto otázky, skončíte tým, že trávite veľa času a energie, veľa personálu, finančných prostriedkov a energetický druh zisťovania.
Aby sa to vyriešilo, aby sa zabezpečil lepší spôsob, čo presne robí, je v skutočnosti uskutočniť transakciu sledovania koncového používateľa, zachytáva o tom metaúdaje, sleduje transakciu cez sieť, do webového servera, do obchodnej logickej úrovne a Podporujeme .NET a ABAP a PeopleCode a E-Business Suite vo viacvrstvových aplikáciách, ktoré nakoniec všetky transakcie budú interagovať so systémom záznamu. Či už ide o vyhľadávanie zásob, odpracovaný čas na podávanie správ, vždy pracujú s databázou. Databáza sa stáva základom výkonnosti podniku. Databáza sa zase spolieha na úložisko. Na čo odpovedajú metaúdaje o transakciách, kto, ktorá transakcia, kde v zásobníku aplikácií, a potom máme hĺbkovú viditeľnosť na úrovni kódu, aby sme vám ukázali, čo sa vykonáva. Tieto informácie sa zaznamenávajú nepretržite a ukladajú do databázy riadenia výkonnosti - ktorá sa stáva jediným hárkom hudby pre všetkých, aby videli, čo sa deje. Existujú rôzni ľudia a organizácie, ktoré sa starajú o to, čo sa deje: technickí odborníci, vlastníci aplikácií, nakoniec samotný podnik. Ak sa vyskytne problém, chcete získať informácie o tejto transakcii.
Skôr ako sa pozrieme na investičné transakcie, chcem vám ukázať, ako by sa to mohlo javiť rôznym ľuďom v organizácii. Na úrovni riadenia môžete mať prehľad o viacerých aplikáciách. Možno budete chcieť vedieť o zdraví, ktoré sa počíta na základe dodržiavania SLA a dostupnosti. Toto zdravie neznamená, že všetko funguje na 100%. V tomto prípade je priestor, kde môžete vidieť, že investujúca transakcia je vo výstražnom stave. Teraz, trochu hlbšie, možno v oblasti podnikania, by ste chceli mať nejaké ďalšie podrobnosti o jednotlivých transakciách, keď porušujú SLA, počty transakcií, atď. Operačný tím bude chcieť byť o tom upovedomený prostredníctvom upozornenia na niektoré zoradiť. Máme zabudované výstrahy o výkonnosti. Skutočne merame výkon v prehliadači koncového používateľa. Či už to dokážeme Internet Explorer, Chrome, Firefox, atď., Dokážeme to zistiť, to je odpoveď na prvú otázku: má koncový používateľ problém?
Poďme sa ponoriť a uvidíme, čo ešte môžeme o tom ukázať. Ľudia, ktorí sa zaujímajú o vystúpenie, by otvorili program Precise. Vyhodnotili transakcie. Pozreli by sa do stĺpca SLA, aby identifikovali transakcie, ktoré nie sú v súlade so SLA. Mohli by vidieť koncových používateľov, ktorých sa to týka, ako aj to, čo táto transakcia urobila, keď prešla aplikáciou. Spôsob, akým dešifrujete tieto hieroglyfy, je prehliadač, adresa URL, adresa U je adresa URL, čo je vstupný bod do JVM. Teraz tento konkrétny JVM vyvolá volanie webového servera do druhého JVM, ktorý potom vykoná príkaz SQL. Toto je jednoznačne problém s databázou, pretože tento príkaz SQL bol zodpovedný za 72 percent času odozvy. Zameriavame sa na čas. Čas je mena výkonu. Je to, ako koncoví používatelia zažívajú, či veci fungujú pomaly alebo nie, a je to miera spotreby zdrojov. Je to veľmi šikovný; je to druh jednej metriky, ktorá je najdôležitejšia pre hodnotenie výkonnosti. Ak je tento problém odovzdaný DBA, nejde iba o problém s databázou, ale o tento príkaz SQL. O tomto kontexte som hovoril.
Teraz, vyzbrojený týmito informáciami, môžem ísť a analyzovať, čo sa stalo. V prvom rade vidím, že os y je časom cez deň. Prepáčte, os y je čas odozvy, os x je čas cez deň. Vidím, že existuje problém s databázou, existujú dva výskyty, vráťte sa k tomuto toku, vyberte tento príkaz SQL a choďte do expertného pohľadu, kde vám program Precise dokáže ukázať, čo sa deje, jeho ovládacie prvky, ako dlho trvá tento kód vykonať. V úrovni databázy je to plán vykonávania. Všimnite si, že program Precise vybral skutočný plán vykonávania, ktorý bol použitý v čase vykonávania, ktorý sa líši od odhadovaného plánu, ktorý by bol v čase, keď bol daný plán, a nie v čase vykonávania. Môže alebo nemusí odrážať skutočnosť, že databáza skutočne bola.
Teraz je tu analýza času odozvy pre príkaz SQL. Deväťdesiat percent času stráveného skladovaním; v CPU bolo použitých desať percent. Vidím text príkazu SQL, ako aj správu o zisteniach. Text príkazu SQL v skutočnosti začína odhaliť niektoré problémy s kódovaním. Je to hviezda; ktorý vráti všetky riadky - ospravedlňte ma, všetky stĺpce z riadkov, ktoré boli vrátené. Vraciame ďalšie stĺpce, ktoré aplikácia môže alebo nemusí potrebovať. Tieto stĺpce spotrebujú priestor a prostriedky na spracovanie. Ak spustíte SAP, jednou z veľkých zmien, pretože databáza HANA je stĺpcová, je to, že v podstate prepíšete SAP tak, aby si nevybral výber hviezd, takže môžu výrazne znížiť spotrebu zdrojov. Je to v podstate niečo, čo sa deje veľa času aj v domácich aplikáciách, či už Java, .NET atď.
Táto obrazovka vám ukáže, kto, čo, kedy, kde a prečo. Prečo sa to týka, ako napríklad príkaz SQL a plán vykonávania, ktorý vám umožňuje riešiť problémy. Pretože presnosť beží nepretržite, môžete skutočne merať pred a po, na úrovni príkazov SQL, na úrovni transakcií, takže buď môžete merať pre seba, ako aj prostredníctvom vlastníkov aplikácií a pre správu, že ste problém vyriešili., Táto dokumentácia je skutočne užitočná. V tomto zásobníku aplikácií je veľa zložitosti. Z mnohých aplikácií, v skutočnosti všetci, s ktorými sme hovorili, bežia aspoň časť aplikačného balíka pod VMware. V tomto prípade sa pozerajú na aplikáciu zákazníckeho servisu, pozerajú sa na čas transakcie a korelujú so spomalením je virtualizačná udalosť. Presne sleduje všetky virtualizačné udalosti. Máme plug-in na vCenter vyzdvihnúť to.
Sme tiež schopní odhaliť spor. Obsah je iný ako využitie. V skutočnosti ukazuje, kedy možno hlučný sused ovplyvňuje vaše hosťujúce VM, v kontexte aplikácie zákazníckeho servera. Teraz som schopný vŕtať sa a získať informácie a v skutočnosti vidím dva VM, ktoré sa v tomto prípade zaujímajú o prostriedky CPU. To mi umožňuje zviditeľniť sa, aby som sa mohol pozrieť na plánovanie. Hostiteľa VM môžem umiestniť na iný fyzický server. Všetky tieto typy vecí, na ktoré by ste mohli odpovedať, a potom sa navyše môžem pozrieť na efektívnosť kódu, aby som ho mohol používať menej CPU. Myslím si, že mám v tejto prezentácii celkom dobrý príklad toho, ako niekto dokázal znížiť spotrebu procesora o rádovo veľké množstvo.
To bol VMware. Poďme do samotného kódu, kódu aplikácie. Presné vám bude môcť ukázať, čo sa deje v jazykoch Java, .NET, ABAP kód, E-Business, PeopleCode atď. Toto sú vstupné body do, v tomto prípade, do WebLogic. Tu dole je správa o zisteniach, ktorá mi hovorí, že je to potrebné na tieto EJB, na ktoré sa musíte pozrieť, a povie mi, že sa v tomto systéme stalo aj uzamykanie. Znova sa v rámci obchodnej logickej úrovne ukážeme, čo sa deje. V tomto prípade sa pozerám na konkrétne prípady; Podporujem aj zoskupovanie. Ak máte spustených početné JVM, môžete sa pozrieť na klaster ako celok alebo sa pozrieť na úzke miesta v jednotlivých JVM.
Keď sa dostanete do zámku, môžem sa dostať do výnimiek. Výnimka je trochu iná ako problém s výkonom. Výnimky sa zvyčajne spúšťajú veľmi rýchlo. Pretože existuje logická chyba a po jej zasiahnutí sa táto chyba skončí. Dokázali sme zachytiť stopu zásobníka v najlepšej výnimočnosti, mohlo by to ušetriť veľa času, keď sa snaží zistiť, čo sa deje, jednoducho tu máte stopu zásobníka. Tiež sme schopní zachytiť úniky pamäte. Súčasťou riešenia je aj databázová úroveň, môžem ísť, môžem vyhodnotiť inštanciu databázy. Opäť platí, že os y je miestom, kde sa strávil čas, os x je čas cez deň. Existuje správa o zisteniach, ktorá mi automaticky povie, čo sa v systéme deje a na čo by som sa mohla pozrieť.
Jedna z vecí, ktorá sa týka správy o zisteniach spoločnosti Precise, sa nezaoberá iba protokolmi alebo stavom čakania - zameriava sa na všetky stavy vykonávania vrátane CPU a vracia informácie z úložiska. Úložný priestor je veľmi dôležitou súčasťou aplikačného zásobníka, najmä s príchodom pevného stavu. Mať informácie týmto smerom môže byť veľmi užitočné. V prípade určitých úložných jednotiek môžeme skutočne podrobne rozobrať a ukázať, čo sa deje na úrovni jednotlivých zariadení. Tento druh informácií - opäť je to hlboká viditeľnosť; rozsah je široký - poskytnúť vám len toľko informácií, aby ste mali viac pákového efektu ako profesionál v oblasti výkonu aplikácií, takže môžete optimalizovať svoje aplikácie end-to-end, aby ste vyhoveli týmto obchodným transakciám.
Mám pár prípadových štúdií, ktoré som s vami chcel zdieľať. Plavíme sa veľmi rýchlo; Dúfam, že idem v poriadku. Keď už hovoríme o úložisku, každý čas mení hardvér. Existuje záruka na hardvér. Poskytlo to skutočne to, čo vám povedal predajca? Môžete to vyhodnotiť pomocou Presného. Vstúpite a čo sa tu stalo, v podstate vložili novú úložnú jednotku, ale keď sa správcovia úložných priestorov pozerali len na úroveň úložnej jednotky, videli veľa sporov a mysleli si, že by mohol byť problém s touto novou úložnou jednotkou., Pri pohľade na viac z hľadiska end-to-end, presne ukázať, kde by sa to skutočne stalo. Skutočne prešli z priepustnosti približne 400 megabajtov za sekundu, kde úložisko zodpovedalo za 38 percent času odozvy, takže je dosť vysoké. S novou skladovacou jednotkou sme skutočne zvýšili priepustnosť na šesť, sedemsto megs za sekundu, v podstate dvojnásobok, a my sme schopní znížiť podiel skladovacej úrovne na čas transakcie na polovicu. Dokážem to skutočne graficky znázorniť predtým, toto je obdobie prerušenia a potom nasledujúce.
Znova teda dokumentácia, ktorá dokazuje, že investícia do hardvéru stála za to, a dodali tak, ako očakával tento konkrétny predajca. Je tu všetko, kvôli zložitosti, množstvu vecí, môžu sa vyskytnúť všetky druhy vecí. V tomto prípade mali skutočne situáciu, keď všetci obviňovali DBA, DBA bola ako „No, nie tak rýchlo.“ Tu sa skutočne pozeráme na aplikáciu SAP, myslím si, že tento typ scenára je dosť bežný, Stalo sa to, že vyvíjali vlastnú transakciu pre používateľa. Užívateľ je rád, „Toto je také pomalé“. Programátor ABAP - to je programovací jazyk v SAP - povedal: „Toto je problém s databázou.“ Skončili tým, že otvorili program Precise; zmerali tohto koncového používateľa 60 sekúnd, tak dobre za minútu. Na zadnom konci bolo strávených päťdesiattri sekúnd. Vŕtali sa do zadnej časti a vlastne dokázali odhaliť príkaz SQL uvedený v zostupnom poradí.
Tento najvyšší príkaz SQL, ktorý je zodpovedný za 25 percent spotreby prostriedkov, jeho priemerná doba vykonávania je dve milisekundy. Túto databázu nemôžete viniť. Vieš, hej, nie tak rýchlo, chlap. Otázka znie, prečo je toľko popráv? Odrazili to späť na ABAP, vošiel dnu, pozrel sa do hniezda slučky, zistil, že volajú do databázy na nesprávnom mieste, v podstate vykonali zmenu, testovali zmenu a teraz je nový čas odozvy päť sekúnd. Trochu pomaly, ale mohli s tým žiť. Oveľa lepšie ako 60 sekúnd. Niekedy, len fretka, je to kód aplikácie, je to databáza, je to úložisko? Toto sú oblasti, v ktorých precízny kontext transakcií typu „end-to-end“ nastáva práve tam, kde nastáva presná situácia. Tieto veci v podstate ukončíte.
Pozerám sa na ten čas, vyzerá to, že ešte stále máme trochu času na to, aby sme si ich prešli ešte pár. Týmto prúdim. Táto aplikácia sa vyvíjala viac ako rok. Keď vstúpili do QA, videli, že webové servery boli maximálne sto percent a vyzeralo to, že aplikácia nemôže bežať pod VMware. Prvá vec, ktorú všetci povedali, bola: „Dajte to na fyzický; nedá sa spustiť pod VMware. “Presnosť im v skutočnosti ponúkla ďalšie spôsoby riešenia problému. Pozreli sme sa na transakcie, videli sme volanie webového servera, prichádza ako ASMX v IIS.NET. V skutočnosti odhalil základný kód. Vidíš to tam, kam smerujem? Toto je 23 dní, 11 hodín. Wow, ako je to možné? Každá výzva trvá 9, 4 sekundy a táto vec sa vyvolá 215 000 krát. Pre každé vyvolanie používa 6 sekúnd CPU. Toto je dôvod, tento kód je dôvod, prečo by sa táto vec nikdy nemala škálovať. V skutočnosti sa nemohla fyzicky zmenšiť.
Čo urobili, vrátili sa k vývojárom a povedali: „Môže niekto urobiť zmenu?“ Mali druhú súťaž, vyskúšali rôzne návrhy a prišli s návrhom, ktorý bol schopný bežať veľa efektívnejšie. Nový dokončil jeden bod, o niečo menej ako dve sekundy, s dvoma stotinami sekundy v CPU. Teraz by sa to mohlo škálovať a mohlo by to bežať na farme VMware. Dokázali sme to v zásade zdokumentovať na úrovni kódu aj transakcie. Toto je druh predtým a potom potom. Teraz, keď tu vidíte stĺpcový graf zásobníka, ktorý zobrazuje web, .NET a databázu, teraz komunikujete s databázou. Toto je profil, ktorý by ste očakávali od aplikácie, ktorá bežala bežnejšie.
Dobre, vyberám a vyberám ďalšie veci, ktoré ti môžem ukázať. Mnoho ľudí sa to páči, pretože to obťažuje veľa obchodov. Ak nemôžete splniť obchodnú zmluvu SLA a všetci sú radi: „Pomôžte nám.“ V tomto obchode sa vyskytla situácia, keď je obchodná zmluva SLA v objednávkach prijatých do 15:00, je odoslaná tento deň. Je skutočne dôležité, aby dostávali objednávky a sklad je veľmi zaneprázdnený. Obrazovka zákazky odberateľa JD Edwards bola zmrazená a môžete získať veľmi dobrý nápad, že ide o systém riadenia maloobchodných zásob just-in-time. Prázdne police sú v maloobchode neprijateľné. Musíš tam mať tovar, aby si ho mohol predať. Urobili sme to, že sme sa ponorili, v tomto prípade sa pozeráme na databázu servera SQL. Vzhľad je rovnaký, či už ide o SQL, Oracle, DB2 alebo Sybase.
Identifikovali sme výber z PS_PROD a dokážeme zachytiť trvanie, toľko, koľko vykonávajú. Tmavomodrá zhoda s kľúčom, ktorý hovoril, že nečakajú na nejaký čakací stav alebo na protokolovanie alebo dokonca na ukladanie dát - táto vec je viazaná procesorom. Sledovali sme príkaz SQL do roku 34301, takže pri každom jeho vykonaní zvyšujeme naše počítadlá, aby sme ho mohli sledovať. To znamená, že máme podrobnú históriu a ja k nej mám prístup kliknutím na toto tlačidlo ladenia. Toto je karta histórie. Táto obrazovka zobrazuje priemerné trvanie verzus zmeny. Streda, štvrtok, piatok bolo priemerné trvanie asi dve desatiny sekundy. Veľmi málo obrazoviek zamrzne, sú schopné splniť obchodné SLA. Poď 27. februára, niečo sa zmení a zrazu je tu čas na vykonanie, a to je vlastne dosť pomalé na to, aby spôsobilo časové oneskorenie, ktoré má za následok zamrznutie obrazovky. Presné udržiavaním podrobnej histórie vrátane plánu vykonávania a všeobecných zmien indexov tabuľky, ak sa tento SQL používa. Podarilo sa nám zistiť, že prístupový plán sa zmenil 27. februára. Od pondelka do piatkového zlého týždňa. Príďte 5. marca, prístupový plán sa znova zmenil. Toto je dobrý týždeň. Táto ružová hviezda hovorí o aktualizovanom objeme.
Vidíte tu počet riadkov v príslušných tabuľkách rastie, čo je typické pre firmu. Chcete, aby vaše tabuľky rástli. Ide o to, že príkazy sú syntaktické, prídu príkazy SQL, optimalizátor sa musí rozhodnúť, čo robiť a zvoliť, keď je plán vykonávania rýchly, zvoliť iný plán vykonávania, keď je pomalý, čo spôsobuje zamrznutie obrazovky. Pokiaľ ide o hlbokú technológiu, potrebujem vedieť, čo je plán vykonávania, a program Precise ho preberie kompletne s dátumom a časovou pečiatkou. Toto bolo rýchle a efektívne, toto bolo pomalé a neefektívne. Toto spojenie filtra jednoducho používa oveľa viac CPU na zladenie, aby urobil tento konkrétny príkaz SQL. Stále majú rovnaký konečný účinok, ale tento má v podstate pomalší a menej efektívny recept na dosiahnutie sady výsledkov. Takže sme prešli. Hej, máme čas na pár ďalších?
Eric Kavanagh: Áno, choďte na to.
Bill Ellis: Dobre, skočím dopredu. Jedna vec, ktorú chcem, aby ste si všimli, hovorili sme o hardvéri, hovorili sme o SAP, hovorili sme o .NET, hovorili sme o prostredí JD Edwards a prostredí Java-SQL Server. Toto je SAP, tu sa pozeráme na PeopleSoft. Presná podporná matica je široká a hlboká. Ak máte aplikáciu, viac ako pravdepodobné, môžeme ju vybaviť tak, aby poskytovala túto úroveň viditeľnosti. Jednou z najväčších zmien, ktorá sa práve teraz deje, je mobilita. PeopleSoft predstavil mobilitu s Fluid UI. Fluid UI používa systém veľmi odlišne. Táto aplikácia sa vyvíja. Fluid UI - čo robí z pohľadu riadenia je to, že umožňuje koncovým používateľom používať ich telefón a výrazne zvyšuje produktivitu. Ak máte stovky alebo tisíce alebo viac zamestnancov, ak môžete zvýšiť svoju produktivitu, o 1 až 2 percentá, môžete mať obrovský vplyv na mzdy a všetko ostatné. Čo sa stalo, tento konkrétny obchod vyšiel z používateľského rozhrania PeopleSoft Fluid UI. Teraz, keď hovoríme o zložitosti, ide o zásobník PeopleSoft. Jedna aplikácia, minimálne šesť technológií, početných koncových používateľov. Ako to začnete?
Precise bude môcť tieto transakcie opäť sledovať. Tu vám ukážeme skladaný stĺpcový graf znázorňujúci klienta, webový server, Java, databázu Tuxedo, zásobník aplikácií PeopleSoft. Zelené mapy sa pripájajú k J2EE, čo je akýmsi spôsobom vymýšľania WebLogic. Toto je medzník. Koncoví používatelia začnú používať používateľské rozhranie Fluid UI a doba odozvy sa môže pohybovať od jednej a pol, dvoch sekúnd až po približne deväť, desať sekúnd. To, čo táto jedna obrazovka neukazuje, je počet ľudí, ktorí „nereagujú“. V skutočnosti dostali v aplikácii zamrznutie obrazovky. Pozrime sa na niektoré z viditeľností, ktoré dokáže spoločnosť Precise poskytnúť tomuto zákazníkovi.
Po prvé, keď sa pozriem na transakcie PeopleSoft, v zásade uvidia, videli sme tento druh vecí všade. Ovplyvnené boli všetky transakcie, ako aj všetky miesta. Mimochodom, keď sa na to pozriete, môžete skutočne vidieť miesta po celom svete. Z Ázie a Tichomoria, do Európy a Severnej Ameriky. Problém s výkonom nebol lokalizovaný pre konkrétnu transakciu alebo konkrétne geografické umiestnenie, je to celý systém. Je to nejaký spôsob, ako povedať, že zmena alebo spôsob, akým má fluidné používateľské rozhranie globálny dopad. Môžete vidieť tu z hľadiska škálovateľnosti, že ľudia sa snažia robiť rovnaký druh aktivity, ale čas odozvy je v podstate iba degradovaný a degradovaný. Môžete vidieť, že veci nie sú škálované. Veci idú veľmi, veľmi zle. Keď sa pozriem na počet osí a súbežné pripojenia, vidíte tu niečo, čo je z hľadiska počtu prístupov a spojení veľmi zaujímavé. Tu sa prispôsobujeme iba na asi 5 000 a pozeráte sa na to, čo vedie k 100 súčasným pripojeniam. Toto sa uskutoční po; toto je predtým. Takže moja skutočná požiadavka na systém, ak by sa táto vec mohla rozšíriť, je v rozsahu 300 000. Za starých čias sa s klasickým používateľským rozhraním pozeráte na 30 súčasných spojení.
Teraz vám to hovorí, že používateľské rozhranie Fluid používa najmenej 10x počet súbežných pripojení. Začíname sťahovať to, čo sa deje pod krytom programu PeopleSoft, aby ste mohli začať vidieť dopad na webové servery, skutočnosť, že SLA sa začínajú porušovať. Nechceme ísť do všetkého, ale nakoniec sa stane, že sa v podstate spoliehajú na zasielanie správ. V podstate vykonávajú WebLogic a spôsobujú radenie v Tuxedo. V skutočnosti sa vyskytol problém súvisiaci s viacerými vrstvami, ktorý sa objavil v používateľskom rozhraní Fluid UI, ale spoločnosť Precise dokázala dokázať, že pomocou množstva rôznych vecí sa môžeme sústrediť na to, o aký problém ide. Ukazuje sa, že sa vyskytol aj problém v samotnej databáze. V skutočnosti existuje súbor denníka správ a tento protokol bol uzamknutý pre všetkých súčasných používateľov. V zásade to malo vyladiť, v každej jednej vrstve v rámci aplikačného zásobníka. Keď už hovoríme o zložitosti, v skutočnosti tu je rad Tuxedo, ktorý vám zobrazuje poradie vo fronte, a môžete vidieť aj zníženie výkonu v tejto úrovni. Videl som tieto procesy; Videl som domény a servery. V Tuxede, aby to ľudia používali, spravidla otvárate ďalšie fronty, domény a servery, rovnako ako v supermarkete, aby ste zmiernili preťaženie, aby ste minimalizovali čas zaradenia do frontu. Posledná a posledná možnosť, Precise ukazuje veľa informácií.
Ako som už spomenul, každá významná transakcia interaguje so systémom záznamov. Viditeľnosť do databázy je prvoradá. Precise ukazuje, čo sa deje v databáze, v rámci WebLogic, v Java, .NET, v prehliadači, ale miesto, ktoré Precise skutočne vyniká, je v databázovej vrstve. Toto sa stáva slabou stránkou našich konkurentov. Dovoľte mi ukázať vám jeden zo spôsobov, ako by vás program Precise mohol pomôcť pri prekonávaní tohto problému. Nebudem tráviť čas na trojuholníku optimalizácie databázy, ale v zásade sa zameriavame na nízkonákladové, nízkorizikové, rozsiahle, vysokorizikové a vysokorizikové zmeny typu. Vlastne budem pípanie z tohto snímky potom, ak ľudia chcú vyskúšať a pozrieť sa na to. Myslím si, že je to dosť veľký sprievodca pre problémy s ladením. Toto je odborný názor precízna pre Oracle. Na začiatok správy o nálezoch je tento konkrétny príkaz SQL 60 percent. Ak otvoríte túto obrazovku činnosti, zobrazí sa tam. Môžem sa pozrieť na toto vyhlásenie, existuje jeden plán vykonávania. Každé vykonanie trvá druhé - 48 000 popráv. To zvyšuje až 48 000 ďalších hodín popráv.
Tmavomodrá je opäť CPU. Táto vec je viazaná na CPU, nie na stav čakania, ani na protokol. Zdôrazňujem, že pretože niektorí z našich konkurentov sa zameriavajú iba na stavy čakania a protokolovanie udalostí, ale všeobecne sa hovorí, že CPU je najrušnejším vykonávacím stavom a ponúka najväčší odplatu. Do tohto expertného pohľadu - a idem veľmi rýchlo - som urobil to, že som sa pozrel na stôl, 100 000 riadkov, 37 000 blokov. Robíme plnú tabuľku, ale v tejto veci máme šesť indexov. Čo sa tu deje? Keď sa pozriem na klauzulu where, čo robí táto klauzula, je to, že v skutočnosti prevádza stĺpec na veľké písmená a hovorí sa, kde je to rovnaké ako veľké písmená. Čo sa deje, je vždy, keď sa táto vec vykoná. Oracle musí tento stĺpec previesť na veľké písmená. Namiesto toho takmer päťdesiattisíc krát je oveľa efektívnejšie vytvoriť tento index veľkými písmenami indexu založeného na funkciách a je k dispozícii nielen v divízii podnikovej Oracle, ale aj v štandardnej divízii. Keď to urobíte, potom môžete overiť plán vykonávania, ktorý vydáva novému užívateľovi indexu perm veľké písmená, to bola len moja vec.
Potom, z merania pred a po, sa pozeráte na jednu sekundu času vykonávania, agreguje až 9 hodín 54 minút, s rovnakým presným príkazom SQL, ale s tým, že tento index je zabudovaný veľkými písmenami pre 58 000 spustení, odpoveď čas klesá na čiastkové milisekundy, agreguje sa spolu, je to až sedem sekúnd. V podstate som na svojom serveri ušetril desať hodín CPU. To je obrovské. Pretože ak nie som kvôli obnoveniu servera, môžem žiť na tomto serveri. Skutočne som znížiť využitie tohto servera o 20 percent a môžete skutočne vidieť predchádzajúce a nasledujúce. To je typ viditeľnosti, ktorý môže poskytnúť služba Precise. Mohli by sme sa tiež pozrieť na niekoľko ďalších vecí, prečo máte všetky tieto indexy, ak sa nepoužívajú? Môžu s tým pokračovať. Je tu architektúra a ja ju zabalím, pretože sa dostávame na vrchol hodiny. Som skutočným veriacim v tomto riešení a chceme, aby ste boli skutočným veriacim. V spoločnosti IDERA veríme, že vďaka skúške sa zákazník stane zákazníkom, takže ak vás zaujíma, dokážeme na vašom webe vykonať hodnotenia.
S tým prejdem maják späť.
Eric Kavanagh: Áno, toto bol obrovský detail, ktorý ste tam ukázali. Je to naozaj fascinujúce. Myslím, že som sa vám v minulosti mohol zmieniť o tom, že - a viem o niektorých ďalších webových vysielaní, ktoré sme uskutočnili v spoločnosti IDERA, spomínal som to - vlastne sledujem presnosť od tej doby, ako ju spoločnosť IDERA získala, až do roku 2008, myslím, alebo do roku 2009. To ma vtedy fascinovalo. Zaujímalo by ma, koľko práce zostáva v práci na nových vydaniach aplikácií. Spomenuli ste, že SAP HANA, čo je podľa môjho názoru dosť pôsobivé, môžete sa skutočne kopať do architektúry HANA a robiť tam nejaké riešenia problémov. Koľko ľudí máte? Koľko úsilia je to z vašej strany a koľko z toho možno urobiť trochu dynamicky, čo znamená, že keď sa nástroj rozmiestni, začnete sa plaziť a vidieť rôzne veci? Koľko z toho môže byť dynamicky, druh, zistené pomocou nástroja, aby ste mohli ľuďom pomôcť pri riešení zložitých prostredí?
Bill Ellis: Položili ste tam veľa otázok.
Eric Kavanagh: Ja viem, prepáč.
Bill Ellis: Poskytol som veľa detailov, pretože pre tieto aplikácie je diabol v detailoch. Musíte mať takú úroveň detailov, aby ste mohli skutočne mať niečo, čo je možné uplatniť. Bez metrík, ktoré je možné použiť, viete len príznaky. V skutočnosti nevyriešite problémy. IDERA je o riešení problémov. Zostať na vrchole nových vydaní a vecí je veľká výzva. Otázka, čo to znamená urobiť, je to skutočne pre produktový manažment. Nemám veľa viditeľnosti do tímu, ktorý nás v podstate informuje o veciach. Pokiaľ ide o HANA, je to vlastne nový prírastok do produktovej rady IDERA; je to veľmi vzrušujúce. Jednou z vecí, ktoré s HANA sú, je, že mi poviem jednu chvíľu o tejto úlohe. V rámci tejto úlohy by obchody SAP vykonali to, že replikujú databázu na účely vykazovania. Potom by ste museli mať ľudí, aby sa zmierili s tým, čo je aktuálne. Mali by ste tieto rôzne databázy a tie by neboli synchronizované na rôznych úrovniach. Je tu len veľa času a úsilia, plus hardvér, softvér a ľudia, ktorí všetko udržiavajú.
Myšlienka HANA mať vysoko paralelnú databázu v pamäti, aby sa v zásade predišlo potrebe duplicitných databáz. Máme jednu databázu, jeden zdroj pravdy, je vždy aktuálny, aby ste sa vyhli potrebe urobiť všetko zmierenie. Význam výkonu databázy HANA stúpa - poviem 10x alebo aspoň cennejšie ako súčet všetkých tých ostatných databáz, hardvér, zdroje, ktoré si môžete kúpiť. Keďže je táto komponenta schopná spravovať HANA, teraz je v súčasnosti v testovaní verzie beta, čoskoro pôjde o službu GA. Preto je pre spoločnosť IDERA a pre nás v podstate podpora platformy SAP celkom vzrušujúce. Nie som si istý, aké ďalšie časti vašej otázky som trochu skrátil, ale -
Eric Kavanagh: Nie, to je všetko dobré. Vrhol som na vás celú partu naraz, takže je mi to ľúto. Som fascinovaný, naozaj, myslím, že nejde o veľmi jednoduchú aplikáciu, však? Vykopávate sa hlboko do týchto nástrojov a rozumiete tomu, ako interagujú medzi sebou as vami, musíte tento príbeh rozdeliť do hlavy. Aby ste pochopili, čo sa v skutočnosti deje a čo spôsobuje problémy, musíte skombinovať kúsky informácií, takže tam môžete ísť a vyriešiť tieto problémy.
Jeden účastník sa pýta, aké ťažké je implementovať program Precise? Ďalšia osoba sa pýtala, kto sú ľudia - samozrejme DBA -, ale kto sú niektoré ďalšie úlohy v organizácii, ktorí by tento nástroj používali?
Bill Ellis: Presnosť je trochu komplikovanejšia. Musíte mať určité vedomosti o aplikačnom prostredí, pokiaľ ide o, viete, táto aplikácia beží v tejto databáze, potrebuje alebo - stredné vrstvy webových serverov atď. Myslím, že vzhľadom na komplexnosť niektorých z týchto aplikácií, je to vlastne relatívne ľahké. Ak dokážem inštrumentovať webový server do vašej databázy, môžem to urobiť od začiatku do konca. Všimli ste si, že som nepovedal nič o vybavovaní klienta koncovým používateľom, a to preto, lebo robíme to, že ho vlastne zahrievame dynamicky, takže nemusíte meniť svoj kód ani nič iné. Do rámca stránky aplikácie vstúpi JavaScript. Bez ohľadu na to, kde sa používateľ nachádza na svete, keď má prístup k adrese URL z vašej aplikácie a stránku skomprimuje, je vybavený nástrojom Presné. To nám umožňuje vybrať si ID užívateľa, ich IP adresu, tiež prvý čas načítania bajtov každej doby vykonávania skriptov komponentov stránky v prehliadači koncového používateľa.
Pokiaľ ide o transakcie, nemusíte transakcie mapovať, pretože sú pevne spojené. Táto adresa URL sa stáva vstupným bodom do JVM a potom vyvolá túto správu, výsledkom čoho je JVC zachytený z databázy. V podstate sme schopní zachytiť tieto prirodzené body pripojenia a potom ich prezentovať na tejto obrazovke transakcií, ktorú som vám ukázal, kde sme tiež spočítali, koľko času alebo percento času, ktorý bol strávený v každom jednotlivom kroku. To všetko sa vykonáva automaticky. Všeobecne povedané, pridelíme 90 minút na to, aby sme v podstate nainštalovali precízne jadro a potom začneme implementovať aplikáciu. V závislosti od znalosti aplikácie môže trvať niekoľko ďalších sedení, kým sa celá aplikácia vybaví. Mnoho ľudí používa iba databázovú zložku Precise. To je v poriadku. V podstate to môžete rozdeliť na súčasti, ktoré považujete za potrebné pre vaše stránky. Určite veríme, že v súvislosti s tým, že sa celý nástrojový nástroj inštrumentoval, aby ste videli, že závislosť medzi vrstvami skutočne zvyšuje hodnotu monitorovania jednotlivej úrovne. Ak chce niekto ďalej skúmať vybavenie svojich aplikačných balíkov, prejdite na našu webovú stránku - myslím, že je to najjednoduchší spôsob, ako požiadať o ďalšie informácie, a budeme o tom hovoriť trochu ďalej.
Eric Kavanagh: Dovoľte mi hodiť jednu alebo dve rýchle otázky. Hádam, že v priebehu času zbierate a budujete úložisko interakcie medzi rôznymi aplikáciami a rôznymi databázami, a to tak pre individuálnych klientov, ako aj pre celé podnikové subjekty. Inými slovami, myslím si, modelovanie scenárov, na ktoré odkazujem. Je to tak? Spravujete v skutočnosti druh úložiska bežných scenárov, aby ste mohli navrhnúť koncovým používateľom, keď sa objavia určité veci? Rovnako ako táto verzia balíka E-Business Suite, táto verzia tejto databázy atď. - robíte to veľa?
Bill Ellis: Tento druh informácií je zabudovaný do správy o zisteniach. V správe o zisteniach sa uvádza, aké sú prekážky výkonu a je založená na čase vykonávania. Súčasťou tejto správy o zisteniach je viac informácií a čo ďalej. Informácie alebo skúsenosti od zákazníkov atď. Sú v zásade začlenené do knižnice odporúčaní.
Eric Kavanagh: Dobre, to znie dobre. Ľudia, fantastická prezentácia dnes. Bill, miloval som, koľko tam máš detailov. Len som si myslel, že to boli naozaj fantastické, odvážne a podrobné informácie, ktoré ukazujú, ako sa to všetko robí. V určitom bode je to takmer ako čierna mágia, ale v skutočnosti to tak nie je. Je to veľmi špecifická technológia, ktorú ste zostavili, aby ste pochopili veľmi, veľmi zložité prostredie a urobili ľudí šťastnými, pretože nikto nemá rád, keď sa aplikácie spúšťajú pomaly.
Ľudia, budeme toto webové vysielanie archivovať. Môžete preskočiť online na stránku Techopedia alebo insideanalysis.com a páni, vďaka za váš čas vás nabudúce dobehneme. Dávajte pozor, zbohom.
