Od zamestnancov Techopedia, 31. augusta 2016
Jedlo s sebou: Hostiteľ Rebecca Jozwiak diskutuje o problémoch s riešením problémov s databázou a problémami s efektívnosťou s analytikmi Ericom Kavanaghom a Dezom Blanchfieldom, ako aj s Billom Ellisom z spoločnosti IDERA.
Momentálne nie ste prihlásení. Ak chcete vidieť video, prihláste sa alebo sa zaregistrujte.
Rebecca Jozwiak: Dámy a páni, ahoj, vitajte v službe Hot Technologies roku 2016. Dnešná téma „Aplikácia beží pomaly? Čas na presnosť“. A nevieme všetci príliš dobre problémy, ktoré sa môžu vyskytnúť, keď materiál beží pomaly? Toto je Rebecca Jozwiak, zastupujem Erica, ktorý tu dnes hrá nejakú novú úlohu. Áno, tento rok je horúci a ako viete, pokiaľ ide o technológie, ako som už povedal, jedna vec, ktorú naozaj nechcete, je pomalý beh všetkého, ktorákoľvek časť vášho systému. A len na to, aby som použil príklad pre spotrebiteľa, myslím, že ak máte reštauráciu, nezáleží na tom, aké skvelé jedlo je, ak je služba pomalá, pravdepodobne sa nakoniec nebudete vracať. Teraz je ľahké v reštaurácii zistiť, prečo niečo beží pomaly. Možno je v kuchyni krátka obsluha alebo došlo k poruche s niektorým vybavením, alebo možno je obsluha trochu lenivá a možno ju ľahko identifikovať a opraviť.
Ale keď uvažujete o dátovom centre, je to úplne iný príbeh. Môže to byť problém so sieťou, zlý dotaz, ktorý zasekáva veci, výkon aplikácií alebo chybný kábel môže dokonca spôsobiť určité problémy. A riešenie problémov s týmto typom zložitosti môže byť, prinajmenšom, ťažké. To je to, o čom dnes budeme hovoriť. A ako som už povedal, Eric Kavanagh sa dnes ožíva ako analytik. Máme nášho dátového vedca Dez Blanchfielda a máme Billa Ellisa z spoločnosti IDERA, ktorý bude hovoriť o riešení svojej spoločnosti, ktoré pomáha pri riadení výkonu aplikácií. A s tým idem odovzdať loptu Ericovi. Eric, podlaha je tvoja.
Eric Kavanagh: V poriadku, znie to dobre, ľudia. A to bola vlastne veľká analógia, pretože ste hovorili o ťažkostiach alebo ľahkosti, s ktorými je možné vyriešiť problém a dostanete sa k nemu priamo. Problémy s výkonom vždy vyplývajú z nejakého problému, ktorý je v sieti. Myslím, že by to mohlo byť také jednoduché, ako starý hardvér, ale spodným riadkom je situácia, ktorá si vyžaduje riešenie problémov. O tom dnes budem hovoriť. A poďme ďalej a skočíme na snímky tu.
Prichádzajú problémy. Riešenie problémov - je to zábava pre ľudí, ktorí ju majú radi, to je super. Ak nájdete niekoho, kto rád rieši problémy, držte sa tejto osoby, dajte im nejaké nástroje na dokončenie práce, pretože naozaj dobré veci nájdete, ak nájdete niekoho, kto sa môže dostať na dno niečoho a dostane veci. Pointa je však to, že riešenie problémov je problematické a vždy to bolo a vždy bude, a ak začnete hovoriť o riešení problémov, v skutočnosti ste sa zaoberali analýzou hlavných príčin. Čo spôsobuje problém?
Ak si len tak sadnete a chvíľu premýšľate aj o dňoch sálových počítačov, mohli by sa vyskytnúť všetky druhy problémov. A vtedy ste museli mať ľudí, ktorí skutočne poznali svoje veci, pretože na riešenie problémov neexistovali ani dobré nástroje, takže ste skutočne museli poznať svoj príkazový riadok a o tom budeme hovoriť o sekundu. A ja som vlastne zabudol vložiť jeden z mojich obľúbených snímok, ja ho budem hľadať, keď sme dnes na výstave, možno počas Dezovej prezentácie. Chcel som však ukázať každému, kto to ešte nevidel, jednu z najzábavnejších britských televíznych relácií, ktorá sa kedy volala, nazýva sa „The IT Crowd“. A pokiaľ ide o riešenie problémov, írsky muž, ktorý je jedným z dvoch IT ľudí v celá spoločnosť vždy hovorí to isté pri každom začatí hovoru: „Skúsili ste ju vypnúť a znova zapnúť?“ Skúste to vypnúť a znovu zapnúť. Boli by ste prekvapení, ako často môže táto jednoduchá vec vyriešiť niektoré problémy.
Tí z vás, ktorí riešili problémy doma, možno so svojimi rodičmi alebo priateľmi, pravdepodobne nie s vašimi deťmi, pretože majú tendenciu vedieť, čo robiť, vypnite ich a znovu zapnite. Ale bez ohľadu na to, riešenie problémov nie je ľahké, nikdy to nebude ľahké, ale dnes sa budeme baviť o niektorých veciach, ktoré môžete urobiť, aby ste to uľahčili. Takže príkazový riadok - áno, skutočne som dosť starý na to, aby som si spomenul na prvé dni výpočtov, keď všetko, čo ste mali, bolo príkazový riadok na vykonanie DIR, Enter. To by bolo vidieť, adresár súborov a cítiť sa pozitívne, že sa skutočne vykonal nejaký príkaz, však? Dez, samozrejme, náš vedec údajov, vie, ako použiť príkazový riadok. A ak môžete použiť príkazový riadok, je to skvelé, pretože väčšina smrteľných smrteľníkov používa nejaký druh grafického používateľského rozhrania, grafické používateľské rozhranie, ale vždy existuje niečo, vždy existuje nejaký rozdiel medzi grafickým používateľským rozhraním a príkazovým riadkom pod ním. A len aby som vám dal náhodný príklad, ak chcete vedieť, koľko kódu niektoré zo základných programov tam pečú v týchto dňoch, choďte do najnovšej verzie programu Microsoft Word, napíšte „ahoj svet“ a potom „uložte ako HTML. “A potom otvorte výsledný dokument v textovom editore a pravdepodobne uvidíte stránky a stránky značiek. To sa nazýva blokacia kódu a blokacia kódu nie je naozaj vhodná na riešenie problémov, len aby som bola tupá.
Samozrejme, prišiel klient-server a to bolo skvelé. A tak sa trochu vraciame týmto smerom, ale myslíme len na zložitosť, ktorá vznikla v situácii, kde je teraz problém, je to na klientovi, je to na serveri, je to sieť? Kde to je? Čo sa môže stať s týmito webmi, ktoré len myslia na vírusy, a keď sa vírus môže stať jedným vírusom v sieti? Môže ísť kamkoľvek. Porušenie údajov je v týchto dňoch šialené. Spôsobujú problémy s výkonom. Mali sme ruských hackerov, ktorých poznáme podľa adresy IP. Sme si celkom istí, že sú Rusi, alebo sú veľmi blízko, alebo sú to veľmi šikovní Ukrajinci alebo Poliaci alebo dokonca Američania, ktorí používajú proxy. V priebehu rokov sme však na naše staré stránky Inside Analysis prišli hackeri a spôsobili všetky druhy problémov. Veci prestávajú fungovať, nemôžete urobiť všetko. Veci, ktoré pracovali, nefungujú. Ako vieš? Ako viete, čo to je? Rovnako ako ďalší príklad tu je veľmi zložité prostredie, je veľmi ťažké dostať sa do burín a skutočne porozumieť tomu, ako sa veci odohrávajú a ako pre nás fungujú, najmä ak získate veľa doplnkov. Veci sa môžu zblázniť celkom rýchlo. Som trochu v predstihu pred seba.
Hodil som sa sem, vždy si dajte pozor na upgrade. Vylepšenia mi vždy vystrašia denné svetlo. Určite operačné systémy. Pamätám si dni, kedy spoločnosť Microsoft skutočne navrhla, aby ste mohli upgradovať operačný systém z tejto verzie na túto verziu. Skúsil som to niekoľkokrát, a to nikdy nikdy nefungovalo. Nezabudnite, že čím väčšie prostredie je, tým zložitejšie je prostredie, čím ťažšia je situácia. A potom je tu virtualizácia. Zamyslite sa nad tým, čo VMware urobil pre IT. Revolucionalizovalo to IT, ale tiež vytvorilo túto vrstvu abstrakcií. Ak máte na tejto základnej úrovni abstrakciu vrstvy, je to úplne nová loptová hra, je to úplne nová guľa vosku a naozaj musíte prehodnotiť, čo robíte, a všetky staré nástroje sa museli zmeniť. A teraz, samozrejme, je to oblak, však? Pre zákazníka je cloud vynikajúci, pretože je veľmi jednoduchý, používateľské rozhranie je veľmi jednoduché, ale samozrejme nemáte nad cloudom veľa kontroly. Ale pre ľudí, ktorí sú v zákulisí, je tu veľa vecí, ktoré musia vedieť a pochopiť v týchto dňoch. Prostredie sa stalo oveľa, oveľa zložitejším. A určite s elektronickým obchodom, a vy si myslíte o všetkých peniazoch, ktoré sa v súčasnosti obchodujú s rukami. Preto ma v dohľadnej dobe nenájdete v prospech bezhotovostnej spoločnosti. Pointa je, že situácia je každým dňom problematickejšia.
A udržanie optimálneho výkonu vždy zahŕňa nejaký prvok riešenia problémov. Je mi jedno, čo vám niekto povie, neexistuje dokonalý nástroj, neexistuje strieborná guľka a nikdy nebude, pretože - v inej zaujímavej perspektíve - sa stále učíme hovoriť kremík. Stále sa učíme porozumieť tomu, ako funguje aj vytváranie sietí na vyššej úrovni. Ak sa pozriete na softvér na správu systémov, v súčasnosti je to celkom dobré. Ale stále sa pozeráte na čiary, ktoré sa pohybujú nahor a nadol a pozeráte sa na reprezentácie reality, bude to mať človeka, ktorý vie, čo sa deje, aby sa zmestili stopy, ktoré by ste mohli hľadieť na optimálne nástroje, aby ste boli schopní pochopiť, čo funguje a čo nie, a je to veľa pokusov a omylov, len aby som bol úprimný. S tým idem odovzdať Dez Blanchfieldovi a potom sa ozve Bill Ellis z IDERA, ktorý nás bude hanbiť jeho znalosťami. S tým, Dez, zober to.
Dez Blanchfield: Hej, vďaka Ericu. Ďakujem. Pekne viedol do mojej malej sejby. Môj titul „Performance Art“ je podľa môjho názoru mimoriadne vhodný v kontexte toho, o čom dnes rozprávame, pretože v mnohých ohľadoch, keď uvažujeme o performance, myslíme o tanci a hudbe a ďalších tvorivých veciach. A úprimne povedané častejšie ako nie, ak riešime problémy a vo veľmi rozsiahlych IT prostrediach a obchodných systémoch skutočne existuje prvok umenia a často čierneho umenia, pretože podľa mojich skúseností za posledných 25 rokov je situácia taká, že moderné aplikačné balíčky, sa veľmi rýchlo zvyšujú zložitosti rýchlosťou, akú sme nikdy predtým nevideli. A úprimne sa snažíme držať krok a existujú organizácie, ako napríklad Uber a podobne, a vývojový tím Pokémon Go, myslím, že zažívajú rast a zložitosť a zvyšovanie zložitosti v miere, ktorá je len astronomická. O tom nie sú napísané ani knihy, pretože túto úroveň rastu sme si neuvedomili. Môj názor je, že základná definícia súboru aplikácií sa zmenila exponenciálne a ja vysvetlím, prečo si myslím, že je to tak, a potom povedie k výzve, po ktorej sa zdá, že moji dobrí priatelia v spoločnosti IDERA majú riešenie na riešenie,
Veľmi stručne to všetci vieme, ale len ich rekapitulujeme, viete, v prvých dňoch sme mali to, čo volám, aplikačná architektúra, verzia 1.0. Bol to serverový počítač, v tomto prípade sálový počítač s pripojeným množstvom terminálov, bolo relatívne ľahké diagnostikovať problémy, ak ste na termináli nevideli veci - môžete vyhľadať kábel medzi terminálom a potom serverovým počítačom. a bol to buď nulový kábel alebo konektor alebo nejaký problém, ak to nesúviselo s terminálom, a na obrazovke vidíte veci, bolo celkom ľahké zistiť, že veci, ktoré spôsobili problémy, boli v stroj sám. A mohli by ste pomaly diagnostikovať, kde v zásobníku sa nachádzal hardvér až po vrstvu softvéru a používateľské rozhranie. V tom, čo volám verziu 1.1, sme to urobili trochu zložitejším. Umiestnili sme zariadenia do stredu, aby sme mohli umiestniť viac terminálov. A boli to nejaký druh komunikačného zariadenia a často išlo o muxy alebo multiplexery a bežali by buď cez vyhradenú linku alebo dial-up linku, takže ste mali mainframe na vzdialenom mieste - mohlo by to byť medzištátne alebo medzinárodne - a nejaké zariadenie pripojené cez spojenie SMA alebo nejaký druh pripojenia WAN a tieto terminály stále fungujú rovnakým spôsobom. Mali ste však trochu zložitejšiu situáciu, pretože ste museli zistiť, či ide o problém medzi terminálmi a zariadením Comms alebo zariadením Comms a mainframe. Zásobník však zostal relatívne podobný v mainframe.
Verzia 1.2, opäť trochu zložitejšia, pretože teraz sme pridali ďalšie zariadenia, pridali sme tlačiarne a ďalšie veci a tieto veci sme zoskupili a myslím na front-end procesor, ktorý by riešil všetky problémy zariadení lokálne, tlačiarne a terminály a tak ďalej s mainframe, ktorý je vzdialený koniec. Trochu zložitejšia. Ale opäť, konzistentnou témou mainframe boli aplikácie bežiace lokálne, takže riešenie problémov zostalo v zásobníku aplikácií dosť podobné. A potom sme nechali ľudí so zručnosťami bežať pri riešení problémov s terminálmi a tlačiarňami a radičmi klastrov. Potom sme však komplikovali veci a vytvorili sme siete a zrazu ten istý druh architektúry zavádza sieťovú vrstvu. Zrazu sme mali sieťový prepínač a pracovné stanice boli oveľa zložitejšie. A túto verziu architektúry sme často mali graficky užívateľské rozhranie aplikácie na pracovnej stanici. Nielenže sme mali server, na ktorom je spustený zásobník aplikácií, ale mali sme aj ďalší balík aplikácií, ktorý sa spúšťal lokálne, a samozrejme rovnaký základný model zariadení pripájajúcich sa k serveru. Potom sme urobili kvantový skok k novšiemu modelu toho, čomu hovorím 2.1, čo je miesto, kde sme vzali tento balík aplikácií a urobili sme ho oveľa zložitejším, oveľa ťažšie diagnostikovateľným. A predstavili sme oveľa viac zariadení na klientskom rozhraní, vo webových prehľadávačoch a počítačoch a mobilných zariadeniach atď. A tu sa aplikačný balík začal ponoriť trochu hlbšie do integrácie ako operačný systém a hypervisor.
Tento obrázok tu na pravej strane máme v pravej prednej časti celý zásobník vrátane sieťovej infraštruktúry, úložných serverov, virtuálnych strojov, operačného systému a potom tradičných troch vrstiev databázových kovových aplikácií atď. Diagnostika problémov s aplikáciou a problémov s výkonom na tomto modeli sa stala oveľa ťažšou. Existuje toľko ďalších pohyblivých častí a snažiť sa vŕtať sa cez ten komín bol, viete, nočnou morou a vy ste sa museli zaoberať ďalšími súbormi zručností a organizáciou, aby ste sa s tým vyrovnali. Už to nebol len váš aplikačný tím. Zrazu ste mali ľudí v oblasti infraštruktúry, mali ste databázových špecialistov, čisto pracovali len na databázach a nič iné - na rozdiel od systémového programátora, ktorý sa oboznámil s databázami. Teraz máme scenár, v ktorom sa oddelenia IT musia zaoberať výrazne širšou komplexnosťou „ako služby“, a to, keď svet práve explodoval a naše výzvy na riešenie problémov sa stali, sa zmenilo z nočnej mory na niečo, čo je takmer netolerovateľné. nejakými spôsobmi.
A toto sa stalo ako vyriešiteľné riešenie, ktoré sa snažíme poskytovať služby na. Verzia 3 toho, čo považujem za aplikačný balík - zaviedla to ako model služieb, kde tradičný model na ľavej strane, podnikový IT zásobník, kde všetko muselo byť na našej strane spravované ako spotrebiteľ a dodávateľ služby - z databázy zabezpečenia aplikácií, operačných systémov, virtualizačných služieb, sieťových dátových centier - museli sme to všetko spravovať, ale mali sme k nim prístup, a tak sme mohli škálovať svoje schopnosti a technické zručnosti a mohli sme sa vŕtať priamo nadol cez tento zásobník a mohli sme nájsť veci. Keď sa však objavila služba v oblasti infraštruktúry a služieb platforiem a model softvérových služieb, zrazu sa nám zrazu odobral náš prístup k back-end infraštruktúre, náš prístup k platformám a nástroju, z ktorého sme poskytovali služby. Keď sme začali využívať infraštruktúrnu službu, mali sme k dispozícii iba štyri hlavné súčasti operačného systému, databázy, zásobníka bezpečnostných prostredí a vyššie. Všetko pod tým bola čierna mágia. A to sa stáva ešte zaujímavejším, keď sa presuniete na platformovú službu, pretože tiež spravujete len zásobník aplikácií.
Keď sa dostanete k softvéru ako službe a jeho tradičným modelom je webmail alebo internetové bankovníctvo, všetko, čo máte, je prístup do webového prehľadávača, takže sa pokúsiť diagnostikovať, čo je za tým, je určite netolerovateľné. A ja som to rozdelil na časové pásma, časové úseky alebo časové úseky, ak sa vám páčia alebo generácie, v tom zľava doprava sme prešli z nejakých pred 2000 rokov a tradičného zväzku, do ktorého sme mali prístup do celého prostredia a cez to by sme sa mohli vŕtať. Ale postupom času sa to stalo čoraz zložitejším. Do začiatku roka 2000 až do polovice roku 2000, do konca roku 2000 až do dnešného dňa, keď sme prešli od služieb v oblasti infraštruktúry, služieb platforiem, softvérových služieb, až po súčasnosť v podstate hovoríme o obchodných službách. A zložitosť sa dramaticky zvýšila. Existuje toľko ďalších pohyblivých častí. Dostupnosť zručností je však ťažšia a ťažšia a ťažšie ju ťažiť. Nájdenie ľudí so správnymi súbormi zručností so správnym prístupom k správnym nástrojom, aby ste sa dostali do tohto zásobníka a zistili, kde niečo beží pomaly. Je to môj laptop alebo môj počítač, je to môj telefón alebo tablet, je to moje pripojenie cez 3 alebo 4G alebo môj vyhradený odkaz s ADSL alebo ISDN, čo to môže byť? Alebo dokonca dial-up, aj keď je to v súčasnosti čoraz menej. Je webový server koniec, je to niečo vo webovom serveri? Je to aplikačný server? Je to niečo okolo pamäte a disku CPU a výkonu siete v aplikačnom serveri? Je tam databáza spustená?
A viete si predstaviť, veľmi rýchlo nakreslíte tento obrázok zložitosti, ktorá sa začína rozširovať ako obrázok veľkého tresku, tejto stále rastúcej bubliny, ktorú sa snažíme obísť a mať schopnosti vrhnúť sa do a vedomosti a prostriedky na rozrezanie a roztrhnutie. A my sme veľmi teraz v dobe, keď viete, že ľudské bytosti sa nedokážu vyrovnať s fyzickým meradlom, aj keď máte schopnosť ťahať databázové prostredie od seba a odtiahnuť túto databázu od seba a ponoriť sa do podrobnosti v tejto databáze. Počet databáz, ktoré musíte teraz spravovať, rýchlo rastie. Všetko je teraz poháňané databázou. Veľmi málo aplikácií v súčasnosti nie je poháňaných databázou. A typy databáz tiež rýchlo rastú. Už to nie sú len tradičné databázy SQL, niekedy jeho SQL, niekedy aj iné ako SQL, niekedy je to grafová databáza, niekedy je to dokumentová databáza. A existujú všetky tieto rôzne typy funkcií, ktoré majú tieto rôzne typy databáz, a preto každá z nich má odlišné výzvy na výkon a rôzne výkonnostné kritériá. Protokolované databázy a databázy dokumentov vykonávajú veľmi, veľmi odlišne a vykonávajú inú funkciu ako tradičná SQL databáza kompatibilná s ACID a ANSI 92. A druhy vecí, ktoré sme tam uložili.
Podľa môjho názoru sme v bode, kde - a myslím si, že Eric na to poukázal -, že ľudské bytosti sa snažia držať krok so zložitosťou toho, čo staviame, s rýchlosťou, ktorú staviame, a Teraz sme v bode, keď jediný spôsob, ako riadiť túto infraštruktúru, a jediný spôsob, ako monitorovať a zaoberať sa problémami, ktorým čelíme, sú nástroje a správne typy nástrojov. A potom vždy správna generácia nástrojov. Nástroje, ktoré skutočne chápu back-end infraštruktúru. Už nie je v poriadku, iba hodiť monitor SQL alebo dotazovací nástroj SQL na niečo a začať dotaz rozdeľovať od seba a zistiť, čo to funguje. Skutočne potrebujeme nástroj, ktorý chápe vytváranie dopytov a vhodný spôsob na vytváranie dopytov a vhodné spôsoby, ako môžu dotazy hovoriť s infraštruktúrou na pozadí a ako sa správajú tak, ako to robia. A pozrieť sa na načasovanie týchto interakcií a poradie, v akom sa uskutočňujú.
A to je oveľa zložitejšia výzva, ktorá ma privádza k otázke naokrúhlenej otázky, a to, že ako sa zvyšuje zložitosť aplikačných balíkov, ktoré vyvíjame, výkonové nástroje a nástroje, ktoré používame na ich správu, nevyhnutne potrebujú aby sa stal čoraz chytrejším a oveľa schopnejším pri pohľade na viac vecí. Ale tiež oveľa chytrejším spôsobom, ako sa ponoriť do toho, čo sa deje v pozadí a čoho o tom môžu zistiť, a prípadne dokonca vykonať nejaký druh analytiky, aby pochopili, že interakcie a výkon sú dodávané, a prečo je výkon pomalší alebo rýchlejší.
A potom s tým pôjdem odovzdať nášmu drahému priateľovi z IDERA, Billovi Ellisovi, a uvidím, čo dnes musí povedať o tom, ako vyriešia tento problém. Bill, nad tebou.
Bill Ellis: Dobre. Moje meno je Bill Ellis a ďakujem vám veľmi pekne. Budeme hovoriť o mojej aplikácii beží pomaly, je čas získať presné informácie. Pozrime sa, čo dokáže produkt Precise, produkt IDERA, a ako vám môže pomôcť. Mnohokrát zistíte iba to, že sa vyskytol problém s výkonom, pretože vás koncový používateľ zavolal, a to je samo o sebe veľký problém. Z každého v IT nikto nevedel, kým nezazvonil telefón. Teraz je ďalším veľkým problémom to, ako tomuto konkrétnemu jednotlivcovi pomáhame a v skutočnosti to nie je triviálny problém. Je tu jedna cesta s sebou. To je nad a za touto snímkou, nad a za ostatnými. A chcem, aby ste videli, či to dokážete. Ako sme však už uviedli, aplikácia vyžaduje, spolieha sa na množstvo rôznych technológií, aplikačný zásobník je vysoký a rastie. A veľa ľudí pristupuje k aplikácii prostredníctvom prehliadača a prekvapujúco dochádza k čoraz väčšiemu spracovaniu, ktoré sa v prehliadači deje so skriptovaním atď. A potom samozrejme máte sieť, webový server, obchodnú logiku a databázu. Chcel by som, aby ste zvážili, že každá významná obchodná transakcia interaguje s databázou, či už ide o podávanie správ o časových kartách, vyhľadávanie zásob, nákupnú objednávku, databáza sa aktualizuje. A tak sa databáza stáva skutočne základom výkonu. Databáza sa samozrejme môže zapnúť alebo sa spolieha na následný ukladací priestor. Každá z týchto technológií je úzko spojená a je schopná vidieť, čo sa deje. Musíte vedieť, čo sa bude môcť merať, je rozhodujúce.
Teraz nájdeme jednu vec, že mnohí z našich zákazníkov majú nástroj a pre každú technológiu majú nástroj, ale to, čo nemajú, je kontext. A kontext je v podstate schopnosť spojiť bodky medzi každou úrovňou aplikačného zásobníka, čo je vlastne relatívne jednoduché. Boli sme zvyklí mať obmedzenia na dvanásť úrovní, ale v podstate sme ich zmenili, máme neobmedzené úrovne a podporujeme zmiešané prostredie, takže s presným riešením môžeme v zásade veľmi skomplikovať.
Teraz na vysokej úrovni takto riešime problém a zameriavame sa na transakciu, transakciu koncového používateľa od kliknutia na disk, ktorá nám hovorí, ktoré z nich bežia pomaly, ktoré spotrebúvajú zdroje, ale kľúčom je toto - umožníme vám vyzdvihnúť a ID používateľa svoju polohu a nielen celý čas transakcie, ale koľko času strávi v každom jednotlivom kroku. Čas je mena výkonu a tiež ukazuje, kde sa spotrebúvajú zdroje. Nevieme vopred, kde bude problém, takže musíme mať primerané metriky a analytiku na každej z úrovní, aby sme mohli diagnostikovať, v čom je problém, kde môže byť problém.
Teraz, v dnešnej prezentácii sa zameriam na túto oblasť, chcem, aby ste si boli istí, že v zásade poskytujeme rovnakú úroveň viditeľnosti na každej úrovni aplikačnej sady a kľúčovou vecou je to, čo nám povie, kto, čo, kde a potom táto časť, nám to povie prečo. A to je skutočne dôvod, prečo je to absolútne rozhodujúce pre riešenie problémov, nielen o nich vedieť. Ďalšou vecou, ktorá vyšla v prezentácii veľmi jasne, bolo, že to nie je možné. Potrebujete automatizáciu. A automatizácia znamená, že máte upozornenie, máte niečo, čo, dúfajme, pred komunitou koncových používateľov, naznačuje, že máte pokračujúci trend, vybudovali si odchýlku od upozorňovania na trendy. A potom ponúkame aj čiaru v piesku, skutočne porušujete SLA. Teraz ponúkate množstvo rôznych informácií - nie každý musí konzumovať bufet, niektorí ľudia chcú iba ľahké občerstvenie, je to šalát, a preto s cieľom ponúknuť portál, ktorý umožňuje nahrávať informácie, potrebuje konkrétneho používateľa alebo informácie o konkrétnej komunite týkajúce sa výkonu. Aplikácia beží pomaly, je čas získať presnosť. Naozaj sa zameriame na štyri veci. Jedným z nich je umiestnenie zadávajúce koncového používateľa. Z tohto kontextu, ktorý spája bodky, a tretej časti prieskumu opäť vyplýva, že takmer 90 percent problémov s aplikáciou je v databáze, a preto je to skutočne druh pojivosti, ktorú vám väčšina výkonných riešení môže povedať jedným príkazom SQL. Nepovedia vám však, prečo tento príkaz SQL beží pomaly.
Preto je vždy rozhodujúca vec a precíznosť je vynikajúca pri preukazovaní toho, prečo pre každú vrstvu a najmä databázu, a len sa s vami podelíme o našej podpornej matici, ktorú podporujeme SQL Server, Sybase, DB2. a / alebo hromadne. Vzhľad a dojem riešenia je veľmi podobný, takže ak hľadáte viac aplikácií, ale mierne odlišné architektúry. Informácie, ktoré tu zdieľam, majú vzhľad a prístup, sú rovnaké, bez ohľadu na to, aké základné technológie sa používajú. Presný je povolený web. Prichádzame, autentifikujeme precíznosť, a tým ideme dovnútra a prvá vec, ktorú by sme sa mohli chcieť pozrieť, je výkon podľa miesta. A tak tu môžete vidieť rôzne miesta, kde ľudia skutočne pristupujú k svojim popravám. Môžete vidieť, či niekto opustil stránku skôr, ako sa úplne vykreslila, alebo či sa vyskytli chyby.
Jedna vec s týmito aplikáciami je teraz, že sieť alebo vzdialenosť od aplikačného servera sa odlišujú. Je veľmi ľahké vidieť, že existuje určitá úroveň siete. Vidím, keď ľudia zaneprázdnení, a potom ďalšia zaujímavá vec, hovorili sme o tom, ako prebieha spracovanie v prehliadači, skutočne si všimnú, že niektoré z rôznych typov prehľadávačov poskytujú lepšie prostredie na rýchle spracovanie. Takže ak vieme, či ľudia pristupujú k prehliadaču Chrome alebo IE alebo k čomukoľvek, čo sa stane, skutočne zistíte, že inverzia jedného typu prehliadača je skutočne lepšia ako druhá. Teraz, niekedy, keď ste verejne konfrontovaní, neovládate prehliadač, niekedy sú aplikácie interné, kde môžete ľuďom odporúčať typ prehliadača pre svoju komunitu koncových používateľov, a preto ide o typy hĺbkovej analýzy a analýzy, ktoré Presnosť je schopná zabezpečiť. Teraz sa dostaneme do skúmania aplikácie.
Nie som si istý, či vidíte môj ukazovateľ, ale chcel som vám opísať horný graf. Os y ukazuje priemernú dobu odozvy. Os x je čas v priebehu dňa. A v skutočnosti je naskladaný stĺpcový graf a ten naskladaný stĺpcový graf, celkový výsledok vám ukáže, čo je výkon, a potom ukazuje odstupňovanie toho, koľko času sa strávi v každom jednotlivom kroku alebo v každej jednotlivej vrstve aplikácie. Z klienta, cez webový server, zelená je Java, toto miesto používame Tuxedo a dole do databázy. V dolnej polovici obrazovky sa zobrazujú rôzne webové ponuky, ku ktorým sa pristupuje, a potom sme si vybrali malú zelenú šípku smerujúcu nadol. Je v zostupnom poradí a bublina sa zobrazuje hore, webová ponuka ju začína zobrazovať. V skutočnosti ukazujeme čas vykonávania, čas odozvy každej jednotlivej technológie a potom je tu vlastne stĺpcový graf pre každú z týchto webových ponúk, a tak dostaneme, začíname získať predstavu o tom, čo sa deje. Teraz si pamätajte, že sme to všetko zoradili podľa toho, ako by zavolal koncový používateľ, ale ako nájdem koncového používateľa? Prichádzam sem, otváram menu, ktoré mi umožňuje filtrovať konkrétneho používateľa, takže som nastavil tohto používateľa na Alex Net, kliknite na OK, a potom sme sa zamerali len na aktivitu od Alex Net. Teraz to umožňuje, aby IT a IT manažment mohli priamo reagovať na koncového používateľa, a najmä, že sa pozerali na správu obsahu, ktorá mala šesť spustení s časom odozvy trochu viac ako tri sekundy. No tri sekundy sú celkom dobré, nie je to hrozné, ale možno je to pomalšie.
Čo s tým môžem urobiť, je to, že tieto informácie môžem rozrezať a nakrájať na rôzne spôsoby. Mohol by som povedať, dobre, je táto transakcia pomalá pre všetkých? Je to dnes pre Alex pomalšie ako to bolo včera? Je to pomalé pre každého používateľa na konkrétnom mieste? Alebo a to, čo to znamená, mi umožňuje rozrábať plátky a kocky a získať predstavu o tom, čo sa deje, aký univerzálny je problém a je veľmi dôležité vedieť identifikovať koncového používateľa, pretože nejde iba o softvér, infraštruktúra, je to tiež o tom, ako koncoví používatelia vykonávajú aplikáciu. Niekedy môžete mať nového zamestnanca alebo niekoho s novou funkciou úlohy a nie sú oboznámení s niektorými obrazovkami SAP alebo niektorými panelmi PeopleSoft a potrebujú trochu ukazovateľa, možno nechávajú polia prázdne alebo vkladajú zástupné znaky a vynútiť vrátenie veľkých výsledkov z databázy. Ak však máte ID používateľa, môžete mu zavolať skôr, ako vám zavolajú. Ďalšou vecou, ktorú zistíme, je, že keď si uživateľská komunita uvedomí, že IT vie, čo robia, je to mnohokrát, že sa lepšie správať a veľa problémov, veľa vecí, ktoré boli problémami, jednoducho druh vyparujte sa, pretože sa ľudia správajú, operujte trochu opatrnejšie. Používajú systém s väčšou starostlivosťou.
Identifikácia koncového používateľa je nevyhnutná. Nakoniec je nevyhnutné, aby IT mohlo pomôcť konkrétnemu koncovému používateľovi. Teraz, čo sme tu urobili, sme prešli na kartu „Tok“. Môžete to vidieť v ľavom hornom rohu. Zamerali sme sa na jednu konkrétnu súčasť webového menu. A na pravej strane je analýza tejto konkrétnej transakcie, a tak v hornej časti je to vlastne prehliadač a potom zobrazenie, aby sme sa zoznámili s trochou ikon v GUI pre webový server, takže vidíme bod atribútu. A potom je „J“ pre Java a „T“ pre Tuxedo a „Q“ je samozrejme SQL. Táto hotovostná hodnota je v podstate identifikáciou konkrétneho príkazu SQL. Zvážte, čo to robí. Identifikovali sme používateľa na transakciu, do základného kódu aplikácie, vrátane jednotlivých príkazov SQL. Keď sa teraz pozriem na tieto jednotlivé príkazy SQL, vidím, že z celkovej doby odozvy je každý z nich zodpovedný za približne šesť percent, a keď spočítajú prvé štyri príkazy SQL, vzali asi štvrtinu transakcie čas.
Teraz je databáza najjednoduchšie manipulovateľná. Zvyčajne je najjednoduchšie získať lacný, oveľa lepší výkon. Teraz musím ísť trochu hlbšie, aby som zistil, čo sa deje a čo chcem, príkladom je, že dokážem urobiť, je skutočne odhaliť jednotlivé príkazy SQL a vieš, že ťa môžem takmer zaručiť pri každom jedinom zábere na trati. mal nejaký databázový nástroj a to, čo databázový nástroj robí, ale len sa pozerá na jednu technológiu izolovane, je to, že sa pozriete na, zameriavate sa na zdravie tejto technológie. A mnohokrát sa ľudia pozerajú na zoznam desiatich najlepších. Teraz je tento príkaz SQL veľmi rýchly, nebude na zozname desiatich najlepších, ale je to príkaz SQL, na ktorý sa táto transakcia spolieha. Takže to, čo v tomto slove, kontexte, môžem urobiť, je to, že to teraz môžem dať do pozornosti, ale v kontexte jednotlivých príkazov SQL.
Teraz táto osoba môže otvoriť Presné v kontexte individuálneho príkazu SQL a Presné zachytáva skutočný plán vykonávania, ktorý používa, čas vykonávania je dôležitý pre databázu DBA, skutočne sa ukáže, môžete vidieť, že 50 percent čas strávený čakaním na ukladanie. Päťdesiat percent času sa používa v procesore, takže začnete získavať predstavy o tom, kde sa čas trávi, ako by som sa mohol časom krútiť a myšlienkou je dať ľuďom možnosti, pretože rôzne reakcie majú rôzne náklady a riziká spojené, Ideálne je riešenie problému s nízkym rizikom a s nízkymi nákladmi. Teraz, keď je príkaz SQL sledovaný hodnotou hash a v ľavom strede obrazovky je toto malé tlačidlo „Vyladiť“ a to, čo sa chystá urobiť, je presunúť vás na úlohu SQL. A táto úloha SQL je akousi vopred vytvoreným pracovným stolom a čo to robí, je to tak, že mi umožňuje skutočne analyzovať konkrétne to, čo ovplyvňuje príkaz SQL, počnúc vykonávacím plánom. Plán vykonávania vyberie optimalizátor pri analýze príkazu, a to - späť k analógii s jedlom, je to recept, ktorý sa dodržiava pri riešení príkazu SQL.
A niektoré recepty sú zložitejšie ako iné, a preto poskytujeme zistenia. A skutočne to tu ukáže, hej, veľa času robí sekvenčné I / O na konkrétnom indexe. A teraz, keď sa vrátime k kyslíku, sleduj tento index. Bol tento index defragmentovaný v poslednom čase, na čo je zdravie? V akom tabuľkovom priestore žije? Je tabuľkový priestor oddelený od tabuľky, na ktorú odkazuje? A tak vám začína poskytovať najrôznejšie nápady, ako by ste mohli vyriešiť problém. Teraz samozrejme vieme, že vytvárame index. Je to omnoho nižšie riziko, omnoho jednoduchšie ako presun indexu z jedného tabuľkového priestoru do druhého tabuľkového priestoru, takže to, čo chceme urobiť, je druh možností zostavenia, aby sme mohli nasadiť čo najnižšiu cenu, najnižšiu mieru rizika vyriešiť problém.
Presné môžu tiež robiť veci, ako sú zachytené väzobné premenné, ktoré sa prenášajú do príkazu SQL. Je zrejmé, že premenné, ktoré sa prenášajú, budú kontrolovať veľkosť sady výsledkov. A bude kontrolovať, ako dlho trvá vykonanie príkazu SQL a koľko údajov musí aplikácia odovzdať a spracovať pomocou Java, cez .NET, do webového servera a siete, ktoré sa nakoniec vykreslia v prehliadači koncového používateľa., To, čo sa deje v databáze, priamo ovplyvňuje čas prehliadača. Preto bude nevyhnutné mať túto úroveň zviditeľnenia, aby sme vedeli presne, čo sa deje a poskytli DBA čo najviac možností, aby si mohli vybrať, ktorá z nich má v konkrétnej situácii najväčší zmysel.
Toto sú niektoré z úvodzoviek, ktoré pochádzajú z obchodu PeopleSoft, ktorý má globálne nasadenie. Precízne podporuje aplikácie PeopleSoft a SAP, Siebel, Oracle, E-Business Suite, domáce Java a .NET aplikácie. Podporujeme preto, ak uskutočňujete webové služby s viacerými JVM, od Java po .NET späť do Java, môžeme to všetko sledovať. Môže to byť on-prem, môže to byť v cloude. Zásadné je, aby sa veci vybavili nástrojom.
A tak, iba zopár citácií od jedného z našich zákazníkov: „Pred presnosťou používali naše DBA OEM, “ - je to iba databázový nástroj a v podstate povedali: „Hej, príklady vyzerajú skvele.“ Ale mohli by pomôžte povedať alebo vyriešiť problém s konkrétnou transakciou. Presnosť zabezpečila viditeľnosť. A tak mať tieto informácie o príkazoch SQL bolo rozhodujúce pre to, aby DBA mali prehľad o úplnom vytlačení výkonu z databázy. A tak to bolo naozaj pekné. Viac ako niektoré z nástrojov, na ktoré by ste sa mohli pozerať.
A potom sa IT manažment naozaj páčil skutočnosť, že Precise dokázala preložiť zložitú URL na názov panela. Ak teda koncový používateľ zavolá a povie: „Hej, s tým mám problémy, “ môžete izolovať a zistiť, kto je tento používateľ, čo vykonávajú, aký výkon vykonáva, vlastne merajú vykreslenie. čas v prehliadači koncového používateľa. Je to skutočná miera zážitku koncového používateľa. A tak je tiež potrebné mať toto ID používateľa na pomoc konkrétnej osobe, ktorá volá.
Ako to robí Presné? A tak by sme radi zdieľali našu architektúru. Presné by malo žiť na svojom vlastnom serveri a živé vo virtuálnom počítači, môže žiť v cloude. Na rozhraní frontend je funkcia Presná povolená na webe, či už používate dashboardy, výstražné rozhranie alebo Expert GUI. Na strane zhromažďovania údajov môžeme v skutočnosti urobiť agenta bez agentov pre niekoľko rôznych technológií. Často však budeme požadovať agenta a jeho agentov bude mať veľa vecí a mínusov. Veľkým plusom je, že zozbierané údaje môžu byť pred odoslaním v sieti LAN predspracované. To znamená, že môžeme minimalizovať celkový dopad monitorovacieho riešenia na cieľové prostredie.
Teraz uvažujte ako o alternatíve, ak máte agenta bez agentov, je tu stále kolektor údajov, je to len otázka toho, kde žije, a volanie a odovzdávanie nespracovaných údajov o cieľovej aplikácii v sieti LAN. A v skutočnosti je to dosť drahé. A tak predspracovaním môžeme skutočne minimalizovať stopu. Budete mať možnosť monitorovať fyzickú aj virtuálnu stránku. A jedna vec, ktorú som chcel povedať o virtuálnej technológii, je to, že sa skutočne zameriava na využitie. To, na čo sa zameriava, je spor. Kedy technológia VMware skutočne minimalizuje zdroje pre hosťovaného VM? A tak sa to stáva skutočne jednoduchým. Ak sa pozeráte iba na hosťa VM, máte iba časť obrázka. Ak chcete automaticky detekovať a upozorňovať na spor, je to skutočne nevyhnutné.
Presné môžu monitorovať až 500 inštancií, takže veľmi veľké nasadenie má v podstate viac presných serverov. A v prípade globálneho nasadenia to bude zvyčajne presný server v každom dátovom centre. Mimochodom, pre tie najväčšie nasadenia ich môžete skutočne federovať, aby ste sa mohli po celej spoločnosti pozerať na to, čo sa deje, a byť schopný ponúkať prehľady, atď. Teraz, ako som už spomenul, máme veľa technickej analýzy. Nie každý musí ísť do expertného GUI, takže vám ponúkame prispôsobiteľný dashboard. A každý z týchto portletov alebo widgetov je všetko voliteľné. A niekto by mohol len chcieť ísť: „Hej, ako môžete zasiahnuť upozornenie na nejakej úrovni v našom prostredí? Ako sa konajú skupiny koncového použitia z hľadiska výkonnosti? “Alebo možno budete mať otázku o infraštruktúre a možno aj výkon v Tuxedo. Alebo dokonca vyrovnávanie záťaže. V tejto časti na vyrovnávanie záťaže je to trochu zaujímavé. Pozerám sa na portlet uprostred na ľavej strane. Môžete vidieť, že počet spustení je veľmi podobný medzi jednotlivými webovými servermi. Ale doba odozvy je v hornej časti veľmi odlišná. Môžete skutočne vŕtať a zistiť presne dôvod, prečo bol čas odozvy na tomto webovom serveri oveľa pomalší ako v iných.
Jedna vec, ktorá sa týka vyvažovania záťaže, je veľmi dôležitá a politiky vyrovnávania záťaže, viete, nie každá politika vyrovnávania záťaže je vhodná pre každú aplikáciu. Je skutočne užitočné overiť si zásady vyrovnávania záťaže. V skutočnosti sa stretávame s niektorými aplikáciami, ako je napríklad nové používateľské rozhranie PeopleSoft Fluid GUI, kde sa v skutočnosti niektoré webové servery prepnú do režimu offline. A to je niečo, čo je skutočne kritické. Ak nasadzujete GUI aplikácie PeopleSoft Fluid GUI, kontaktujte nás. Môžeme vám poskytnúť veľa informácií a veľa vedomostí o tom, s čím sa ostatní zákazníci stretávajú. Každý z týchto portletov môže byť dosť podrobný. Rovnako ako stredná pravá, s modrou a zelenou, skutočne zobrazuje vzor špičky meča, ukazuje to, že vaša zbierka odpadu v rámci úrovne WebLogic beží tak, ako by ste očakávali. Každý z týchto portletov môže byť vysoko zameraný alebo môže byť veľmi vysoký. A dôvodom, že je to dôležité alebo dôležité, je to často, že nestačí mať tieto informácie iba v IT, niekedy musíte tieto informácie zdieľať s vlastníkmi aplikácií a niekedy s vrcholovým manažmentom o tom, čo sa deje,
Chcel som sa s vami podeliť o niekoľko príbehov, napríklad „Úspech v dátovom centre“. Sú to databázy zamerané a mám ďalšie príbehy zamerané na strednú úroveň. Ale dnes sa naozaj chcem zamerať na databázovú úroveň. Poďme sa pozrieť na obrazovku zamrzne. Teraz sa stalo, že tento konkrétny obchod mal obchodnú SLA, že ak je objednávka prijatá do 15:00, objednávka sa doručí ten deň. Počas tohto časového obdobia je sklad veľmi zaneprázdnený. A potom, keď sa obrazovka zamrzla, bolo to veľmi frustrujúce. A tak supervízor - to je menšia spoločnosť - supervízor skutočne vstúpil do IT a samozrejme ide do DBA a hovorí: „Teraz, čo sa deje?“ A čo sme urobili, dokázali sme presne ukázať čo sa dialo. Teraz je to viacvrstvová aplikácia JD Edwards, toto je obrazovka zákazky odberateľa. Môžete získať predstavu o tom, v čom spočívala firma, v podstate inventár just-in-time, a tak sa v podstate pozeráte na skladové aplikácie. A teraz v podstate odosielate na množstvo rôznych zákazníckych stránok, rôznych obchodov. A to, čo sme urobili, sme otvorili precízne.
Teraz, v tomto prípade, predtým ako sme sa pozreli na Oracle, sa pozeráme na SQL Server, a teraz horná polovica ukazuje skladaný stĺpcový graf, kde príkazy SQL trávia svoj čas počas vykonávania. Každý slabý stav je zahrnutý v osi y. Os x môže samozrejme v priebehu času a môžete vidieť, že stohovaný stĺpcový graf sa mení z časového segmentu v závislosti od toho, čo sa vykonáva a ako používa systém. Teraz v tomto konkrétnom prípade sme sa zamerali na tretiu sekvenciu SQL zhora. Je to textový text SELECT FROM PS_PROD a v tomto stĺpci vidíte, že sme zachytili skutočný plán vykonávania. A môžete vidieť v celom počte popráv. Skutočnosť, že tento konkrétny príkaz SQL bol zodpovedný za 9, 77% spotreby zdrojov v tomto časovom rámci, na ktorý sa pozeráme - a to je dôležitý bod, časový rámec, presná správa priebežnej histórie - a tak sa môžem v zásade vytočiť a zistiť, čo sa stalo v ktoromkoľvek konkrétnom čase alebo v priebehu času. Dokážem zobraziť trendy.
Teraz tento príkaz SQL vidíte, že tento stĺpcový graf je tmavo modrý. To znamená, že využívame všetky procesory. Poďme sa sústrediť kliknutím na toto tlačidlo „TUNE“ na konkrétny príkaz SQL. Čo robíme je, že to vezmeme do tohto predpripraveného seminára, ktorý je navrhnutý tak, aby povedal: „Čo bude DBA vedieť o tomto konkrétnom príkaze SQL?“ A na pravej strane vidíte kartu s názvom „ História “, ktorá bola vybraná. Chcel by som, aby ste teraz urobili nejaký posun smerom na ľavú stranu, kde bude uvedené priemerné trvanie zmien oproti priemeru trvania. A každý z týchto barov predstavuje udalosti každý deň.
Vidíte to v stredu, štvrtok, piatok, čas na vykonanie bol, obraciam sa na bod dva. Os y ukazuje bod štyri sekundy, teda bod dva. V SLA veľmi málo zamrzne obrazovka a operácie sú v poriadku. Nanešťastie 27. februára sa zmenil plán vykonávania, čo spôsobilo okamžitú zmenu v čase vykonávania. Zrazu sa čas vykonávania zvyšuje, štyri X, možno päť X, a veci bežia naozaj zle. Teraz Presné, vo svojom úložisku v skutočnosti časopisy všetky zmeny, ktoré by mohli mať vplyv na správanie. A tu vidíte, že sme skutočne zaznamenali zmeny roviny osi. Jeden v strede hovorí: „Zmenil sa objem tabuľky.“ A tak tabuľky stúpajú a my sme hneď na vrchole, keď sa analyzuje príkaz SQL, optimalizátor vyberie jeden plán vykonávania alebo iný plán vykonávania.
Teraz našťastie, tento týždeň tu v pondelok prepadol, takže to bolo v pravý čas. Bohužiaľ to znova prehodí a vy viete čo, koncoví používatelia začnú predvídať zamrznutie obrazovky a začnú znova predkladať túto obrazovku a tlačia počet vykonaní hore a hore a hore. Máme obrovské množstvo detailov, ale na vyriešenie tohto problému a na jeho zabránenie v budúcnosti potrebujeme jednu ďalšiu informáciu. A to mi ukazuje porovnanie týchto plánov vykonávania. 5. marca, keď to bolo rýchle a efektívne, na ľavej strane je znázornený realizačný plán. Keď bolo 12. marca pomalé a neefektívne, môžete vidieť, že robí pripojenie filtra. Spojenie filtra len núti oveľa viac spotreby procesora a robí oveľa viac práce. Výsledok je identický, robí to oveľa viac práce. Je to, akoby ste šli a dostali svoje zásoby naraz po jednej prísade, namiesto toho, aby ste šli do špajze a dostali všetky prísady naraz. Existuje teda oveľa efektívnejší spôsob, ako to dosiahnuť. Teraz to vedia, DBA bola schopná použiť plán dotazov, aby sa zabránilo tomuto pomalému plánu vykonávania a zablokovala rýchly, vysoký výkon.
Teraz nasledoval ďalší druh vojnového príbehu „Správy sú neskoro“. Myslím si, že s týmto scenárom sa môže veľa ľudí stotožniť. Možno máte prehľady ad hoc, môžete použiť nástroj ako NVISION, možno máte nejaký nástroj na vytváranie prehľadov tretích strán. A čo sa stane, tento nástroj vyvíja SQL. A často nie je SQL tak dobre kódované. A to by sa mohlo týkať aj situácie, keď viete, že máte nejakú aplikáciu tretej strany, správne, kde SQL nebol napísaný interne, a tak ako DBA: „Neovládam SQL, čo urobím to? “No Presné poskytuje niečo, čo neviem o žiadnom inom poskytovaní databázového nástroja, a to je pohľad na objekt. V kombinácii s odporúčaniami a modelovaním. A tak môžeme skutočne zviditeľniť hlavu. Skôr než sa len pozrieme na aktivitu, preskúmajme, aký objekt je v systéme najťažší? A v spodnej časti obrazovky môžete vidieť riadok SQL a stĺpec „v MS-SQL“. A tabuľka riadkových objednávok je desaťkrát náročnejšia ako ktorákoľvek iná tabuľka v systéme. Myslím si, že v hornej polovici si tiež všimnete, alokácia priestoru rastie a na serveri sa môžete pozrieť aj na to, akú verziu softvéru používame. Presné skontroluje sledované zmeny primárnych nastavení. Opäť príčina a následok.
Teraz, so zameraním na riadkovú tabuľku objednávok, môžem robiť s mojím podrobným historickým archívom to, že v skutočnosti môžem korelovať príkazy SQL, ktoré idú proti tabuľke riadkov objednávok. A môžete začať skúmať klauzulu where v týchto príkazoch SQL. A začnete si všimnúť, že klauzula where je medzi rôznymi príkazmi SQL veľmi podobná. A navrhujem vám, aby ste vo svojom záznamovom systéme našli to isté. Pretože obchodní používatelia, obchodní analytici sa budú chcieť zaoberať agregovanou obchodnou činnosťou za posledný deň, posledný týždeň, posledný mesiac, posledný štvrťrok, posledný rok. Uvidíte veľmi podobné prípady, kde sú klauzuly zoradené, zoskupené podľa, a to znamená, že budú existovať určité indexy, ktoré budú mať pre tieto príkazy SQL zmysel.
A preto Precise obsahuje motor odporúčaní, vidíte, že v pravom hornom rohu je možné získať odporúčania. Povedzte: „Hej, spúšťam všetky príkazy SQL, ktoré indexy by ich adresovali?“ Indexy sa vám predložia a môžete skutočne vidieť DBL. Teraz je Precise iba na čítanie, neponúka možnosť kliknúť na tlačidlo a vytvoriť index, ale to je dosť ľahké robiť mimo Precízneho. Ale tu je rozhodujúca vec: Presnosť vám umožňuje vyhodnotiť a modelovať zmeny, takže v ľavom dolnom rohu obrazovky je toto tlačidlo Vyhodnotiť. A čo to robí, je to, že zobrazuje príkazy SQL pred a po.
Pozrime sa na tieto príkazy SQL. Vidíte tu tento stĺpec, ktorý hovorí „v MS-SQL“ a hovorí hodinu, štyri minúty? Tieto najlepšie príkazy SQL vykonávajú alebo spotrebúvajú zdroje v hodnote približne 64 minút. A jeho plánované zlepšenie je 98 percent. Tieto zmeny ušetria spracovaniu hodiny. Ďalší príkaz SQL je 27 minút a v zásade ušetrí tretí. To je asi desať minút spracovania. Celkovo teda týmito navrhovanými zmenami ušetríte hodiny a hodiny na spracovanie. A tak to vedieť dopredu, byť schopný to modelovať. Môžete tiež použiť schopnosť typu „čo ak“, ak poviem: „No, nechcem vytvoriť tento index alebo čo sa stane, ak zmením poradie stĺpca?“ A tak môžem použiť túto schopnosť modelovania presne zistiť, čo sa bude diať.
Ďalšou dôležitou vecou je to, že keď vykonám zmenu, môžem skutočne zmerať jednotlivé príkazy SQL. V predchádzajúcom príklade ste videli históriu príkazov SQL a môžem skutočne overiť, či som dosiahol úspory, ktoré boli modelované. A tak, že spätná väzba, dokončenie spätnej väzby je absolútne rozhodujúce.
Dobre, tu je posledný príklad, ktorý som pre vás chcel mať. Toto je obchod SAP a ako viete, šli na zásadný upgrade, robili nejaké veci s vlastnými transakciami a koncový užívateľ bol v podstate s výkonom nespokojný. A tak sme sa dokázali zamerať na to, čo tento koncový používateľ zažil. A v hornej časti zoznamu môžete vidieť „VYBERTE“ a čas odozvy je niečo vyše 61 sekúnd. Realizácia tejto veci trvá minútu. Teraz môžete vidieť, že máme stohovaný stĺpcový graf, ktorý je zameraný na SAP. Na pravej strane zobrazuje čas klienta, čas zaradenia do frontu. Modrá je čas aplikácie av prostredí SAP, to je ABAP kód a potom databáza. A tak databáza, viete, mohla by to byť Oracle, mohla by to byť SQL, mohla by to byť HANA. V podstate to dokážeme.
Teraz robíme s presnosťou to, že sa zameriame na túto transakciu a na tohto používateľa, aké príkazy SQL vyšli. Opäť, v tomto kontexte spojiť bodky. Teraz tento najlepší príkaz SQL vidíte, že je krúžený, vykonáva sa za dve milisekundy. Naozaj nemôžete obviňovať databázu, ak sa vykonáva tak rýchlo. Počet spustení je veľmi vysoký. V skutočnosti sme schopní sa vrátiť k programátoru ABAP a povedať: „Hej, čo sa deje?“ Skutočne sme zistili, že kód v databáze bol vložený na nesprávne miesto, hniezdil na nesprávnom mieste v rámci slučky, urobil zmeny a potom sme schopní zmerať. Môžete skutočne vidieť, po čom je výkon. Nielen na úrovni príkazu SQL, ale aj na úrovni vlastného kódu. A tak mohli žiť s časom vykonania štyri a pol sekundy. Toto je len zopár príkladov toho, ako by sa dalo využiť presnosti, mohli by ste ich využiť. Rovnako ako rýchla rekapitulácia, Precise ukazuje výkon podľa umiestnenia, podľa ID koncového používateľa, poskytuje kontext cez aplikačný zásobník. Môžete vŕtať na hlavnú príčinu. A myslím si, že jedným z veľkých diferenciátorov je vedieť, nielen príkaz SQL, ale aj dôvod, prečo príkaz SQL beží pomaly, byť schopný identifikovať tvrdenie a v zásade ponúka viac možností na riešenie problémov. To je to, čo ponúka spoločnosť Precise, a môžete nás konzumovať, viete, ľahkým spôsobom alebo ak máte veľmi hlboké a veľmi náročné problémy, radi ich tiež berieme.
Eric Kavanagh: Dobre, musím povedať, že to bolo veľa fantastických detailov, Bill. Ďakujeme vám za zobrazenie všetkých týchto snímok obrazovky. A z môjho pohľadu ste skutočne splnili to, čo som v úvode hodiny vysvetlil, čo je, číslo jedna, musíte mať ten správny nástroj. Musíte mať nástroj, ktorý vám umožní množstvo kontextu, ktoré je potrebné na identifikáciu všetkých prvkov v rovnici, ako už raz niekto povedal vo filme, to bolo trochu vtipné. Ale dovoľte mi ísť ďalej a odovzdať to Dezovi, pretože sa stavím, že má pre vás nejaké otázky, a chcem tlačiť ešte jeden z týchto snímok len na vizuálne sladkosti, ak chcete. Vlastne, počkajte, dovoľte mi to vziať späť. Ale Dez, som si istý, že máš nejaké otázky, zober to.
Dez Blanchfield: Áno, páni. Tento nástroj prešiel dlhou cestou, odkedy som to pôvodne vedel, a nebol som si vedomý, že by ste sa teraz v komore dostali dosť hlboko. Je to celkom ohromujúce. Len veľmi rýchlo, pár vecí. Model nasadenia, môžete naozaj rýchlo, za minútu alebo dve, len načrtnúť tradičný alebo typický model nasadenia. Spomenuli ste, že je k dispozícii ako virtuálny stroj. Môže byť spustený v cloude. A myslím, že jedna z otázok, ktorá sa pravdepodobne objaví, si myslím, že v časti Otázky a odpovede sa objavilo niekoľko otázok. Súhrnne ich zhrnieme, takže bežný model nasadenia a typ požadovanej osi je tradične nasadený na mieste alebo hosťovaný alebo v cloude? Aké typy zavádzacích modelov bežne vidíte? A aký typ osi je potrebný, aby to fungovalo? Musíme zmeniť veci na úrovni zabezpečenia okolo prístupu k sieti atď.? Alebo sa to môže správať ako koncový používateľ?
Bill Ellis: Áno, takže v súčasnosti je väčšina zariadení zapnutá. Čoraz viac ľudí vkladá komponenty aplikačného balíka do cloudu, a preto sa s tým môžeme vyrovnať. Nasadenie, ktoré potrebujeme na spustenie servera, bude spĺňať určité špecifikácie. Potrebujeme databázu na ukladanie historických úložísk, takže splnenie týchto predpokladov je len prvým krokom. Ďalšia vec je, že určite musíme mať určité vedomosti o samotnej aplikácii a inštalácia je riadená pomocou sprievodcu a v podstate vyplňuje medzery. Z dôvodu hĺbky informácií, ktoré dostávame, viete, od úrovne webového procesu po kód, ktorý sa vykonáva, potrebujeme určité privilégiá. Chcem povedať, že máme zabezpečený dátový model alebo model zabezpečenia, pretože agenti sú prevádzkovaní na základe poverení, ktoré sú úplne oddelené od ľudí, ktorí používajú metadáta o transakciách atď.? Presná komunikácia cez TCP cez IP, a preto vyžadujeme otvorenie určitých portov. Ako príklad môžeme uviesť, že náš predvolený port je 2702. Tento typ podrobností je niečo, čo by sa zaujímalo o ľudí, mohli by sme sa k nemu dostať podrobnejšie. Ale zvyčajne sme veľmi rýchly čas na hodnotu. Ak niekto čelí veľkému problému, často ho môžeme nainštalovať a za jasných hodín nasvieti jasné svetlo.
Dez Blanchfield: Áno, určite som to pochopil. V modeli nasadenia ste hovorili o veľmi veľkom meradle a až 500 prípadoch a o tom, ako by sa to dalo spojiť. Na samej vstupnej úrovni, ako to vyzerá, ak niekto chce - pretože viem, že IDERA je veľmi veľká v poskytovaní prístupu k bezplatným skúšobným verziám, ukážkam zadarmo a pamätám si, že som na webe videla takmer všetko, s čím sa dá hrať. Pre ľudí tu, a myslím, že som to zmeškal skôr, ale myslím si, že prišla otázka, ako vyzerá typická stránka a ako k tomu ľudia získajú prístup a začnú s ňou hrať a získajú tento typ. skúsenosti, kde môžu vidieť, či majú spôsob, ako vyriešiť niektoré problémy s výkonom? Môžu si stiahnuť ODS a roztočiť ho na hypervízore, Hyper-V alebo prenosnom počítači, alebo na to, aby ho mohli spustiť, potrebujú vyhradený stroj? Predstavili ste architektúru skôr, ale len veľmi stručne, za minútu alebo dve, ako to vyzerá pre nasadenie na základnej úrovni, aby ste napríklad urobili dôkaz koncepcie?
Bill Ellis: Áno, takže náš model je trochu iný ako nástroje IDERA. Sme viac hodí do scenára Embarcadero, kde by ste chceli kontaktovať niektorého z našich obchodných zástupcov. Chceli by sme sa s vami len porozprávať, aké sú výzvy, a potom by sme, celkom obyčajne, pridelili jednu SE, ktorá by v podstate pracovala pri inštalácii s niekým. Spravidla by ste na svojom notebooku nespúšťali presné nastavenie. Mali by ste mať VM alebo server v dátovom centre, v ktorom aplikácia žije, aby ste mohli robiť zbierky. Ale my vám pomôžeme pri každom kroku. Ak má niekto o to záujem, určite by ste sa mali obrátiť na spoločnosť IDERA.
Dez Blanchfield: Jedna z ďalších vecí, ktorá ma zasiahla, bolo to, že myslím, že veľa z toho, čo sme dnes venovali, je reakcia na problémy s výkonom. Ale zdalo sa mi, že v živých prostrediach, keď ich ľudia používajú, tak ako pri prvej prezentácii niekto zdvihne telefón a povie: „Aplikácia beží pomaly, pomoc.“ Ale napadlo ma, že počas predpredaju aplikácií alebo upgradov alebo nových opráv a opráv, môžete prejsť množstvom plánovania kapacity a stresového testovania a mať precízne prehľad o celom prostredí a skutočne nájsť problémy skôr, ako koncovým používateľom umiestnite prostredie. Je to prípad použitia, ktorý ste predtým videli, alebo to ľudia tiež robia, alebo to nie je typický prípad použitia?
Bill Ellis: Absolútne by sme chceli používať precíznosť počas celého životného cyklu vývoja aplikácií alebo životného cyklu aktualizácie. Precízny pohľad ponúka škálovateľnosť, bude zobrazovať počet vykonaných operácií s časom odozvy. Je zrejmé, že ak počet poprav a čas odozvy spolu narastú, nebudete škálovať a musíte niečo urobiť. Tento druh vecí nesmierne pomohol. Myslím si, že je to o niečo menej pravdivé, ale keď ľudia začali zavádzať produkčné aplikácie do VMware, trochu váhali a bolo to ako, viete, na prvom mieste by boli ako: „Och, musíme to presunúť do fyzicky. “A čo môžeme skutočne urobiť, je ukázať, aká je spotreba zdrojov, aby ste mohli aplikáciu zefektívniť. V každom kroku životného cyklu aplikácie určite chcete použiť program Precise. Musím však povedať, že na produkcii skutočne záleží najviac a precíznosť je zameraná na nepretržité monitorovanie výroby, takže naozaj nechcete spustiť svoje výrobné aplikácie bez viditeľnosti.
Dez Blanchfield: Určite. Jedna ďalšia rýchla otázka práve pri tomto dôkladnom teste, prisťahovalectve, UAT atď. - myslím, že je skvelé mať tento nástroj a predstavujem si, že vývojári aplikácií by radi radi k nemu mali prístup počas životného cyklu vývojového životného cyklu., So zložitejšími architektúrami, ktoré teraz vidíte, sme sa presunuli z vyhradených služieb k virtualizáciám a virtualizáciám, teraz sa presúvame k akýmsi typom, viete, zavedeniu outsourcingu do cloudového hostingu a vidíme tiež prechod. na kontajnerizáciu. Už ste videli, ako to veľa ľudí nasadzuje a modeluje regióny alebo zóny, takže niekto môže mať - av Austrálii máme veľmi veľký problém v oblasti súkromia a viem, že v Európe je to to isté a myslím si, že sa stáva viac prípadom. v USA, kde údaje, ktoré ma dokážu osobne identifikovať, sa musia často nachádzať v bezpečnejšom prostredí až po samotnú aplikačnú vrstvu až po webovú vrstvu. A tak teraz máme tieto nasadenia, kde si ľudia môžu interne uchovávať svoju databázu a ich aplikačné materiály, ale môžu svoju webovú vrstvu a jej dodávku ukončiť a aplikovať a tak ďalej v poskytovateľovi cloudu, ako je Azure alebo, alebo Amazon Web Services a software., Ako to funguje pri bežnom nasadení? Je to tak, že ste práve dostali ďalšiu skupinu zberateľov v regióne a ešte viac sa zhromažďujú? Ako to vyzerá v presnom svete v dnešnom bimodálnom prístupe prevádzkovania IT starých odkazov na jednom mieste a váš tovar je niekedy v cloude?
Bill Ellis: Áno, takže podporujeme zmiešané prostredie. Jedna vec, ktorú treba vziať do úvahy, je, že existujú rôzne zmluvy s poskytovateľmi cloudu. Niektoré z nich nedovolia v cloude žiadny agent ani žiadny vonkajší monitoring. Ak chcete nainštalovať a monitorovať s presnosťou, musíte mať typ zmluvy, ktorá umožňuje tento typ prístupu. Určite existujú určité obmedzenia, s ktorými musíme niekedy pracovať, a preto sú to dôležité kritériá, ktoré zvážite, keď ste, myslím, najprv podpíšete tieto zmluvy a potom a / alebo ak potrebujete nasadiť Presné.
Dez Blanchfield: Áno, videl som veľa prípadov, keď dokonca aj v tradičnom databázovom prostredí, ak to obstarávate v rámci služby, najmä v prípade služieb Azure, ako obstarávate napríklad HDInsight alebo SQL ako služba, ako platforma, vaše bežné nástroje sa môžu ponoriť len tak hlboko, pretože nie sú skutočne také, že by ste sa chceli pozrieť na to, čo je pod kapotou. A tak skončíte s určitou úrovňou alebo hĺbkou, ktorú môžete sledovať, a zrazu nemôžete vidieť za magickou oponou. Je samoobsluha vecou? Je to tradične niečo, čo by bežalo vo vnútri sieťového operačného centra, kde by technický tím, ľud pod CIO mal prístup iba, alebo je to tiež niečo, čo môžete poskytnúť koncovým používateľom na úrovni prístupu? Možno to nie je nevyhnutne recepcia a tradiční ľudia v oblasti ľudských zdrojov a financií, ale dôvtipnejší používatelia, ktorí robia, viete, napríklad, vedci s údajmi, poistní matematici, štatistici, ľudia, ktorí skutočne pracujú. Je to tak, že môžu získať prístup k nejakému samoobslužnému prístupu, aby videli, čo sa deje, keď spustia tieto ťažké otázky a kde sa objaví bolesť, aby mohli nejakým spôsobom vyladiť, ako sa vyťaží ich pracovné zaťaženie?
Bill Ellis: V rámci programu Precise je dosť dobrá bezpečnosť, takže môžete nastaviť používateľov, ktorí majú rôzne úrovne prístupu. Na veľmi základných úrovniach poskytujú dohľad len riadiace panely. A potom v rámci, viete, ak niekto chcel ísť do Expert GUI, môžete tak trochu obmedziť to, čo sú schopní vidieť a čo môžu robiť. A akési krúženie späť k vašej predchádzajúcej otázke, že viete, v oblasti zdravotnej starostlivosti máte všetky zákony HIPAA, a preto sú určite určité úvahy a v skutočnosti existujú určité možnosti nasadenia, aby sme s nimi mohli pracovať v oboch prostrediach. Jednu vec, ktorú je potrebné vziať do úvahy s údajmi, ktoré ste videli v tejto prezentácii, sú všetko metaúdaje o výkonnosti, nie obsah tabuliek, viete, a teda je to naozaj, že sa do týchto typov nedostane. obavy o ochranu súkromia.
Dez Blanchfield: Áno, páčilo sa mi to. Mal som okamih eureka o tom, ako sa tvoj štvrtý alebo piaty snímok obrazovky prichytáva a uvedomil som si, že iba ťaháš výkon, nie len, ale ťaháš údaje o výkone, ťaháš veci, ako ste povedali, metadáta z na rôznych úrovniach zásobníka, vlastne sa nepozeráte na obsah. A myslím si, že je to zaujímavá vec, pretože je to jeden z tých nástrojov, kde by ste ho mohli nasadiť krátkodobo a pozrieť sa, čo sa deje v prostredí, ale nemusíte mať prístup k samotným údajom. Môžete sa dokonca pozrieť na spôsob, akým sú posádky vedené. Myslím, že posledná vec, len rýchlo, a potom sa vrátim späť Ericovi, takže ak máte otázku, potom si nechajte Rebeccu zabaliť, už ste spomenuli, že režijné náklady sú nominálne, je to tak, že je to tak dokonca viditeľné režijné náklady z monitorovacej strany vecí a len sledujúce pozadie, alebo je to tak zanedbateľné množstvo režijných nákladov, že to jednoducho nestojí za zváženie?
Bill Ellis: Áno, takže si myslím, že v databázovej vrstve je každá technológia trochu iná. V databáze úrovne Precise je celkom dobre známe, že prekonáva najnižšiu réžiu. V strednej vrstve je, viete, existuje určitý druh vyrovnávacieho aktu, viete, nie je to iba presné, týka sa to všetkých, pokiaľ ide o viditeľnosť a režijné náklady. Jednou z vecí je, že ponúkame množstvo sofistikovaných nástrojov na kontrolu toho, čo je to režijné náklady. Sme navrhnutí pre výrobu a ako viete, určite je užitočné zredukovať toľko problémov v zárodku vývoja a kontroly kvality, ale viete, nič také nevie, čo sa deje vo výrobe.
Dez Blanchfield: Eric, máš pre vás nejaké posledné otázky?
Eric Kavanagh: Áno, len poviem, že si myslím, že ste odviedli skvelú prácu a poukázali na to, že kontext je skutočne kľúčom a je to skoro ako keby sme sa posunuli smerom k tejto ére internetu vecí, chcete, aby bolo všetko vybavené. A myslím si, že súčasným štandardom vo výrobe je to, čo je dobrá správa, však? Pretože chcete mať možnosť získať informácie zo všetkých týchto rôznych prostredí a spojiť ich všetky dohromady. A myslím, že vám to len odovzdám kvôli niektorým následným pripomienkam. To je to, na čo sa zameriavate, je vizuálne rozhranie, prostredníctvom ktorého môže niektorý analytik, analytik v zásade sledovať a analyzovať, čo sa deje v tomto zložitom prostredí, a potom zistiť, čo sa má zmeniť. Pretože to nie je len nástroj. Musíte mať tento nástroj, ale potrebujete toho človeka, ktorý sa bude venovať tomuto detailu a nájde odpovede, nie?
Bill Ellis: Áno, vidím to ako varenie na vrchol a určovanie priorít tam, kde je najviac spätného odkúpenia, viete? Ak sa ukáže, že je to iná situácia, pretože nie každý problém je v databáze. Ak je databáza, viete, veci sa vykonávajú o desatinu sekundy, ale na aplikačnej vrstve to trvá tri sekundy, to je miesto, kde je najviac spätného odkúpenia. A taký druh schopnosti izolovať problémovú úroveň a potom, čo sa deje v rámci tejto úrovne, sa skutočne sústrediť na to, kde je spätný nákup. To skutočne urýchľuje rozlíšenie a optimalizáciu aplikácie a je to omnoho rýchlejšie a omnoho lepšie a oveľa zábavnejšie, ako sa ľudia zhromaždili v konferenčnej miestnosti a pokračovali: „No to nie som ja, musí to byť niekto iný.“
Eric Kavanagh: Správne. Inokedy som videl skvelú mému, ktorá povedala niečo ako: „Buďte informovaní, nielen sa vyjadrujte.“ Vstúpite na stretnutie, máte informácie, môžete poukázať na údaje. To je kľúč a my sa tam dostávame, vďaka bohu. Dobre ľudia, ideme do toho a zabalíme ich, ale všetky tieto webové vysielania archivujeme pre neskoršie prezeranie. Neváhajte a vyskúšajte to kedykoľvek. Zoznam všetkých našich webových vysielaní teraz, sérií Hot Tech a Briefing Room na adrese Techopedia.com, takže choďte online a pozrite sa na týchto ľudí. S týmto sa ťa rozlúčime. Ďakujem za tvoj čas dnes, Bill. Vďaka tebe a všetkej tvrdej práci, Dez. A nabudúce sa s tebou rozprávame, ľudia. Dávaj pozor. Zbohom.
