Avtor osebja Techopedia, 2. novembra 2016
Odvzem: Voditelj Eric Kavanagh razpravlja o uspešnosti aplikacije in kako izboljšati učinkovitost z dr. Robin Bloor, Dez Blanchfield in IDER-jevim Billom Ellisom.
Trenutno niste prijavljeni. Če si želite ogledati video, se prijavite ali prijavite.
Eric Kavanagh: Dame in gospodje, pozdravljeni in dobrodošli še enkrat k Hot Technologies. Da, resnično! Moje ime je Eric Kavanagh, danes pa bom vaš gostitelj novega spletnega prenosa v tej zares zabavni in vznemirljivi seriji, ki jo imamo kot kompliment k naši seriji Briefing Room. Naslov je »Pospeševanje aplikacij: Hitrejša zmogljivost za končne uporabnike.« Pridi, kdo ne želi tega? Če sem tisti mož, ki pomaga, da se vaša aplikacija hitreje zažene, mislim, da sem tisti, ki mi kupi pivo v baru po opravkih. Hoditi je treba in pospešiti uporabo vsakogar.
Drsnik o tvojem resnično je, na Twitterju me objavi @Eric_Kavanagh. Vedno se trudim slediti nazaj in vedno me posnamejo, če me omenite, zato me ne pozabite.
Celoten namen te oddaje je osredotočiti se na različne vidike poslovne tehnologije in resnično pomagati določiti določene discipline ali določene obraze, če hočete. Velikokrat se bodo prodajalci pobrali pri določenih trženjskih pogojih in govorili o tem, kako delajo to ali ono ali kakšno drugo stvar. Tokratna oddaja je bila resnično zasnovana tako, da pomaga našemu občinstvu razumeti, kaj mora imeti programsko orodje, da bi lahko postalo vodilno v svojem prostoru. Oblika tega sta dva analitika. Vsak gre najprej, za razliko od sobe za informiranje, kjer gre prodajalec prvi. Vsakdo lahko prevzame svoje mnenje o določeni vrsti tehnologije.
Danes govorimo o pospeševanju aplikacije. Zaslišali se bomo z Dez Blanchfield in tudi doktorjem Robinom Bloorjem - danes smo po vsem svetu - in nato Bill Ellis pokliče iz večjega območja Virginije. S tem bom to izročil našemu prvemu voditelju, dr. Bloorju. Mimogrede smo napisali hashtag #podcast, zato lahko tvitnite. Vzemi stran.
Dr. Robin Bloor: V redu, hvala za uvod. Učinkovitost aplikacij in raven storitev - to je nekakšno področje, na tem področju sem v preteklih letih veliko delal, v smislu, da sem v resnici opravil ogromno dela pri spremljanju uspešnosti in delu v enem tako ali drugače, kako preizkusiti in izračunati te stopnje. Treba je povedati, da smo nekoč - nekoč že imeli to obdobje, ko so ljudje gradili sisteme v silosih. V bistvu veliko dela, ki ga dejansko morajo opraviti, da bo sistem uspešno deloval, če je bil v silosu, pravzaprav ni bilo preveč težko, ker je treba upoštevati zelo malo, zelo majhno količino spremenljivk. Takoj, ko smo se pravilno povezali, je v enačbo prišla interaktivna in storitvena orientacija. To je postalo malo težko. Zmogljivost je lahko enodimenzionalna. Če samo pomislite na to, da bi aplikacija večkrat izvedla določeno kodno pot, se vam zdi smiselno, pravočasno, videti kot enodimenzionalna stvar. Takoj ko začnete govoriti o ravneh storitev, pravzaprav govorite o več stvareh, ki tekmujejo za računalniški vir. Postane večdimenzionalno zelo hitro. Če začnete govoriti o poslovnih procesih, lahko poslovne procese povežete iz več aplikacij. Če govorite o storitveno usmerjeni arhitekturi, potem lahko določena aplikacija dejansko dostopa do zmogljivosti več aplikacij. Potem postane zelo zapletena stvar.
Pogledal sem - že zdavnaj sem sestavil ta diagram. Ta diagram je star vsaj 20 let. V bistvu ji pravim Diagram vsega, ker je to način, kako pogledati vse, kar obstaja v IT okolju. To so res samo štirje kosi: uporabniki, podatki, programska in strojna oprema. Seveda se sčasoma spreminjajo, a dejansko se zavedaš, ko pogledaš, da je vsaka od teh kosov hierarhična eksplozija. Strojna oprema da, strojna oprema je lahko strežnik, vendar strežnik je sestavljen iz morda več CPU-jev, omrežne tehnologije in pomnilnika, in to, nekako veliko nadzornikov, kot se zgodi. Če to dejansko pogledate, se vse razgradi na koščke. Če dejansko razmišljate o poskusu orkestriranja vsega tega v zvezi s podatki, ki se spreminjajo, se delovanje programske opreme spreminja, ker se strojna oprema spreminja in tako naprej, in tako naprej, pravzaprav gledate na zelo težko situacijo z več različicami. To je krivulja zahtevnosti. Seveda je krivulja zahtevnosti za skoraj vse, toda videl sem, da se vedno znova pojavlja, ko govorimo o računalnikih. V bistvu, če postavite vozlišča na eno os in pomembne povezave na drugi osi, na koncu dobite krivuljo zahtevnosti. Skoraj ni pomembno, kakšna so vozlišča in povezave, kar se bo zgodilo, če želite predstaviti rast glasnosti v telefonskem omrežju.
Pravzaprav, ko govorite o vozliščih v računalniškem okolju, govorite o posameznih stvareh, ki jih skrbi drug za drugega. Izkazalo se je, da je zapletenost odvisna od raznolike strukture in različnih omejitev, ki se jih poskušate držati. Tudi številke. Ko se številke dvignejo, gredo noro. Včeraj sem imel zanimiv klepet, z nekom sem se pogovarjal - ne morem omeniti, kdo je bil, ampak v resnici ni pomembno - govorili so o spletnem mestu, ki je imelo 40.000 - to je štirih nič, 40.000 - primerkov baz podatkov na mestu. Samo pomislite na to - 40.000 različnih baz podatkov. Seveda edino, kar smo imeli - očitno so imeli veliko, veliko tisoč aplikacij. Govorimo o zelo veliki organizaciji, vendar je ne morem imenovati. To dejansko pogledate in pravzaprav poskušate na tak ali drugačen način doseči raven storitev, ki bodo ustrezne za več uporabnikov, z več različnimi, če želite, pričakovanji. To je zapletena situacija in to, kar resnično pravim, je, da so te stvari zapletene. Številke se vedno povečajo. Omejitve določajo poslovni procesi in poslovni cilji. Opazili boste, da se pričakovanja spreminjajo.
Spominjam se, da so takoj, ko so se pojavili Gmail, Yahoo in Hotmail, vsi ti poštni sistemi, ljudje začeli pričakovati, da bodo njihovi notranji poštni sistemi znotraj organizacije zaslužili ravni storitev teh ogromnih operacij z ogromnimi strežniškimi kmetijami zunaj organizacije in začeli so se izvajati pritiski, da bi se vse to zgodilo. Dejansko so sporazumi na ravni storitev ena stvar, pričakovanja pa druga stvar in se med seboj borijo znotraj organizacije, nerodna stvar. Tukaj je le poslovna perspektiva. V nekaterih sistemih je optimalni odzivni čas desetina sekunde človekovega odzivnega časa. Ena desetina sekunde je čas, ko vas potrebuje, da vas kobra ugrize. Če stojite pred kobro in se odloči, da vas bo ugriznil, je že prepozno, ker se ne morete odzvati v eni desetini sekunde. Ena desetina sekunde je približno toliko časa, ko žoga zapusti roko vrča, da doseže tipa s palico. V bistvu, ko vidi žogo vrženo, se mora odzvati točno v tem trenutku. Človeški odziv, nekako zanimiva stvar. Programska oprema do programske opreme ima očitno večje pričakovanje.
Nato se znajdete v nekaterih situacijah, za katere menim, da so tiste tržne situacije, kjer je prva vrednost, kjer je poslovna vrednost. To je tako, kot če želite prodati določeno delnico na borzi, je verjetno manj, na primer, ker mislite, da gre navzdol in veliko drugih ljudi misli, da gre navzdol, dobite najboljšo ceno, če pridete na trg najprej. Veliko je situacij, prikazovanja oglasov in podobnih stvari, zelo podobna situacija. To gibanje imate v smislu pričakovanja o ravni storitev. Imate eno stvar, ki je nekakšen stekleni strop za človeški odziv. Če je to programska oprema, če imate takšno zgornjo mejo, potem ni najboljše ravni storitev. Hitreje kot vsi drugi so najboljši.
V redu, to je, mislim, zadnji del, ki sem ga naredil, ampak to je samo zato, da vam predstavim široko sliko zahtevnosti, ko dejansko pogledate zahteve organizacije, storitev. Tu greš po levi strani, upravljaš sistem, to je nabor programske opreme, ki služi za upravljanje storitev, ki poskuša upravljati raven storitev. Zgoraj imate upravljanje poslovanja. Potem, če pogledate tukaj spodaj, območje za avtomatizacijo upravljanja storitev, imate razdrobljene storitve, ki se razvijajo v standardizirane storitve, če dejansko želite investirati v tovrstne stvari, ki se razvijajo v integrirane storitve, ki se razvijajo v optimizirane storitve . Večinoma so to storili samo ljudje, le v spodnjem levem kotu tega. Mogoče malo upravljanje storitev. Upravljanje uspešnosti poslovanja, zelo redko. Razdrobljeno, skoraj vse. Popoln svet bi napolnil to mrežo. Instrumentacija - omenila sem težavo s podoptimizacijo. Lahko optimizirate dele sistema in to ni dobro za celoten sistem. Če boste srce naredili optimalno, bi lahko kri prehitro krožila za ostalimi organi. To je težava z velikimi organizacijami in storitvami. Jasno je, da ničesar ne bo mogoče doseči brez zapletenih orodij, ker so spremenljivke pravkar prišle - no, preveč je spremenljivk, ki bi jih lahko poskusili in optimizirati.
Potem ko bom to rekel, bom prenesel Deza, ki bo v celoti govoril o nečem drugem.
Dez Blanchfield: Hvala, Robin. Tako kot dr. Robin Bloor sem tudi jaz preveč let razmišljal o delovanju zelo zapletenih sistemov v zelo velikem obsegu. Verjetno ne povsem istega obsega kot Robin, toda uspešnost je vsakodnevna tema in del našega DNK je, da želimo performans, da iz vsega naredimo najboljše. Pravzaprav sem uporabil grafiko ene mojih najljubših stvari na svetu, dirkalnih vozil formule I, kjer cel planet še nekaj časa sedi in opazuje, kako avtomobili zelo hitro krožijo. Vsak vidik formule I ne bi smel biti natančen. Veliko ljudi se ukvarja s športom, ker mislijo, da je to zapravljanje denarja. Izkazalo se je, da avto, ki ga vozimo vsak dan, da otroke ob koncu tedna spuščajo v nogomet in v šolo, izhaja iz razvoja in raziskav, ki temeljijo na uspešnosti. To je nekakšno življenje dirk formule I. Vsakodnevna tehnologija, vsakodnevna znanost, pogosto izvira iz nečesa, kar je bilo usmerjeno izključno v visoke zmogljivosti.
Resničnost pa je, da je naš novi "vedno vklopljen" svet, ki zahteva 100-odstotno nadaljevanje - kot je že prej omenil Robin - s takšnimi stvarmi, kot so uvedba spletne pošte in drugih storitev, ki jih jemljemo za samoumevne v nenehnem prostoru, in zdaj pričakujemo, da v naše podjetje in delovno okolje. V resnici je, da biti pripravljen ne pomeni vedno, da izpolnjujete dogovor o ravni storitev. V zvezi s tem moram upoštevati potrebo po upravljanju uspešnosti aplikacij in sporazumov o ravni razpoložljivosti storitev v zadnjem desetletju. Ne poskušamo več skrbeti za delovanje enega sistema. Ko je bil svet nekoliko enostavnejši, bi utegnili imeti situacijo, ko lahko en sam strežnik z več storitvami spremljamo v živo in je bilo relativno enostavno podpirati. Lahko bi - in to je moja majhna stvar, zaradi katere smo se pred mnogimi leti skrbeli, ko sem bil na primer sistemski skrbnik -, bi pogledali naokoli, ali je storitev običajno pripravljena in se odziva? Ali se lahko na primer prijavim v terminal? Ali se operacijski sistem odziva in ali lahko vnašam ukaze? Ali se aplikacije zaženejo? Ali lahko vidim procese in pomnilnik pri izvajanju stvari in I / O-ja po omrežju in podobno? V dneh osrednjega okvirja ste lahko slišali kasete, na katerih zip-zip-zip pada papir, iz njih pa papir.
Se aplikacije odzivajo in ali se lahko prijavimo in naredimo stvari na njih? Ali se uporabniki lahko povežejo z nekaterimi od teh strežnikov? Se nadaljuje. So dokaj temeljni, veste. Potem nekaj smešnih - je služba za pomoč zelena? Ker če ne, potem vse teče v redu in kdo bo dobil krofe? Življenje je bilo v tistih dneh res preprosto. Tudi v tistih dneh, in potem govorim pred 20–30 leti, je bila zapletenost še vedno zelo velika. Lahko bi na dokaj preprost način upravljali sporazume o ravni storitev in spremljali uspešnost. Ne moremo več ročno, kot je namigoval Robin. Izziv je prevelik. Dejstvo je, da lahko nekaj dobrih aplikacij, skrbnikov, sistemskega omrežja in baze podatkov skrbniki spremljajo in izpolnjujejo SLA-je za uspešnost. SLA so tako daleč zdaj, da sem se spopadel sinoči, ko sem sestavljal svoje zadnje opombe, da sploh pomislim na leto, ko sem nazadnje uspel pogledati sistem zelo zapletenega svežnja, ga smiselno razumeti in celo razumeti, kaj je pod pokrovom, prihajam iz globoko tehničnega ozadja. Ne predstavljam si, kako je to biti vsakodnevno v upravnem smislu.
Kaj se je zgodilo? No, leta 1996 so se aplikacije, ki jih poganjajo baze podatkov, preoblikovale z internetnim razcvetom. Precej nas je šlo skozi to. Tudi če niste bili okoli internetnega buma, lahko preprosto pogledate naokoli in spoznate, da v vsakdanjem življenju zdaj na internet priklopimo vse. Verjamem, da imamo toaster, ki očitno prihaja z možnostjo dostopa do Wi-Fi-ja, kar je smešno, saj ne potrebujem svojega toasterja, povezanega z internetom. V 2000-ih, zlasti v zgodnjih 2000-ih, smo se morali spoprijeti s to množično rastjo zapletenosti, ki je zagotavljala uspešnost storitev v razmahu dot-com. Nato še ena smešna nerodna iskrica v spletu 2.0, kjer so nastali pametni telefoni in zdaj so bile aplikacije 24/7 v naših rokah in so bile vedno vklopljene.
Zdaj je leto 2016, soočeni smo s še eno trmo v obliki oblaka, velikih podatkov in mobilnosti. Gre za sisteme, ki so ravno tako veliki, da jih je pogosto težko razumeti in postaviti v navadno angleščino. Ko pomislimo na to, da imajo nekateri veliki enorogi, o katerih govorimo, na desetine sto petabajtov podatkov. To je celotno podnožje prostora na disku in prostora za shranjevanje samo za shranjevanje e-pošte, slik in socialnih medijev. Ali pa je v nekaterih primerih v transportni in ladijski logistiki vse v bančništvu, tam, kjer je vaš denar, ali kje je vaša pošta ali vaša, kjer je stvar, ki ste jo kupili na eBayu. Naslednji velik val, s katerim se bomo soočili, je ta zelo velik izziv interneta stvari.
Če to ne bi bilo dovolj slabo, bomo vgradili umetno inteligenco in kognitivno računalništvo v skoraj vse. Te dni se pogovarjamo s Siri in Googlovimi motorji. Vem, da ima Amazon enega svojega. Baidu imajo eno od teh naprav, s katerimi se lahko pogovarjate, pretvorijo jo v besedilo, ki gre v običajen sistem, baza podatkov poišče poizvedbo in se vrne v postopek. Razmislite o kompleksnosti, ki spada v to. Resničnost je, da kompleksnost današnje standardne zbirke aplikacij daleč presega človeške zmožnosti. Ko razmišljate o vsem, kar se zgodi, ko na napravi s pametnim telefonom ali tabličnim računalnikom pritisnete gumb, govorite z njim, pretvori to v besedilo, požene vse do interneta v sistem za zaledje, prejme sprednji del ki ga pretvori v poizvedbo, poizveduje skozi aplikacijski sklad, gre skozi bazo podatkov, zadene disk, se vrne ven, na sredini pa je omrežje nosilcev, tam je status statusa lokalnega omrežja. Kompleksnost je nora.
To učinkovito trdimo kot hipskrbno. Kompleksnost in hitrost hiperskrvnosti je le zalivanje oči. Aplikacije in baze podatkov so postale tako velike in tako zapletene, da je upravljanje uspešnosti v resnici sama po sebi znanost. Mnogi ga označujejo kot raketno znanost. Imamo tehnologijo na kraju samem, imamo zunanjo tehnologijo, imamo vrsto možnosti podatkovnega centra; fizični in virtualni. Imamo fizične in virtualne strežnike, imamo oblak, imamo infrastrukturo kot storitev in platformo kot storitev in programsko opremo kot storitev, je stvar, ki jo zdaj jemljemo kot samoumevno. Slednje, programska oprema kot storitev, je postalo strašljivo nekaj časa nazaj, ko so finančni direktorji in deli organizacije spoznali, da lahko sami prevzamejo kreditno kartico in kupijo stvari ter potujejo po CIO in smo to dejansko poimenovali „senca IT "in CIO-ji zdaj poskušajo vrniti to kontrolo hrbta in se boriti nazaj.
V infrastrukturi imamo programsko definirano mreženje, virtualizacijo omrežnih funkcij, spodaj pa smo verjetno že končali, zdaj imamo mikro storitve in aplikacije aktivnih storitev. Ko kliknete URL, je na koncu tega naslova kup poslovne logike, ki opisuje, kaj potrebuje, da ga dejansko dostavi. Ni nujno, da čaka na to vnaprej izdelana logika. Imamo tradicionalne baze podatkov na eni strani, ki so zelo veliko in veliko. Imamo podobno infrastrukturo in ekosisteme Hadoop na drugem spektru, ki so ravno tako veliki, da, kot sem rekel, veste, ljudje zdaj govorijo o sto petabajtov podatkov. Imamo mobilnost kompleksnosti, kar zadeva naprave, ki nosijo naokoli, prenosnike in telefone in tablice.
BYOD imamo v nekaterih zaprtih okoljih in vedno bolj, odkar izkušeni ljudje Gen Y prinašajo svoje naprave. Preprosto jim pustimo, da se z njimi pogovarjajo o spletnih vmesnikih. Preko interneta ali prek Wi-Fi-ja imamo v kavarni spodaj brezplačen brezžični internet, ko pijejo kavo. Ali pa naš interni Wi-Fi. Stroj za stroj je zdaj vedno prisoten. To ni neposredno del interneta stvari, ampak je tudi povezano. Internet stvari je povsem nova igra kompleksnosti, ki se trudi z mislimi. Umetna inteligenca in če mislite, da je to, kar se zdaj igramo, z vsemi Siri in drugimi sorodnimi napravami, s katerimi govorimo, zapleteno, počakajte, da pridete do situacije, ko vidite nekaj, imenovano Olli, ki je 3-D tiskani avtobus, ki sprejme približno šest ljudi in se lahko sam vozi po mestu, z njim pa lahko govorite navadno angleško in odgovoril vam bo. Če zadene promet, se bo odločil, da bo levo ali desno zavil z glavnega območja, kjer je prometa. Ko zavijete in vas skrbi, zakaj je zavijal levo ali desno z glavne ceste, vam bo rekel: "Ne skrbite, levo bom zavil. Pred nami je promet in jaz ga bom obvozil. "
Upravljanje zmogljivosti vseh tamkajšnjih sistemov in vse zapletenosti, sledenje kam gre ta podatek, ali gre v bazo podatkov, vse medsebojne povezave in vse ustrezne bite, je samo nadlegovanje. Resničnost je, da upravljanje zmogljivosti in SLA-jev pri današnjih hitrostih in obsegu zahteva orodja in sisteme, privzeto pa to ni več nekaj, kar bi si mislili, da bi bilo lepo imeti orodje - to je pogoj; je preprosto nujno. Tu je nekaj le majhnega primera, seznam diagramov oblikovanja aplikacij na visoki ravni za oblak OpenStack, ki je programsko določen. To je samo velik kos. To niso samo strežniki in baze podatkov. Tukaj vsak modri plavček predstavlja kopice stvari. V nekaterih primerih tečejo datoteke in strežniki ali na stotine baz podatkov ali seveda ne več kot desetine tisoč majhnih kosov logike aplikacij. To je majhna različica. Ko se začnete razmišljati o kompleksnosti, ki nastane pri tem, je resnično zelo mučno. Danes bom tudi v samo velikem podatkovnem prostoru postavil nekaj posnetkov zaslona samo blagovnih znamk. Ko razmišljate o vseh delih, ki jih moramo tukaj upravljati, ne govorimo samo o eni blagovni znamki, to so vse blagovne znamke v veliki podatkovni pokrajini in vrhunski blagovni znamki, ne le vsaka majhna ali odprta koda. Izgledaš in misliš, da je to precej moteča karta.
Oglejmo si le nekaj navpičnic. Vzemimo za primer trženje. Tu je podoben grafikon, vendar iz tehnoloških paketov, ki so na voljo samo v marketinški tehnologiji. To je graf iz leta 2011. Tu je različica 2016. Samo pomislite, to je samo število znamk izdelkov, ki jih lahko tržite za tehnologijo v zvezi s tržno tehnologijo. Ne zapletenost sistemov znotraj, ne različna aplikacija in splet ter razvoj in omrežje ter vse ostalo. Samo znamka. Tu je prej, pred petimi leti in tukaj je danes. Samo poslabšalo se bo. Zdaj smo tam, kjer je resničnost, ljudje preprosto ne morejo zagotoviti vseh sporazumov o ravni storitev. Ne moremo se potopiti v dovolj podrobnosti, dovolj hitro in v obsegu, ki ga potrebujemo. Tu je primer, kako izgleda nadzorna konzola. To je tako, kot da je skoraj dvajset čudnih zaslonov zlepljenih skupaj, pretvarjajo se, da so en velik, velik projekcijski zaslon, ki spremlja vsak majhen delček. Zdaj je tukaj zanimivo, blagovne znamke ne bom omenil, vendar ta platforma za spremljanje spremlja eno samo aplikacijo v logističnem in ladijskem okolju. Samo ena aplikacija. Če pomislite na to, o čem je Robin govoril, kje imajo lahko organizacije zdaj 40.000 baz podatkov v proizvodnih okoljih. Ali lahko samo predstavite, kakšne bi lahko bile 40.000 različic te zbirke zaslonov, ki spremljajo eno aplikacijo? To je zelo pogumen svet, v katerem živimo. Kot je dejal Robin in bom popolnoma 100-odstotno odmeval, da je brez pravih orodij, brez prave podpore in glasbe na mizi z uporabo teh orodij uspešnost aplikacij izgubljena igra za ljudi in to je treba storiti z orodji in programsko opremo.
S tem bom prenesel na naše prijatelje v IDERA.
Eric Kavanagh: V redu, Bill.
Bill Ellis: Hvala. Tu delim svoj zaslon. Verjetno lahko kdo potrdi, da lahko vidite moj zaslon?
Dr Robin Bloor: Ja.
Eric Kavanagh: Izgleda, da je vse v redu.
Bill Ellis: Hvala. Edino, na kar se je skliceval, je, da res nestrpno čakam, da je samovozeči avtomobil. Ena stvar, o kateri nisem slišal, da bi kdo govoril, je, kaj se zgodi, ko sneži? Nekako se sprašujem, ali so inženirji v Kaliforniji ugotovili, da v drugih delih države precej sneži.
Dez Blanchfield: Všeč mi je, spomnil se bom tega.
Eric Kavanagh: Tipična milja na uro.
Bill Ellis: Tu smo, da govorimo o upravljanju uspešnosti aplikacij v zapletenem okolju. Ena stvar, o kateri rad govorim, je, da veliko ljudi, ko govorijo o uspešnosti, naravi reakcije je, hej več strežnikov, več CPU-ja, več pomnilnika itd. Druga stran tega kovanca je učinkovitost obdelave. Res, to sta dve strani istega kovanca in oba si bova ogledala. Končni cilj je izpolnjevanje sporazumov o ravni storitev za poslovne transakcije. Konec koncev vsa ta tehnologija obstaja za podjetja. Govorili smo o tem, da imamo prvo bazo podatkov o upravljanju uspešnosti v industriji. Ideal tega je, da se prilega idealnemu modelu delovanja in upravljanju od začetka življenjskega cikla aplikacij.
Teme se zares sesedejo na štiri komade; eden je postopek upravljanja uspešnosti. Z vsemi smo se pogovarjali in vsi imajo orodje. Če nimajo orodij, imajo skripte ali ukaze, toda manjka jim kontekst. Kontekst je preprosto povezovanje pik čez nabore aplikacij. Te aplikacije za - temeljijo na brskalniku. Od stopnje do stopnje so zelo tesno povezane. Pomembno je tudi delovanje medsebojnih ravni. Nato govorimo o poslovni transakciji. Vidnost bomo zagotovili ne le tehničnim osebam, temveč tudi lastnikom aplikacij in upravljavcem operacij.
Imam nekaj študij primerov, s katerimi lahko samo delim, kako so jih stranke uporabile. Tukaj je zelo praktičen del predstavitve. Oglejmo si, kaj se običajno zgodi. Všeč mi je, da diagramiram - bil je kot neverjeten kolaž tehnologij. Število tehnologij v podatkovnem centru je pravkar raslo, raslo in raslo. Medtem končnemu uporabniku ni mar za to in na to ne pozabi. Preprosto želijo izvesti transakcijo, ali je na voljo, ali naj se ta hitro zaključi. Ponavadi se strokovnjaki na področju IT ne zavedajo, da so končni uporabniki imeli težave, dokler se niso sami prijavili. To začne dolgotrajen počasen postopek in pogosto frustriranje. Kar se zgodi, bodo ljudje odprli svoja orodja in si ogledali podmnožico svojih aplikacij. S to podskupino je zelo težko odgovoriti na najpreprostejše vprašanje. Je običajno, da imate težave? Kakšna transakcija je? Kje je v paketu aplikacij ozko grlo? Če ves ta čas porabite za to, da ne morete odgovoriti na ta vprašanja, na koncu porabite veliko časa in energije, veliko osebja, sredstev in energije.
Da bi to rešili, da bi zagotovili boljši način, kar natančno počne, je dejansko sprejeti sledilno transakcijo končnega uporabnika, zajame metapodatke o njej, sledi transakciji po omrežju, v spletni strežnik, v stopnjo poslovne logike in podpiramo .NET in ABAP ter PeopleCode in E-Business Suite, v večdimenzionalnih aplikacijah, da bodo končno vse transakcije povezane s sistemom snemanja. Ne glede na to, ali gre za iskanje zalog, čas opravljenega poročanja, vedno komunicirajo z bazo podatkov. Baza podatkov postane temelj uspešnosti poslovanja. Baza podatkov se zanaša na shranjevanje. Kaj odgovarjajo metapodatki o transakcijah, kdo, katera transakcija, kje v naboru aplikacij in potem imamo globoko vidnost na ravni kode, da vam pokažemo, kaj se izvaja. Te informacije se zajemajo nenehno in jih dajo v bazo podatkov o upravljanju uspešnosti - kar postane en sam glasbeni list, da lahko vsi vidijo, kaj se dogaja. Obstajajo različni ljudje in organizacije, ki jim je mar za dogajanje: tehnični strokovnjaki, lastniki aplikacij, navsezadnje tudi sam posel. Ko se pojavi težava, želite pridobiti podatke o tej transakciji.
Preden pogledamo naložbeno transakcijo, vam želim pokazati, kako se to lahko zdi različnim ljudem v organizaciji. Na ravni upravljanja boste morda želeli imeti pregled več aplikacij. Morda boste želeli vedeti o zdravju, ki se izračuna na podlagi skladnosti in razpoložljivosti SLA. To zdravje ne pomeni, da je vse, kar 100% deluje brezhibno. V tem primeru je nekaj prostora, za katerega vidite, da je naložbena transakcija v opozorilnem stanju. Zdaj, nekoliko globlje, morda v svoji panogi želite imeti nekaj dodatnih podrobnosti o posameznih transakcijah, ko kršijo SLA-je, šteje transakcije itd. Operativna skupina bo želela o tem obvestiti opozorilo nekaterih razvrsti. Vgrajena so opozorila o uspešnosti. Dejansko merimo uspešnost v brskalniku končnega uporabnika. Ne glede na to, ali ga lahko odkrijemo Internet Explorer, Chrome, Firefox itd., To odgovarja na prvo vprašanje: ali ima končni uporabnik težave?
Potopimo se in poglejmo, kaj še lahko pokažemo o tem. Ljudje, ki jih zanima izvedba, bi odprli Natančno. Ocenili bi transakcije. Pregledali bi stolpec SLA, da bi ugotovili transakcije, ki niso skladne s SLA. Videli bodo lahko končne uporabnike, ki so bili prizadeti, pa tudi, kaj je ta transakcija storila, ko je tekla po aplikaciji. Način, kako razvozlati te hieroglife, je to brskalnik, URL, U je za URL, to je vstopna točka v JVM. Zdaj ta poseben JVM pokliče spletni strežnik k drugemu JVM, ki nato izvede stavek SQL. To je očitno težava z bazo podatkov, ker je ta izjava SQL predstavljala 72 odstotkov odzivnega časa. Osredotočeni smo na čas. Čas je valuta uspešnosti. Tako končni uporabniki doživljajo, ali se stvari počasi izvajajo ali ne, in to je merilo porabe virov. Zelo je priročen; gre za eno samo meritev, ki je najpomembnejša za oceno uspešnosti. Ko se ta težava izroči DBA, ne gre samo za bazo podatkov, temveč je ta stavek SQL. To je kontekst, o katerem sem govoril.
Zdaj sem oborožen s temi informacijami in lahko analiziram, kaj se je zgodilo. Najprej vidim, y-os je čez dan. Oprostite, os y je odzivni čas, os x je čas čez dan. Vidim, da obstaja težava z bazo podatkov, obstajata dva dogodka, vrnite se k temu toku, poberite to izjavo SQL in pojdite v strokovni pogled, kjer vam Natančno lahko pokaže, kaj se dogaja, njene kontrole, koliko časa traja ta koda izvršiti. V ravni baze podatkov je izvedbeni načrt. Opozorili boste, da je Precision izbral resnični načrt izvrševanja, ki je bil uporabljen v času izvedbe, in se razlikuje od predvidenega načrta, ki bi bil, ko bi bil načrt dan in ne v času izvajanja. Morda ne odraža, da je baza podatkov dejansko storila.
Zdaj tukaj je analiza odzivnega časa za stavek SQL. Devetdeset odstotkov porabljenega časa za skladiščenje; deset odstotkov je bilo uporabljenih v CPU-ju. Vidim besedilo izjave SQL in poročilo o ugotovitvah. Besedilo stavka SQL dejansko začne razkrivati nekatere težave s kodiranjem. Je izbrana zvezda; ki vrne vse vrstice - oprostite, vsi stolpci iz vrnjenih vrstic. Vračamo nazaj dodatne stolpce, ki jih aplikacija ali morda ne potrebuje. Ti stolpci porabijo prostor in vire za obdelavo. Če zaženete SAP, je ena od velikih sprememb, ker je baza podatkov HANA stolpčna, ta, da v bistvu prepisujejo SAP, da ne izberejo izbrane zvezde, zato lahko močno zmanjšajo porabo virov. To je v bistvu nekaj, kar se dogaja veliko časa tudi v domačih aplikacijah, najsi bo to Java, .NET itd.
Na tem zaslonu se prikaže kdo, kaj, kdaj, kje in zakaj. Zakaj pride do, kot sta izjava SQL in izvedbeni načrt, ki vam omogoča reševanje težav. Ker Natančno teče neprekinjeno, lahko dejansko izmerite pred in po tem, na ravni stavkov SQL, na ravni transakcij, tako da lahko bodisi merite tako zase kot tudi prek lastnikov aplikacij in za upravljanje, da ste rešili težavo . Ta dokumentacija je zelo koristna. V tem paketu aplikacij je veliko zapletenosti. Od mnogih aplikacij pravzaprav vsi, s katerimi smo se pogovarjali, izvajajo vsaj del skladov aplikacij pod VMware. V tem primeru gledajo v aplikacijo za storitve za stranke, gledajo na čas transakcije in to povezujejo z upočasnitvijo, je dogodek virtualizacije. Natančno spremljate vse dogodke virtualizacije. Za vnos tega centra imamo vtičnik vCenter.
Prav tako lahko zaznamo prepir. Prepir je drugačen kot izkoriščenost. Pravzaprav prikaže, kdaj morda hrupni sosed vpliva na VM gosta, v povezavi z aplikacijo strežnika za stranke. Zdaj lahko preverim in dobim informacije in dejansko vidim dva VM-ja, ki se potegujeta za vire CPU-ja. To mi omogoča vidljivost, tako da si lahko ogledam načrtovanje. Gosta VM lahko postavim na drug fizični strežnik. Vse te vrste stvari, na katere se lahko odzovete, lahko poleg tega dejansko pogledam na učinkovitost kode, da bi morda uporabil manj CPU-ja. Mislim, da imam v tej predstavitvi precej dober primer, kako je nekomu uspelo zmanjšati porabo CPE-jev za naročila velikosti.
To je bil VMware. Pojdimo v samo kodo, kodo aplikacije. Natančno vam bo lahko pokazal, kaj se dogaja znotraj Jave, .NET, kode ABAP, E-Business, PeopleCode itd. To so vstopne točke v tem primeru v WebLogic. Spodaj je poročilo o ugotovitvah, ki mi pravi, da morate pogledati te EJB, in povedal mi je, da se tudi v tem sistemu dogaja zaklepanje. Še enkrat, natančnejši opis stopnje poslovne logike, da pokažemo, kaj se dogaja. V tem primeru si ogledam posebne primere; Podpiram tudi grozdenje. Če imate na voljo številne JVM-je, si lahko ogledate skupino kot celoto ali si ogledate ozka grla znotraj posameznega JVM-ja.
Ko zaidete v zaklepanje, lahko sodim v izjeme. Izjema je nekoliko drugačna kot težava z zmogljivostmi. Običajno se izjeme izvajajo zelo hitro. Ker pride do logične napake in ko enkrat pritisnete na to logično napako, se ta konča. Uspeli smo ujeti sled skladnosti na vrhuncu izjeme, to bi lahko prihranilo veliko časa, saj gre skozi poskuse, da ugotovimo, kaj se dogaja, samo sled steka imate tam. Prav tako lahko zajamemo puščanje spomina. Rešitev vključuje tudi stopnjo baze podatkov, lahko grem, lahko ocenim primerek baze podatkov. Še enkrat, y-os je tam, kjer je bil porabljen čas, x-os je čas čez dan. Obstaja poročilo o ugotovitvah, ki mi samodejno pove, kaj se dogaja v sistemu in kaj lahko pogledam.
Ena od stvari v poročilu o ugotovitvah družbe Precision je, da ne gleda le dnevnikov ali stanja čakanja - pregleduje se vsa stanja izvajanja, vključno s CPU-jem, in vrnitev informacij iz pomnilnika. Shranjevanje je zelo pomemben del nabora aplikacij, zlasti s pojavom trdnega stanja. Informacije v teh vrsticah so lahko zelo koristne. Pri nekaterih enotah za shranjevanje lahko dejansko sprostimo in pokažemo, kaj se dogaja na ravni posamezne naprave. Ta vrsta informacij - še enkrat, globoka vidljivost; je širok po obsegu - da vam bo na voljo samo dovolj informacij, da boste kot strokovnjak za uspešnost aplikacij imeli več vzrokov, s katerimi lahko svoje aplikacije optimizirate od konca do konca, da izpolnite te poslovne transakcije.
Imam nekaj študij primerov, ki bi jih želela deliti z vami. Križarimo precej hitro; Upam, da grem v redu. Ko govorimo o shrambi, vsi sčasoma spreminjajo strojno opremo. Obstaja garancija za strojno opremo. Ali je res prineslo to, kar vam je povedal prodajalec? To lahko ocenite s točnim. Vstopite, in kaj se je zgodilo tukaj, so v bistvu postavili novo shranjevalno enoto, ko pa so skrbniki pomnilnika pogledali samo na ravni enote, so videli veliko prepirov in mislili so, da bi lahko prišlo do težave s to novo shranjevalno enoto . Če pogledamo več z vidika od konca do konca, natančno zato, da pokažemo, kje bi se to dejansko zgodilo. Dejansko so šli s hitrostjo približno 400 meg na sekundo, kjer je bilo za shranjevanje odgovornih 38 odstotkov odzivnega časa, tako da je precej veliko. Z novo shranjevalno enoto smo dejansko prešli do šest, sedemsto megsov na sekundo, kar je v bistvu dvojno in prispevek stopnje pomnilnika k času transakcij lahko zmanjšamo na polovico. To lahko prej izluščim, to je obdobje preseka in nato pozneje.
Torej, še enkrat, dokumentacijo, s katero bi dokazali, da je bila naložba v strojno opremo vredna in so jo posredovali tako, kot je pričakoval ta prodajalec. Obstaja vse, saj se zaradi zapletenosti, števila stvari lahko zgodi vse vrste. V tem primeru so imeli v resnici situacijo, ko so vsi nekako krivili DBA, DBA je bil takšen, "no, ne tako hiter." Tukaj pravzaprav gledamo aplikacijo SAP, mislim, da je takšen scenarij precej pogost . Zgodilo se je, da so razvijali transakcijo po meri za uporabnika. Uporabnik je kot: "To je tako počasno." Kodir ABAP - to je programski jezik v SAP -, je dejal: "To je težava z bazo podatkov." Na koncu so se odprli Precision; tega končnega uporabnika so izmerili 60 sekund, torej dobro minuto. Petindvajset sekund je bilo porabljenih v zadnjem delu. Vrtali so se v zadnji del in dejansko so lahko razkrili izjavo SQL, predstavljeno v padajočem vrstnem redu.
Ta zgornja izjava SQL, ki je odgovorna za 25 odstotkov porabe virov, njen povprečni čas izvedbe je dve milisekundi. Nekako ne morete kriviti baze podatkov. Veste, hej, ne tako hitro, fant. Vprašanje je, zakaj je toliko usmrtitev? No, vrnili so ga nazaj v ABAP, on je vstopil, pogledal v gnezdenje zanke, ugotovil, da kličejo bazo podatkov na napačnem mestu, v bistvu so naredili spremembo, preizkusili spremembo in zdaj je nov odzivni čas pet sekund. Nekoliko počasi, vendar bi s tem lahko živeli. Daleč bolje kot 60 sekund. Včasih, samo odkritje, ali je to koda aplikacije, ali je to baza podatkov, ali je shranjevanje? Natančno je to področje, kjer družba Precision ima kontekst transakcij od konca do konca, kjer se igra Precision. Te stvari v bistvu končaš.
Gledam na čas, izgleda, da imamo še nekaj časa, da preidemo še nekaj teh. Skozi te pretakam. Ta aplikacija je bila v pripravi več kot leto dni. When they went into QA, they were seeing that the web servers were maxed out 100 percent and it looked like the application couldn't run under VMware. The first thing everybody said was, “Put this on physical; it can't run under VMware.” Precise actually offered them additional ways to solve the problem. We looked at the transactions, we saw a web server call, it comes in as an ASMX in IIS.NET. It actually revealed the underlying code. You see this where I'm pointing? This is 23 days, 11 hours. Wow, how is that possible? Well each invocation takes 9.4 seconds and this thing is invoked 215, 000 times. For every invocation, it uses 6 seconds of CPU. This is the reason, this code is the reason why this thing could never scale. In fact, it couldn't scale in physical.
What they did, is they went back to their developers and they said, “Can somebody make a change?” They kind of had a contest, and they tested out the different suggestions and they came up with a suggestion that was able to run much more efficiently. The new one completed one point, a little less than two seconds, with two-hundredths of a second in CPU. Now this could scale and it could run on the VMware farm. We were able to basically document that at both the code level as well as the transaction level. This is kind of the before, and then the after. Now that you can see here in the stack bar graph that shows web, .NET and database, now you're interacting with the database. This is a profile you would expect to see for an application that was running more normally.
All right, I'm picking and choosing in terms of additional things I can show you. A lot of people like this because this bedazzles many shops. If you're unable to meet a business SLA, and everybody is like, “Help us out.” This shop had a situation where the business SLA is in orders received by 3 pm, it's shipped that day. Is really vital that they get the orders out, and the warehouse is very busy. This JD Edwards' sales order screen, was freezing and you can get a very good idea that this is a just-in-time retail inventory management system. Empty shelves are unacceptable in retail. Got to have the merchandise there in order to sell it. What we did is we dived in, in this case, we're looking at the SQL server database. The look and feel is the same whether it's SQL, Oracle, DB2 or Sybase.
We identified the select from PS_PROD and we're able to capture the duration, the fact they execute so much. The dark blue matched the key that said they're not waiting on some wait state or some logging or even storage – this thing is bound by CPU. We tracked the SQL statement by 34301 so every time this is executed, we increment our counters to keep track of it. That means that we have a detailed history and I can access it by clicking that tune button. Here's the history tab. This screen here shows average duration versus changes. Wednesday, Thursday, Friday, the average duration was about two-tenths of a second. Very few screen freezes, they're able to meet the business SLA. Come February 27th, something changes and all of the sudden, execution time is up here, and that's actually slow enough to cause timeouts, which result in screen freezes. Precise, by keeping a detailed history, including the execution plan and general changes to the table's indexes if that SQL is in use. We were able to pick up that the access plan changed on February 27th. Monday through Friday's bad week. Come March 5th, the access plan changed again. This is a good week. This pink star tells us the volume updated.
Tu lahko vidite, da število vrstic v osnovnih tabelah raste in to je značilno za podjetje. Želite, da vaše mize rastejo. Stvar je v tem, da so stavki razčlenjeni, pridejo izjave SQL, optimizator se mora odločiti, kaj storiti in izbrati, ko je načrt izvedbe hiter, izbrati drug izvedbeni načrt, ko je počasen, kar povzroči zamrznitev zaslona. Na globoki tehnološki osnovi moram vedeti, kakšen je načrt izvedbe, in natančno ga zajemam skupaj z datumom in časovnim žigom. Ta je bil hiter in učinkovit, to je bil počasen in neučinkovit. Ta združitev filtrov za uskladitev za to konkretno izjavo SQL porabi veliko več CPU-ja. Še vedno imajo enak končni učinek, vendar ima ta v bistvu počasnejši in manj učinkovit recept za zagotavljanje rezultatov. Torej, stopimo skozi. Hej, imamo čas še za par?
Eric Kavanagh: Ja, pojdi.
Bill Ellis: V redu, preskočil bom naprej. Želim si, da se seznanite, govorili smo o strojni opremi, govorili smo o SAP, govorili smo o .NET, govorili smo o JD Edwards in okolju Java-SQL Server. To je SAP, tukaj gledamo PeopleSoft. Precizna podporna matrica je široka in globoka. Če imate aplikacijo, je več kot verjetno, da jo lahko instrumentiramo za zagotavljanje te stopnje vidnosti. Ena največjih sprememb, ki se trenutno dogaja, je mobilnost. PeopleSoft je predstavil mobilnost s svojim uporabniškim vmesnikom Fluid. Uporabniški vmesnik Fluid uporablja sistem zelo drugače. Ta aplikacija se razvija. Uporabniški vmesnik Fluid - s stališča upravljanja omogoča končnim uporabnikom uporabo telefona in močno poveča produktivnost. Če imate na stotine ali tisoče ali celo več zaposlenih, če lahko povečate njihovo produktivnost, za 1-2 odstotka, lahko močno vplivate na plače in vse ostalo. Zgodilo se je, ta trgovina je razvila uporabniški vmesnik PeopleSoft Fluid. Zdaj, ko govorimo o zahtevnosti, to je skupina PeopleSoft. Ena aplikacija, najmanj šest tehnologij, številni končni uporabniki. Kako jo začnete?
Še enkrat natančno bo lahko sledil tem transakcijam. Tukaj prikazujemo zložen črtni graf, ki prikazuje odjemalca, spletni strežnik, Java, bazo podatkov Tuxedo, paket aplikacij PeopleSoft. Zeleni zemljevidi J2EE, kar je nekako domišljav način, kako povedati WebLogic. To je presek. Končni uporabniki začnejo uporabljati uporabniški vmesnik Fluid, odzivni čas pa traja od ene in pol do dveh sekund do približno devet, deset sekund. Na tem enem zaslonu se ne vidi število ljudi, ki se "ne odzivajo". V aplikaciji dejansko zaslonijo zaslon. Oglejmo si nekaj prepoznavnosti, ki jo Precision lahko zagotavlja tej stranki.
Najprej, ko pogledam transakcije PeopleSoft, lahko v bistvu vidijo, da smo to vrsto stvari videli po vsem svetu. Vplivale so vse transakcije, pa tudi vse lokacije. Mimogrede, ko to pogledate, lahko dejansko vidite lokacije po vsem svetu. Od Azijsko Tihega oceana, Evrope in Severne Amerike. Problem z uspešnostjo ni bil lociran v določeni transakciji ali določeni geografski lokaciji, temveč v celotnem sistemu. Nekako bi rekli, da je sprememba ali način, kako je vplival uporabniški vmesnik Fluid, vplival globalno. Tu lahko vidite z vidika skalabilnosti, ljudje poskušajo izvesti enako vrsto obsega dejavnosti, vendar je odzivni čas v bistvu samo degradiran in degradiran. Vidite, da se stvari ne spreminjajo. Stvari gredo zelo, zelo slabo. Tu, ko pogledam število osi in sočasne povezave, vidite nekaj, kar je zelo zanimivo glede števila dostopov in povezav. Tu smo le približno do 5000 in gledamo na to, kar je več kot 100 sočasnih povezav. To se naredi po; to je prej. Kakšna je moja resnična zahteva po sistemu, če bi ta stvar lahko obsegala, je v območju 300.000. V starih časih si s klasičnim uporabniškim vmesnikom ogledujete 30 sočasnih povezav.
Zdaj vam to pove, da uporabniški vmesnik Fluid uporablja vsaj 10x število sočasnih povezav. Z PeopleSoftom začnemo vleči nazaj, kaj se dogaja pod platnicami, da boste lahko začeli opažati vpliv na spletnih strežnikih, dejstvo, da se SLA začnejo kršiti. Ne bomo se spuščali v vse, toda na koncu se zgodi, da se v bistvu zanašajo na sporočila. V bistvu telovadba je WebLogic in povzroča čakalne vrste znotraj Tuxeda. V resnici je obstajala težava glede odvisnosti od več ravni, ki se je pokazala z uporabniškim vmesnikom Fluid, vendar je Precision lahko pokazal, da se lahko s kopico različnih stvari osredotočimo na to, kaj je težava. Izkazalo se je, da je bila težava tudi v sami bazi podatkov. Datoteka dnevnika za sporočila dejansko obstaja in zaradi vseh sočasnih uporabnikov se je ta datoteka zaklenila. V bistvu je bilo treba stvari prilagoditi v vsaki stopnji znotraj nabora aplikacij. Pogovorite se o zapletenosti, tukaj je pravzaprav stopnja Tuxedo, ki prikazuje čakalne vrste in lahko vidite tudi uspešnost, ki upada tudi znotraj te stopnje. Videl sem procese; Lahko bi videl domene in strežnike. V Tuxedu za ljudi, ki to uporabljajo, običajno odprete dodatne čakalne vrste, domene in strežnike, tako kot v supermarketu za lajšanje preobremenjenosti, da zmanjšate čas čakanja. Zadnja in zadnja možnost, Natančno prikazuje veliko informacij.
Kot sem že omenil, vsaka pomembna transakcija vpliva na sistem evidenc. Vidnost v bazi je najpomembnejša. Natančno prikazuje, kaj se dogaja v bazi podatkov, v programu WebLogic, znotraj Jave, .NET, v brskalniku, toda kraj, ki ga Precision resnično izstopa, je v ravni baze podatkov. To je šibkost naših konkurentov. Dovolite, da vam pokažem enega od načinov, kako vam bo Precis lahko pomagal pri tem. Ne bom porabljal časa za trikotnik optimizacije podatkovnih baz, ampak v bistvu gledamo na nizkocenovne, nizko-tvegane, široko-obsežne, visoko tvegane in visoko-stroškovne spremembe. Potem bom dejansko pospravil ta diapozitiv, če bodo ljudje želeli poskusiti in si ga ogledati. Mislim, da gre za precej velik vodnik za težave s uglaševanjem. Tukaj je mnenje Natančno za Oracle. Na vrhu poročila o ugotovitvah, 60-odstoten vpliv ima ta posebna izjava SQL. Če odprete ta zaslon dejavnosti, ga pokaže tam zgoraj. Lahko pogledam to izbrano izjavo, obstaja en načrt izvršitve. Vsaka izvedba traja sekundo - 48.000 usmrtitev. To pomeni še do 48.000 usmrtitev.
Temno modra je spet CPU. Ta stvar je vezana na CPU, ne na stanje čakanja in ne na dnevnik. Poudarjam, da ker nekateri naši konkurenti gledajo samo na stanje čakanja in beleženje dogodkov, na splošno pa je CPU najbolj zasedeno stanje izvajanja in ponuja največ odkupov. Ko zaidem v ta strokovni pogled - in grem zelo hitro - kar sem storil, sem pogledal mizo, 100.000 vrstic, 37.000 blokov. Delamo s polno tabelo, vendar imamo šest indeksov o tej stvari. Kaj se tukaj dogaja? No, ko pogledam klavzulo kje, to, kje dela klavzula, je to, da dejansko pretvori stolpec v velike črke in pove, kje je enako velikemu velikanu, poišči spremenljivko. Dogaja se, ko mora Oracle vsakič, ko se ta stvar izvrši, pretvoriti ta stolpec v velike črke. Namesto da bi to storili skoraj petdeset tisoč krat, je veliko bolj učinkovito zgraditi ta indeks v velikih črkah funkcijskega indeksa in je na voljo ne samo v oddelku podjetja Oracle, temveč tudi v standardni razdelitvi. Ko to storite, potem lahko preverite izvedbeni načrt, ki izda tistemu novemu uporabniku indeksa perm velika črka, to je bila le nekakšna moja stvar.
Potem, ko merite pred in po, si ogledate ensekundni čas izvedbe, združi do 9 ur 54 minut, z isto natančno izjavo SQL, vendar ima ta indeks vgrajen v velike črke za 58.000 izvedb, odgovor čas pade na podmilosekunde, seštejemo skupaj, pride do sedmih sekund. Na svojem strežniku sem v bistvu prihranil deset ur CPU-ja. To je ogromno. Ker če mi ne bo treba za osvežitev strežnika, bom lahko živel na tem strežniku. Dejansko znižam porabo strežnika za 20 odstotkov in dejansko lahko vidite prej in po tem. To je vrsta vidnosti, ki jo lahko zagotavlja Precision. Mogoče bi bilo videti še nekaj dodatnih stvari, zakaj imate vse te indekse, če se ne uporabljajo? S tem lahko sledijo. Obstaja arhitektura in jaz jo bom zavil, saj dosežemo vrh ure. Resničen verjamem v to rešitev in želimo, da ste pravi vernik. V podjetju IDERA verjamemo, da preizkus naredi kupca, zato če smo zainteresirani, lahko opravimo ocene na vašem spletnem mestu.
S tem bom poslal svetilnik nazaj.
Eric Kavanagh: Ja, to je bila ogromna podrobnost, ki ste jo pokazali tam. Res je zelo fascinantno. Mislim, da sem vam v preteklosti že omenil, da - in to vem v nekaterih drugih spletnih oddajah, ki smo jih opravili z IDERA, sem to že omenil - pravzaprav sledim Natančno, odkar jo je IDERA pridobila, vse do leta 2008, mislim, ali leta 2009. Takrat me je očaralo. Zanimivo me je vedeti, koliko dela je treba ostati pri vrhunskih izdajah aplikacij. Omenili ste, da je SAP HANA, ki se mi zdi zelo impresiven, da se lahko dejansko kopate v arhitekturi HANA in tam odpravite nekaj težav. Koliko ljudi imate? Koliko truda je s vaše strani in koliko tega lahko naredite nekoliko dinamično, kar pomeni, da ko orodje zaženete, začnete plaziti okoli in videti različne stvari? Koliko tega lahko orodje dinamično, nekako ugotovi, tako da lahko pomagate ljudem pri odpravljanju zapletenih okolij?
Bill Ellis: Tam ste postavili veliko vprašanj.
Eric Kavanagh: Vem, oprosti.
Bill Ellis: Predložil sem veliko podrobnosti, ker je pri teh aplikacijah, če pogledamo kodo, hudič v podrobnostih. To raven podrobnosti moraš imeti, da boš res lahko imel nekaj dejanskega. Brez uporabnih meritev preprosto veste o simptomih. Pravzaprav ne rešuješ težav. IDERA govori o reševanju težav. Velik izziv je ostati na vrhu novih izdaj in drugih stvari. Vprašanje, kaj je potrebno za to, je res za upravljanje izdelkov. Nimam veliko prepoznavnosti v ekipi, ki nas v bistvu sproti obvešča o stvareh. Kar zadeva HANA, je to pravzaprav nov dodatek k liniji izdelkov IDERA; je zelo razburljivo. Ena od stvari s HANO je - naj se pogovorim o nalogi še sekundo. V nalogi bi trgovine SAP naredile, da bodo kopirale bazo podatkov za namene poročanja. Potem bi morali ljudi sprijazniti s tistim, kar je dejansko trenutno. Imeli bi te različne podatkovne baze, ki bi jih na različnih ravneh ne sinhronizirali. Potrebno je le veliko časa in truda, poleg strojne opreme, programske opreme in ljudi za vzdrževanje vsega tega.
Ideja družbe HANA, da bi imela visoko vzporedno bazo podatkov v pomnilniku, bi se v bistvu izognila potrebi po podvojenih bazah podatkov. Imamo eno bazo podatkov, en vir resnice, vedno je posodobljen, tako se izognete potrebnim, da bi dosegli to spravo. Pomembnost uspešnosti baze podatkov HANA narašča - rekel bom 10x ali vsaj bolj dragocen od vsote vseh drugih baz podatkov, strojne opreme in virov, ki jih lahko kupimo. Ker je HANA sposobna upravljati, zdaj je ta komponenta trenutno v beta testiranju, to bo kmalu začelo. Tako je za IDERA in za nas precej navdušujoče, da podpiramo SAP platformo. Nisem prepričan, katere druge dele vašega vprašanja sem nekako spremenil, vendar -
Eric Kavanagh: Ne, tukaj so vse dobre stvari. Naenkrat sem vam vrgel cel kup, tako mi je žal. Prav očaran sem, res, mislim, da to ni zelo preprosta aplikacija, kajne? Kopljete globoko v ta orodja in razumete, kako medsebojno komunicirajo in po vašem mnenju morate zgodbo nekako sestaviti v svoji glavi. Če želite razumeti, kaj se dejansko dogaja in kaj vam povzroča težave, morate kombinirati koščke informacij, da lahko vstopite tja in rešite te težave.
En udeleženec se sprašuje, kako težko je izvajati Natančno? Druga oseba se je vprašala, kdo so ljudje - očitno DBA -, ampak kdo so v organizaciji še kakšne vloge, ki bi uporabljale to orodje?
Bill Ellis: Natančnost je nekoliko bolj zapletena. Morate imeti nekaj znanja o aplikacijskem okolju, kar zadeva, saj veste, ta aplikacija deluje na tej bazi podatkov, potrebuje ali - spletne strežnike srednjega nivoja itd. Mislim, da je glede na zapletenost nekaterih teh aplikacij, je pravzaprav razmeroma enostavno. Če lahko spletni strežnik povežem z vašo bazo podatkov, lahko to storim od konca do konca. Opažate, da nisem ničesar povedal o opremljanju odjemalca za končnega uporabnika in zato to, kar počnemo, dejansko vključimo dinamično, zato vam ni treba spremeniti svoje kode ali česar koli drugega. JavaScript gre v okvir strani aplikacije. Ne glede na to, kje je uporabnik na svetu, ko do svojega URL-ja dostopajo do URL-ja in snamejo to stran, je to orodje Natančno. To nam omogoča, da v brskalniku končnega uporabnika izberemo ID uporabnika, njihov IP naslov in tudi prvi bajtovski čas upodabljanja vsakega od strani izvajanja skripta komponent strani.
Glede transakcij vam ni treba preslikavati transakcij, ker so tesno povezane. Ta URL postane vstopna točka v JVM in nato sproži to sporočilo, zaradi česar je JVC ujet iz baze podatkov. V bistvu lahko ujamemo te naravne točke povezave in vam jih nato predstavimo na tem transakcijskem zaslonu, kjer sem vam pokazal, kje smo izračunali tudi koliko časa ali odstotek časa, porabljenega v posameznem koraku. Vse to se naredi samodejno. Na splošno si namenimo 90 minut, da v bistvu namestimo Precision jedro in nato začnemo izvajati aplikacijo. Glede na znanje o aplikaciji nam lahko traja nekaj dodatnih sej, da bomo lahko celotno aplikacijo opremili. Mnogi ljudje uporabljajo samo komponento baze podatkov Natančno. To je vredu. To lahko v bistvu razbijete in razdelite na komponente, za katere menite, da vaše spletno mesto potrebuje. Vsekakor verjamemo, da je kontekst opremljenosti celotnega niza aplikacij instrumentiran, tako da lahko vidite, da odvisnost od stopnje do stopnje dejansko poveča vrednost spremljanja posamezne stopnje. Če bo kdo želel še naprej raziskati zbirko svojih orodij, pojdite na našo spletno stran. Mislim, da je to najlažji način za dodatne informacije, o čemer bomo razpravljali še malo.
Eric Kavanagh: Naj vam postavim eno ali dve hitri vprašanji. Predvidevam, da sčasoma zbirate in gradite repozitorij interakcij med različnimi aplikacijami in različnimi zbirkami podatkov za posamezne stranke in kot korporativni subjekt na splošno. Z drugimi besedami, mislim, da nameravam načrtovati scenarije. Je to tako? Ali dejansko vzdržujete nekakšno shrambo običajnih scenarijev, da lahko dajete predloge končnim uporabnikom, ko se nekatere stvari začnejo igrati? Kot ta različica E-Business Suite, ta različica te baze itd. - to počnete veliko?
Bill Ellis: No, ta vrsta informacij je vgrajena v poročilo o ugotovitvah. Poročilo o ugotovitvah pravi, katera so ozka grla pri uspešnosti, in temelji na času izvedbe. Del tega poročila o ugotovitvah je izvedeti več in kaj narediti naprej. Informacije ali izkušnje strank in podobno so v osnovi vključene v to knjižnico priporočil.
Eric Kavanagh: V redu, zveni dobro. Pa ljudje, fantastična predstavitev danes. Bill, všeč mi je bilo, koliko podrobnosti si imel tam. Samo mislil sem, da so to res fantastične, krušne, natančne informacije, ki prikazujejo, kako vse to počnejo. V določenem trenutku je skoraj kot črna magija, ampak res ni. To je zelo specifična tehnologija, ki jo dobite skupaj za razumevanje zelo, zelo zapletenih okolij in osrečuje ljudi, saj nihče ne mara, ko aplikacije tečejo počasi.
No, ljudje, arhivirali bomo to spletno oddajo. Lahko skočite po spletu na Techopedia ali insideanalysis.com in wow, hvala za vaš čas, vas bomo naslednjič dohiteli. Pazite, zbogom.
