Tekijä Techopedia Staff, 2. marraskuuta 2016
Takeaway: Isäntä Eric Kavanagh keskustelee sovellusten suorituskyvystä ja kuinka parantaa tehokkuutta tohtori Robin Bloorin, Dez Blanchfieldin ja IDERAn Bill Ellisin kanssa.
Et ole tällä hetkellä kirjautunut sisään. Kirjaudu sisään tai kirjaudu sisään nähdäksesi videon.
Eric Kavanagh: Hyvät naiset ja herrat, hei ja tervetuloa jälleen kerran Hot Technologiesiin. Todellakin! Nimeni on Eric Kavanagh, tulen tänään isäntänä toiselle webcast-lähetykselle tässä todella hauskassa, jännittävässä sarjassa, jonka olemme saaneet kohteliaisuutena Briefing Room -sarjallemme. Otsikko on ”Sovelluskiihdytys: nopeampi suorituskyky loppukäyttäjille”. Tulkaa ihmiset, kuka ei halua sitä? Jos olen kaveri, joka auttaa sovellustasi toimimaan nopeammin, ajattelen, että kaveri hankkii minulle oluita baareista työn jälkeen. Sen on oltava aika siisti asia kävellä sisään ja nopeuttaa kenen tahansa sovellusta.
Siellä on dia sinun oikeasta, lyö minut Twitteriin @Eric_Kavanagh. Yritän aina seurata ja twiitin aina uudelleen, jos mainitset minut, joten mainitse rohkeasti minua.
Koko tämän näyttelyn tarkoitus on keskittyä yritysteknologian eri näkökohtiin ja auttaa todella määrittelemään tietyt tieteenalat tai tietyt kasvot, jos haluat. Monta kertaa myyjät hakevat tiettyjä markkinointiehtoja ja puhuvat kuinka he tekevät tämän tai toisen tai muun asian. Tämä esitys oli todella suunniteltu auttamaan yleisöämme ymmärtämään, mitä ohjelmistotyökalulla on oltava ollakseen johtava tilaansa. Tämä on kaksi analyytikkoa. Jokainen menee ensin, toisin kuin tiedotustila, jossa myyjä menee ensin. Jokainen antaa omaksua sen, mikä heidän mielestään on tärkeää sinun tietää tietyn tyyppisestä tekniikasta.
Tänään puhumme sovelluksen kiihdyttämisestä. Kuulemme Dez Blanchfieldiltä ja myös tohtori Robin Bloorilta - olemme tänään ympäri maailmaa - ja sitten Bill Ellis soittaa sisään suuremmalta Virginian alueelta. Aion luovuttaa sen ensimmäiselle esittelijällemme, tohtori Bloorille. Olemme tweettivät #podcastin hashtagin muuten, joten voit tweettiä. Ota se pois.
Dr. Robin Bloor: Okei, kiitos johdannosta. Sovellusten suorituskyky ja palvelutasot - tämä on eräänlainen alue, olen tehnyt paljon työtä tällä alueella vuosien varrella, siinä mielessä, että olen todella tehnyt hirvittävän paljon työtä suorituskyvyn seurannassa ja treenaamisessa yhdessä tavalla tai toisella, kuinka yrittää laskea nämä tasot. On sanottava, että siihen asti - meillä oli tapana olla aika sitten, aika sitten, jolloin ihmiset rakensivat järjestelmiä siiloihin. Periaatteessa niiden työn määrä, jotka heidän on tosiasiallisesti tehtävä, jotta järjestelmä toimisi kohtuullisen hyvin, jos se oli siilossa, ei oikeastaan ole kovin vaikeaa, koska muuttujia, joita joudut ottamaan huomioon, on hyvin vähän, hyvin pieni. Heti kun olemme saaneet verkkoon oikein, vuorovaikutteinen ja palvelusuuntautuminen tuli yhtälöön. Siitä tuli vähän vaikeaa. Suorituskyky voi olla yksiulotteinen. Jos ajattelee vain sovellusta, joka suorittaa tietyn koodipolun toistuvasti, sen tekeminen kohtuudella ja ajoissa tuntuu yhden ulottuvuudelta. Heti kun aloitat puhumisen palvelutasoista, puhut tosiasiassa useista asioista, jotka kilpailevat tietokoneresurssien puolesta. Siitä tulee moniulotteinen hyvin nopeasti. Jos alkaa puhua liiketoimintaprosesseista, liiketoimintaprosessit voidaan yhdistää useista sovelluksista. Jos puhut palvelukeskeisestä arkkitehtuurista, tietty sovellus voi tosiasiallisesti käyttää useiden sovellusten ominaisuuksia. Sitten siitä tulee erittäin monimutkainen asia.
Katsoin - kauan sitten piirrosin tämän kaavion. Tämä kaavio on vähintään 20 vuotta vanha. Periaatteessa kutsun sitä kaikesta kaaviona, koska se on tapa tarkastella kaikkea, mitä IT-ympäristössä on. Se on oikeastaan vain neljä kappaletta: käyttäjät, data, ohjelmistot ja laitteistot. Tietenkin ne muuttuvat ajan myötä, mutta todella ymmärrät tätä tarkastellessasi, että jokaisella näistä kappaleista on hierarkkinen räjähdys. Laitteisto kyllä, laitteisto voi olla palvelin, mutta palvelin koostuu mahdollisesti useista prosessoreista, verkkotekniikasta ja muistista, ja tämä on sellainen hirvittävä joukko ohjaimia, kuten se tapahtuu. Jos tarkastellaan tätä, se kaikki hajoaa paloiksi. Jos todella ajattelet yrittää organisoida kaikki tämä muuttuvien tietojen suhteen, ohjelmiston suorituskyky muuttuu, koska laitteisto muuttuu, ja niin edelleen ja niin edelleen, katsot itse asiassa uskomattoman vaikeaa monimuotoista tilannetta. Tämä on monimutkaisuuskäyrä. Tietenkin se on monimutkaisuuskäyrä melkein kaikelle, mutta olen nähnyt sen vetävän uudestaan ja uudestaan puhuttaessa tietokoneista. Periaatteessa, jos laitat solmut yhdelle akselille ja tärkeät liitokset toiselle akselille, lopputuloksena on monimutkaisuuskäyrä. Sillä ei melkein ole merkitystä, mitkä solmut ja yhteydet ovat, ja mitä tehdään, jos haluat edustaa puhelinverkon äänenvoimakkuuden kasvua.
Itse asiassa puhuttaessa tietokoneympäristön solmuista puhut yksittäisistä asioista, jotka välittävät toisistaan. Monimutkaisuus, se osoittautuu, kysymys lajikkeen rakenteesta ja erilaisista rajoituksista, joita yrität noudattaa. Myös numerot. Kun numerot nousevat, ne hulluiksi. Minulla oli eilen mielenkiintoinen keskustelu, puhuin jonkun kanssa - en voi mainita kuka hän oli, mutta sillä ei ole väliä - he puhuivat sivustosta, jolla oli 40 000 - eli neljä nollaa, 40 000 - tietokanta-esiintymää. sivustolla. Ajattele vain sitä - 40 000 erilaista tietokantaa. Tietenkin ainoa asia, joka meillä oli - heillä oli tietysti monia, tuhansia sovelluksia. Puhumme erittäin suuresta organisaatiosta, mutta en voi nimetä sitä. Katsot itse sitä ja yrität tosissaan tavalla tai toisella saada palvelutasoja, jotka ovat riittäviä kauttaaltaan joillekin monille käyttäjille, joilla on useita erilaisia, jos haluat, odotuksia. Se on monimutkainen tilanne, ja sanon vain, että nämä asiat ovat monimutkaisia. Luvut kasvavat aina. Rajoitukset määräävät liiketoimintaprosessit ja liiketoiminnan tavoitteet. Olet huomannut, että odotukset muuttuvat.
Muistan heti, kun Gmail, Yahoo ja Hotmail, kaikki nämä postijärjestelmät tulivat esiin, ihmiset alkoivat odottaa, että organisaation sisäiset postijärjestelmät ansaitsevat näiden valtavien toimintojen palvelutasot ansaitsematta laajoja palvelintiloja ulkopuolella organisaatiota, ja heitä painostettiin saattamaan kaikki sellaiset asiat tapahtumaan. Itse asiassa palvelutasosopimukset ovat yksi asia, mutta odotukset ovat toinen asia ja ne taistelevat toisiaan organisaation sisällä, hankala asia. Tässä on vain liiketoiminnan näkökulma. Joissakin järjestelmissä optimaalinen vasteaika on yksi kymmenesosa sekunneista ihmisen vasteajasta. Kymmenesosa sekunnista on aika, joka kobralla puree sinua. Jos seisotte kobran edessä ja se päättää purra sinua, on liian myöhäistä, koska et voi vastata sekunnin kymmenesosassa. Kymmenesosa sekunnista on noin aika, joka kuluu pallon kuljettamiseen syöttäjän kädestä päästäkseen kaverin kanssa mailaan. Periaatteessa, kun hän näkee pallon heitettävän, hänen on vastattava tarkalleen sinä ajankohtana. Ihmisen reaktio, eräänlainen mielenkiintoinen asia. Ohjelmisto-ohjelmisto-ohjelmisto, voi tietysti olla suurempi odotus.
Sitten joudut joihinkin tilanteisiin, jotka mielestäni ovat niitä markkinatilanteita, joissa ensisijaisuus on siellä, missä liiketoiminnan arvo on. Tämä on kuin jos haluat myydä tietyn osakekannan osakemarkkinoilla, esimerkiksi todennäköisesti vähemmän, koska luulet sen laskevan ja monet muut ihmiset ajattelevat sen laskevan, saat parhaan hinnan, jos pääset ensin markkinoille. Siellä on paljon tilanteita, mainosten näyttämistä ja vastaavia, hyvin samanlainen tilanne. Sinulla on tämä liike palvelutaso-odotusten suhteen. Sinulla on yksi asia, joka on eräänlainen lasikatto ihmisen vastaukseksi. Kun se on ohjelmisto-ohjelmisto, jos sinulla on tämä enimmäismäärätilanne, niin ei ole parasta palvelutasoa. Nopein kuin kukaan muu on paras.
Okei, tämä on mielestäni viimeinen dia, jonka tein, mutta tämä on vain antaa sinulle suuren kuvan monimutkaisuudesta, kun todella tarkastellaan organisaation vaatimuksia, palvelua. Menette vasemmalle puolelle täällä, ja sinulla on järjestelmän hallinta, joka on joukko ohjelmistoja, jotka palvelevat palvelun hallintaa ja jotka yrittävät hallita palvelutasoa. Tämän lisäksi sinulla on liiketoiminnan suorituskyvyn hallinta. Sitten, jos tarkastellaan alhaalta täältä, palvelunhallinnan automaatioaluetta, sinulla on pirstoutuneita palveluita, jotka muuttuvat standardoiduiksi palveluiksi, jos todella haluat investoida tällaiseen asiaan, joka kehittyy integroiduiksi palveluiksi, jotka kehittyvät optimoiduiksi palveluiksi . Useimmiten mitä ihmiset ovat tehneet, on vain tämän vasemmassa alakulmassa. Ehkä vähän palvelunhallintaa. Liiketoiminnan johtaminen, hyvin harvinainen. Hajanainen, melkein kaikki. Täydellinen maailma täyttäisi tuon ruudukon. Instrumentointi - Mainitsin alioptimointiongelman. Voit optimoida järjestelmän osia, eikä se ole hyötyä koko järjestelmälle. Jos teet sydämestä optimaalisen, verisi saattaa kiertää liian nopeasti muille elimillesi. Se on ongelma suurten organisaatioiden ja palvelutasojen kanssa. Ilman, että mitään ei saavuteta ilman hienostuneita työkaluja, koska muuttujat ovat juuri saaneet - muuttujia on liian paljon yritettäväksi optimoida.
Tämän jälkeen välitän Dezille, joka toivottavasti puhuu jostakin muusta kokonaan.
Dez Blanchfield: Kiitos, Robin. Kuten tohtori Robin Bloor, olen viettänyt aivan liian monta vuotta ajatellen erittäin monimutkaisten järjestelmien suorituskykyä erittäin laajassa mittakaavassa. Todennäköisesti ei aivan samassa mittakaavassa kuin Robin, mutta suorituskyky on päivittäinen aihe ja se on osa DNA: tamme, että haluamme suorituskykyä, jotta kaikesta saadaan paras mahdollinen hyöty. Itse asiassa, olen käyttänyt grafiikkaa yhdestä maailman suosikkiasioistani, Formula I -kilpailuista, jossa koko planeetta istuu vielä jonkin aikaa ja seuraa, kuinka autot kiertävät ympyröitä hyvin nopeasti. Jokaisesta näkökulmasta, kaavassa I ei ole mitään näkökohtaa, joka ei nimenomaan koske suorituskykyä. Monet ihmiset poo-poo urheilua, koska heidän mielestään se on rahan tuhlausta. On käynyt ilmi, että auto, jota ajamme joka päivä pudottaakseen lapset jalkapalloon viikonloppuisin ja kouluina muina päivinä, on johdettu suoritusperusteiseen kehitykseen ja tutkimukseen. Se on sellaista Formula I -kilpailujen elämää. Jokapäiväinen tekniikka, jokapäiväinen tiede, johtuu usein sellaisesta, joka on keskittynyt puhtaasti korkeaan suorituskykyyn.
Tosiasia on kuitenkin, että uusi "aina päällä" -maailmamme, joka vaatii sataprosenttisesti käyttöaikaa - kuten Robin aiemmin mainitsi - muun muassa ottamalla käyttöön verkkoposti ja muut palvelut, joita pidämme itsestään selvänä jatkuvassa tilassa, odotamme nyt, että yritys- ja työympäristömme. Tosiasia on, että oleminen ei aina tarkoita, että täytät palvelutasosopimuksesi. Minun on otettava huomioon tarve hallita sovellusten suorituskykyä ja saatavuuden palvelutasosopimukset ovat muuttuneet perusteellisesti viimeisen vuosikymmenen aikana. Emme yritä enää pelätä yhden järjestelmän suorituskyvystä. Kun maailma oli hieman yksinkertaisempi, saatamme joutua tilanteeseen, jossa yhtä palvelinta, jolla on useita palveluita, voidaan tarkkailla reaaliajassa ja sitä oli suhteellisen suoraviivainen tukea. Voisimme - ja tässä on minun pieni, asioita, joista olemme huolissamme, kun olin esimerkiksi järjestelmänvalvoja esimerkiksi vuosia sitten -, katsoisimme ympärilleen, onko palvelu tyypillisesti ylös ja vastaako? Voinko kirjautua esimerkiksi päätelaitteeseen? Vastaako käyttöjärjestelmä ja voinko kirjoittaa komentoja? Ovatko sovellukset käynnissä? Voinko nähdä prosesseja ja muistia tekeessäni asioita ja I / O-verkon kautta ja niin edelleen? Keskuspäivinä voit kuulla nauhoja, jotka menivät zip-zip-zip-tyyliin, ja paperia putoamasta niistä.
Vastaavatko sovellukset ja voimmeko kirjautua sisään ja tehdä asioita niiden suhteen? Pystyvätkö käyttäjät muodostamaan yhteyden näihin palvelimiin? Se jatkuu. He ovat melko perustavanlaatuisia. Sitten muutama hauska - onko asiakaspalvelu vihreä? Koska jos ei, niin kaikki menee hyvin, ja kuka saa munkkeja? Elämä oli todella yksinkertaista noina päivinä. Jo tuolloin, ja sitten puhun 20–30 vuotta sitten, monimutkaisuus oli edelleen todella korkea. Voisimme suhteellisen suoraviivaisesti hallita palvelutasosopimuksia ja seurata suorituskykyä. Emme voi tehdä sitä enää käsin, kuten Robin viittasi. Haaste on liian suuri. Tosiasia on, että muutama hyvä sovellus, järjestelmänvalvoja, järjestelmäverkko ja tietokanta, järjestelmänvalvojat voivat seurata ja tavata suorituskykyä koskevia SLA: ita. SLA: t ovat niin kaukana nyt, että kamppailisin eilen illalla laatiessani viimeisiä muistiinpanojani edes ajatella vuotta, jolloin onnistuin viimeksi katsomaan erittäin monimutkaisen pinon järjestelmää, ymmärtämään sitä ja edes ymmärtämään mikä oli jatkuvan konepellin alla, ja olen kotoisin syvästi teknisestä taustasta. En voi kuvitella, miltä se on päivittäisessä tilanteessa nyt hallinnollisella tavalla.
Mitä tapahtui? No, vuonna 1996 tietokantapohjaiset sovellukset muutettiin Internet-puomin myötä. Monet meistä ovat käyneet läpi tämän. Vaikka et olisi ollut Internet-puomin ympärillä, voit helposti vain katsella ympärilleen ja ymmärtää, että jokapäiväisessä elämässämme koukku nyt kaikki Internetiin. Uskon, että meillä on leivänpaahdin, joka ilmeisesti sisältää mahdollisuuden päästä langattomaan verkkoon, mikä on naurettavaa, koska en tarvitse leivänpaahdinani kytkettynä Internetiin. 2000-luvulla, etenkin 2000-luvun alkupuolella, meidän piti käsitellä tätä monimutkaisuuden valtavaa kasvua, joka tarjosi palvelun suorituskyvyn dot-com-puomissa. Sitten uusi naurettava hankala kipinä Web 2.0: ssa, jossa älypuhelimet syntyivät ja nyt sovellukset olivat käsissämme ympäri vuorokauden ja olivat aina päällä-tilassa.
On nyt vuosi 2016, kohtaamme toisen askelpilven muodossa pilvi, iso data ja liikkuvuus. Nämä ovat vain niin suuria järjestelmiä, että niitä on usein vaikea ymmärtää ja laittaa selkeästi englanniksi. Kun ajattelemme sitä tosiasiaa, että joillakin suurilla yksisarvisilla, joista puhumme, on kymmeniä satoja petatavuja tietoja. Tämä on koko kerros levytilaa ja tallennustilaa vain sähköpostiviestiesi, kuvasi ja sosiaalisen median pitämistä varten. Tai joissain tapauksissa kuljetus- ja merilogistiikassa kaikki on pankkitoimintaa, missä rahasi ovat tai missä postisi on tai missä olet ostanut eBayssa. Seuraava iso aalto, jota kohtaamme on tämä asioiden Internetin erittäin suuri haaste.
Jos tämä ei ollut tarpeeksi huono, rakennamme tekoälyn ja kognitiivisen tietojenkäsittelyn melkein kaikkeen. Keskustelemme Sirin ja Google-moottorien kanssa nykyään. Tiedän, että Amazonilla on oma oma. Baidulla on yksi näistä laitteista, joiden kanssa voit puhua, he muuntavat sen tekstiksi, joka menee normaaliin järjestelmään, tietokanta tekee kyselyn ja tulee takaisin ja kääntää prosessin. Ajattele sitä monimutkaisuutta. Tosiasia on, että nykypäivän vakiosovelluspinon monimutkaisuus on kaukana ihmisen kyvyistä. Kun mietit kaikkea, mitä tapahtuu, kun painat älypuhelimen tai tablet-laitteen nappia, puhut sitä, muunat sen tekstiksi, ajatut internetin aina taustajärjestelmään, käyttöliittymä vastaanottaa joka muuntaa sen kyselyksi, suorittaa kyselyn sovelluspinon kautta, käy tietokannan läpi, osuu levylle, tulee takaisin ulos ja keskellä on operaattoriverkko, lähiverkon tilakeskus. Monimutkaisuus on hullua.
Vakuutamme tämän tosiasiallisesti hyperscale-arvona. Hypersalan monimutkaisuus ja nopeus on vain silmien kastelua. Sovelluksista ja tietokannoista on tullut niin suuria ja niin monimutkaisia, että suorituskyvyn hallinta on itse asiassa tiede. Monet viittaavat siihen rakettitieteenä. Meillä on paikan päällä tekniikka, meillä on ulkopuolinen tekniikka, meillä on useita datakeskusvaihtoehtoja; fyysinen ja virtuaalinen. Meillä on fyysisiä ja virtuaalisia palvelimia, meillä on pilvi, meillä on infrastruktuuri palveluna ja alusta palveluna ja ohjelmisto palveluna on asia, jonka nyt pidämme itsestään selvänä. Jälkimmäisestä, ohjelmistosta palveluna, tuli pelottava hetki muutama vuosi sitten, kun talousjohtaja ja organisaation osa tajusi, että pystyivät noutamaan luottokorttinsa ja vain ostamaan asioita itse ja käymään CIO: n ympärillä, ja kutsumme tätä "varjoksi" IT ”ja CIO: t yrittävät nyt kääntää tämän taakse ja painivat ohjausobjektin takaisin.
Infrastruktuurissa meillä on ohjelmistojen määrittelemä verkottuminen, verkkotoimintojen virtualisointi, alla, joka on todennäköisesti ohi, nyt meillä on mikropalvelut ja aktiivisten palveluiden sovellukset. Kun napsautat URL-osoitetta, URL-osoitteen lopussa on joukko liiketoimintalogiikkaa, joka kuvaa, mitä se tarvitsee toimittaakseen sen. Sillä ei välttämättä ole valmiiksi rakennettua logiikkaa odottamassa sitä. Meillä on toisella puolella perinteisiä tietokantoja, jotka ovat skaalautuvat erittäin, erittäin suuriksi. Meillä on Hadoopin infrastruktuurin kaltaisia tyyppejä ja toisen spektrin ekosysteemejä, jotka ovat vain niin suuria, että kuten sanoin, tiedätkö, ihmiset puhuvat nyt sadoista petatavuista dataa. Meillä on monimutkaisuus liikkuvuudeltaan laitteita, jotka kuljettavat ympäri, kannettavat tietokoneet ja puhelimet ja tabletit.
Meillä on BYOD joissakin suljetuissa ympäristöissä ja yhä enemmän nyt, koska Gen Y: n kokeneet ihmiset tuovat omia laitteitaan. Annoimme heidän vain puhua heidän kanssaan verkkoliittymistä. Joko Internetissä tai Wi-Fi: n kautta, meillä on ilmainen langaton internetyhteys alakerran kahvilassa heidän kahvitessaan. Tai sisäinen Wi-Fi. Koneesta toiseen on nyt aina läsnä. Se ei ole suoraan osa asioiden Internetiä, mutta se liittyy myös toisiinsa. Asioiden Internet on aivan uusi monimutkaisuuspeli, joka ajattelee. Keinotekoinen älykkyys ja jos luulet, että se, mitä pelaamme nyt kaikkien Siri-laitteiden ja muiden niihin liittyvien laitteiden kanssa, joiden kanssa puhumme, on monimutkaista, odota, kunnes pääset tilanteeseen, jossa näet jotain nimeltään Olli, joka on kolmiulotteinen painettu bussi, joka vie noin kuusi ihmistä ja voi ajaa itseään ympäri kaupunkia. Voit puhua sille tavallista englantia, ja se puhuu sinulle. Jos se osuu liikenteeseen, se päättää kääntyä vasemmalle tai oikealle pääalueelta, jolla liikenne on. Kun se kääntyy ja olet huolissasi siitä, miksi se käännytään vasemmalle tai oikealle päätieltä, se sanoo sinulle: “Älä huoli, aion kääntyä vasemmalle. Edessä on liikennettä ja aion kiertää sitä. ”
Kaikkien siellä olevien järjestelmien suorituskyvyn ja kaiken monimutkaisuuden hallitseminen, niiden tietojen kulkemisen seuraaminen, siirretäänkö ne tietokantaan, kaikki yhdyskytkennät ja kaikki asiaankuuluvat bitit ovat vain mielenkiintoisia. Todellisuus on, että suorituskyvyn ja SLA: n hallinta nykypäivän vauhdilla ja mittakaavoilla vaatii työkaluja ja järjestelmiä, ja oletuksena tämä ei ole enää jotain, josta luulet vain olevan kiva työkalu - se on edellytys; se on vain ehdottoman välttämätöntä. Tässä on jotain aivan kuten pieni esimerkki luettelosta OpenStack-avoimen lähdekoodin ohjelmiston määrittämän pilven korkean tason sovellussuunnitelmakaavioista. Tämä on vain iso kimpale. Tämä ei ole vain palvelimia ja tietokantoja. Täällä jokainen pieni sininen möykky edustaa ryhmiä asioita. Joissain tapauksissa tiedostot ja palvelimet tai sadat tietokannat tai tietysti enintään kymmeniä tuhansia pieniä palaja sovelluslogiikkaa. Se on pieni versio. Se on todella mielenkiintoista, kun alkaa miettiä tämän monimutkaisuutta. Tänään, vaikka vain suuressa datatilassa, laitan vain joitain kuvakaappauksia vain tuotemerkeistä. Kun mietit kaikista kappaleista, joita meidän on täällä hallittava, emme puhu pelkästään yhdestä tuotemerkistä, nämä ovat kaikki merkkejä suuressa tietomaisemassa ja parhaita tuotemerkkejä, eivät vain jokaista pientä tai avointa lähdekoodia. Näytät ja pidät sitä mieltä, että se on melko mielekäsittävä kaavio.
Katsotaanpa vain muutama pystysuunta. Otetaan esimerkiksi markkinointi. Tässä on samanlainen kaavio, mutta tekniikan pinoista, joita on saatavana pelkästään markkinointitekniikassa. Tämä on vuoden 2011 kaavio. Tässä on vuoden 2016 versio. Ajattele vain, tämä on vain määrä tuotemerkkejä, joita voit käyttää tekniikkaan markkinointitekniikan suhteen. Ei sisällä olevien järjestelmien monimutkaisuus, ei erilainen sovellus ja verkko, kehitys ja verkko ja kaikki muut. Vain tuotemerkki. Siellä on aikaisemmin, viisi vuotta sitten ja tässä on tänään. Se vain pahenee. Olemme nyt tosiasiassa, että ihmiset eivät yksinkertaisesti pysty varmistamaan kaikkia palvelutasosopimuksia. Emme voi sukeltua tarpeeksi yksityiskohtiin, riittävän nopeasti ja tarvittavassa mittakaavassa. Tässä on esimerkki siitä, miltä valvontakonsoli näyttää nyt. Tämä on kuin melkein kaksikymmentä paritonta näyttöä, jotka on liimattu yhteen teeskentelemällä olevansa yksi suuri, iso projisoitu näyttö, joka tarkkailee jokaista pientä palaa. Nyt se on mielenkiintoinen täällä, en mainitse brändiä, mutta tämä seurantaympäristö seuraa yhtä sovellusta logistiikka- ja toimitusympäristössä. Vain yksi sovellus. Jos ajattelet mitä Robin puhui, missä organisaatioilla voi nyt olla 40 000 tietokantaa tuotantoympäristöissä. Voitko vain visualisoida, mitkä 40 000 versiota tämän sovellusnäytön kokoelmasta voi seurata yhtä sovellusta? Se on erittäin rohkea maailma, jossa elämme. Kuten Robin sanoi ja aion ehdottomasti, kaikua sataprosenttisesti, että ilman oikeita työkaluja, ilman oikeaa tukea ja pöydällä olevia työkaluja pöydällä, sovellusten suorituskyky on menetetty peli ihmisille ja se on tehtävä työkaluilla ja ohjelmistoilla.
Sen avulla siirron ystävillemme IDERAssa.
Eric Kavanagh: Hyvä on, Bill.
Bill Ellis: Kiitos. Näyttöni jakaminen täällä. Luulenko, että joku voi vahvistaa, että näet ruudun?
Dr. Robin Bloor: Kyllä.
Eric Kavanagh: Se näyttää hyvältä.
Bill Ellis: Kiitos. Yksi asia, johon hän viittasi, oli, en todellakaan voi odottaa, että se oli itse ajava auto. Ainoa asia, josta en ollut kuullut kenenkään puhuvan, on, mitä tapahtuu, kun sataa lunta? Ihmettelen, jos Kalifornian insinöörit tajusivat, että muualla maassa lunta on melko vähän.
Dez Blanchfield: Pidän siitä, muistan sen.
Eric Kavanagh: Tyypillinen maili tunnissa.
Bill Ellis: Olemme täällä puhumassa sovellusten suorituskyvyn hallinnasta monimutkaisessa ympäristössä. Yksi asia, josta haluan puhua on, että monet ihmiset, kun he puhuvat suorituskyvystä, reaktion luonne on, hei enemmän palvelimia, enemmän prosessoria, enemmän muistia jne. Kolikon toinen puoli on prosessoinnin tehokkuus. Oikeasti, se on saman kolikon kaksi puolta ja katsomme molemmat. Perimmäisenä tavoitteena on täyttää palvelutasosopimukset liiketoimista. Viime kädessä kaikki tämä tekniikka on olemassa yritykselle. Puhuimme siitä, että meillä on alan ensimmäinen suorituskyvyn hallinnan tietokanta. Tämän ihanne on sopivuus suorituskyvyn ihanteelliseen muottiin ja sen hallitseminen sovellusten elinkaaren alusta alkaen.
Aiheet kiehuvat neljään kappaleeseen; yksi on suorituskyvyn hallintaprosessi. Puhuimme kaikkien kanssa, ja jokaisella on työkaluja. Jos heillä ei ole työkaluja, heillä on skriptejä tai komentoja, mutta niistä puuttuu konteksti. Konteksti on yksinkertaisesti pisteiden yhdistäminen sovelluspinoihin. Nämä sovellukset - ovat selainpohjaisia. Ne ovat erittäin tiukasti kytketty tasosta toiseen. Tasojen vuorovaikutus on myös elintärkeää. Sitten puhumme liiketoimista. Annamme näkyvyyden paitsi teknisille ihmisille, myös sovellusten omistajille ja operaation johtajille.
Minulla on pari tapaustutkimusta, jotta voin vain jakaa kanssanne kuinka asiakkaat ovat asettaneet nämä käytettäväksi. Tämä on hyvin käytännöllinen osa esitystä täällä. Katsotaanpa mitä tapahtuu. Pidän kaaviosta - se oli kuin uskomaton kollaasi tekniikoista. Tietokeskuksen teknologioiden lukumäärä on juuri kasvanut ja kasvanut. Samaan aikaan loppukäyttäjä ei välitä siitä, ja on unohtaa sen. He haluavat vain harjoittaa kauppaa, jos se on saatavilla, saada se nopeasti päätökseen. Tyypillisesti tapahtuu, että tietotekniikan ammattilaiset eivät tiedä, että loppukäyttäjillä oli jopa ongelma, kunnes he ilmoittavat itse. Se käynnistää tyyppisen aikaa vievän, hitaan prosessin ja usein turhauttavaa. Tapahtuu kuitenkin, että ihmiset avaavat työkalunsa ja katsovat osaa sovelluspinostaan. Tällä alajoukolla on erittäin vaikeaa vastata yksinkertaisimpaan kysymykseen. Onko sinulla tavallista, että sinulla on ongelma? Mikä kauppa on? Missä sovelluspinossa pullonkaula on? Vietämällä koko tämän ajan, etsimällä tasoa kerrallaan, etkä pysty vastaamaan näihin kysymyksiin, kulutat paljon aikaa ja energiaa, paljon henkilöstöä, varoja ja energiaa selville saadakseen selville.
Tämän ratkaisemiseksi paremman tavan aikaansaamiseksi Precise itse asiassa ottaa loppukäyttäjän seurata tapahtuman, sieppaa siitä metatiedot, seuraa tapahtumaa verkon kautta, verkkopalvelimelle, liiketoimintalogiikan tasolle ja tuemme .NET- ja ABAP- sekä PeopleCode- ja E-Business Suite -sovelluksia monitasoisissa sovelluksissa, joissa viime kädessä kaikki tapahtumat tapahtuvat vuorovaikutuksessa tietuejärjestelmän kanssa. Olipa kyse inventaariohausta, raportoidusta työajasta, he ovat aina vuorovaikutuksessa tietokannan kanssa. Tietokannasta tulee liiketoiminnan suorituskyvyn perusta. Tietokanta puolestaan luottaa tallennukseen. Mitä liiketoimien metatiedot vastaavat, kuka, mikä tapahtuma, missä sovelluksen pinossa, ja sitten meillä on syvä kooditason näkyvyys näyttää sinulle, mitä suoritetaan. Tietoja kaappaaan jatkuvasti, laitetaan suorituskyvyn hallintaan tietokantaan - siitä tulee yhdeksi arkkikappaleksi kaikille nähdä, mitä tapahtuu. On olemassa erilaisia ihmisiä ja organisaatioita, jotka välittävät siitä, mitä tapahtuu: tekniset asiantuntijat, sovellusten omistajat, viime kädessä itse yritys. Kun ongelma ilmenee, haluat pystyä purkamaan tietoja kyseisestä tapahtumasta.
Ennen kuin katsomme sijoituskauppaa, haluan näyttää sinulle, kuinka se voi näyttää erilaisille ihmisille organisaatiossa. Hallintatasolla saatat haluta olla yleiskuva useista sovelluksista. Haluat ehkä tietää terveydestä, jonka SLA-vaatimustenmukaisuus ja saatavuus laskevat. Että terveys ei tarkoita, että kaikki toimii sataprosenttisesti täydellisesti. Tässä tapauksessa on tilaa, voit nähdä, että sijoitustoimi on varoitustilassa. Nyt hieman syvemmälle, ehkä toimialalla, haluat saada lisätietoja yksittäisistä tapahtumista, kun ne rikkovat SLA-sopimuksia, tapahtumien lukumäärää jne. Operaatiotiimi haluaa saada siitä ilmoituksen siitä joidenkin ilmoitusten avulla. järjestellä. Meihin on rakennettu suorituskykyhälytyksiä. Mittaamme tosiasiallisesti loppukäyttäjän selaimessa. Onko se Internet Explorer, Chrome, Firefox jne., Jonka pystymme tunnistamaan, tämä vastaa ensimmäiseen kysymykseen: onko loppukäyttäjällä ongelmia?
Sukellaan sisään ja katsotaan, mitä muuta voimme näyttää siitä. Suorituksesta kiinnostuneet ihmiset avaavat tarkan. He olivat arvioineet tapahtumia. He katsoivat SLA-saraketta tunnistaakseen tapahtumat, jotka eivät olleet SLA: n mukaisia. He näkivät loppukäyttäjät, joihin vaikutettiin, samoin kuin mitä tapahtuma teki, kun se kulki sovelluksen läpi. Tapa, jolla nämä hieroglifit puretaan, on selain, URL, U on URL, se on tulo kohta JVM: ään. Nyt tämä tietty JVM kutsuu verkkopalvelimen soittamaan toiselle JVM: lle, joka sitten suorittaa SQL-käskyn. Tämä on selvästi tietokantaongelma, koska tämä SQL-käsky oli vastuussa 72 prosenttia vastausajasta. Olemme keskittyneet aikaan. Aika on suorituskyvyn valuutta. Se, kuinka loppukäyttäjät kokevat, kulkevatko asiat hitaasti vai ei, ja se on resurssien kulutuksen mitta. Se on erittäin kätevä; se on eräänlainen yksi mitta, joka on tärkein suorituskyvyn arvioinnissa. Kun tämä ongelma luovutetaan DBA: lle, se ei ole vain tietokantaongelma, se on tämä SQL-käsky. Tästä asiasta puhuin.
Nyt varustettuna näillä tiedoilla, voin mennä sisään analysoimaan tapahtuneita. Ymmärrän ensinnäkin, että y-akseli on päivä päivän ympäri. Anteeksi, y-akseli on vasteaika, x-akseli on päivä päivän ympäri. Näen, että kyseessä on tietokantaongelma, on olemassa kaksi tapausta, palaa takaisin siihen virtaan, noutaa kyseinen SQL-käsky ja siirry asiantuntija-näkymään, missä Precise pystyy näyttämään, mitä tapahtuu, sen hallintaa, kuinka kauan koodi vie suorittaa. Tietokannan tasossa se on suoritussuunnitelma. Huomaa, että Tarkkuus valitsi toteutuksen aikana käytetyn todellisen suoritussuunnitelman, joka eroaa arvioidusta suunnitelmasta, joka olisi suunnitelman antamisen aikana eikä toteutuksen aikana. Se voi heijastaa tai ei heijastaa sitä, että tietokanta todella tapahtui.
Nyt täällä on SQL-lauseen vastausaikaanalyysi. Yhdeksänkymmentä prosenttia varastoinnissa käytetystä ajasta; kymmenen prosenttia käytettiin prosessorissa. Näen SQL-lausunnon tekstin sekä havaintoraportin. SQL-lauseen teksti alkaa paljastaa joitain koodausongelmia. Se on valitse tähti; joka palauttaa kaikki rivit - anteeksi, kaikki palautettavien rivien sarakkeet. Kääntämme takaisin lisää sarakkeita, joita sovellus tarvitsee tai ei tarvitse. Nämä sarakkeet käyttävät tilaa ja resursseja prosessointiin. Jos suoritat SAP: tä, yksi suurimmista muutoksista, koska HANA-tietokanta on sarakkeellinen, on se, että SAP: n uudelleenkirjoittaminen pohjimmiltaan valitun tähden valitsemiseksi ei ole, jotta ne voivat vähentää resurssien kulutusta huomattavasti. Tämä on pohjimmiltaan jotain, mitä tapahtuu paljon aikaa myös kotitekoisissa sovelluksissa, onko Java, .NET jne.
Tuo näyttö näyttää, kuka, mitä, milloin, missä ja miksi. Miksi pääsee, kuten SQL-käsky ja suoritussuunnitelma, jonka avulla voit ratkaista ongelmat. Koska Tarkkuus jatkuu jatkuvasti, voit tosiasiallisesti mitata ennen ja jälkeen SQL-käskytasolla, tapahtumatasolla, joten voit joko mitata itsesi sekä sovellusten omistajien ja hallinnan kautta, että olet ratkaissut ongelman . Tämä dokumentaatio on todella hyödyllinen. Tässä sovelluspinossa on paljon monimutkaisuutta. Monista sovelluksista, tosiasiassa, kaikki, joiden kanssa olemme puhuneet, ajavat ainakin osan sovelluspinosta VMwaren alla. Tässä tapauksessa he katsovat asiakaspalvelusovellusta, tarkastelevat tapahtumiaikaa ja korreloivat sen hidastumisen kanssa, joka on virtualisointitapahtuma. Tarkat seuraavat kaikkia virtualisointitapahtumia. Meillä on laajennus vCenteriin valitaksesi sen.
Pystymme myös havaitsemaan kiistan. Väite on erilainen kuin hyödyntäminen. Näytetään tosiasiallisesti, milloin meluisa naapuri vaikuttaa asiakkaan VM: ään asiakaspalvelimen sovelluksen yhteydessä. Nyt pystyn poraamaan ja saamaan tietoja ja näen tosiasiassa kaksi VM: tä, jotka kilpailevat tässä tapauksessa CPU-resursseista. Tämä antaa minulle näkyvyyden, jotta voin katsoa aikatauluja. Voin laittaa vieraan VM: n toiselle fyysiselle palvelimelle. Kaikki nämä tyypit asioihin, joihin saatat vastata, ja sen lisäksi voin tosiasiallisesti tarkastella kooditehokkuutta saadakseniko se käyttämään vähemmän prosessoria. Minusta on mielestäni melko hyvä esimerkki tässä esityksessä siitä, kuinka joku pystyi vähentämään prosessorin kulutusta suuruusluokilla.
Se oli VMware. Mennään itse koodiin, sovelluskoodiin. Tarkka pystyy näyttämään, mitä Java, .NET, ABAP-koodi, E-Business, PeopleCode jne. Tapahtuu. Nämä ovat pääsypisteitä WebLogiciin. Täällä on löytöraportti, joka kertoo minulle, että sinun on tarkasteltava näitä EJB: itä, ja kertoo, että sait myös lukituksen tapahtuu tässä järjestelmässä. Jälleen kerran, poraa alaspäin liiketoimintalogiikan tasossa, jotta voidaan nähdä mitä tapahtuu. Tässä tapauksessa tarkastelen tiettyjä tapauksia; Kannatan myös klusterointia. Jos sinulla on käynnissä useita JVM-koneita, voit joko tarkastella klusteria kokonaisuutena tai tarkastella yksittäisen JVM: n pullonkauloja.
Kun lukitsut, voin päästä poikkeuksiin. Poikkeus on hiukan erilainen kuin suoritusongelma. Tyypillisesti poikkeukset suoritetaan erittäin nopeasti. Koska siellä on logiikkavirhe ja kun osut siihen logiikkavirheeseen, se loppuu. Pystyimme kaappaamaan pinojäljenvedon poikkeuksen alussa. Tämä voisi säästää paljon aikaa, kun yritetään selvittää mitä tapahtuu, sinulla on vain pinojälki oikealla. Pystymme sieppaamaan myös muistivuodot. Ratkaisu sisältää myös tietokannan tason, voin mennä sisään, osaan arvioida tietokannan esiintymää. Jälleen kerran, y-akseli on aika, missä aika käytettiin, x-akseli on aika päivän aikana. Löytöraportti kertoo minulle automaattisesti, mitä järjestelmässä tapahtuu ja mitä voin katsoa.
Yksi Precisen löytöraportin asioista, siinä ei tarkastella vain lokkeja tai odotustilaa - siinä tarkastellaan kaikkia suoritustiloja, mukaan lukien suoritin, sekä tietojen palauttamista varastosta. Varastointi on erittäin tärkeä osa sovelluspinoa, varsinkin kun se on solid-state. Tietojen saaminen näistä linjoista voi olla erittäin hyödyllistä. Tietyille tallennusyksiköille voimme tosiasiallisesti porata ja näyttää, mitä yksittäisen laitteen tasolla tapahtuu. Tämäntyyppiset tiedot - jälleen kerran, se on syvää näkyvyyttä; se on laaja-alainen - antaa sinulle juuri tarpeeksi tietoa, jotta sinulla on enemmän vipuvapautta vetääksesi sovellusten suorituskyvyn ammattilaisena, jotta voit optimoida sovelluksesi kokonaisvaltaisesti vastaamaan näitä liiketoimia.
Minulla on pari tapaustutkimusta, jotka halusin kertoa teille. Matkustamme melko nopeasti; Toivon menevän hyvällä tahdilla. Tallennuksesta puhutaan, että kaikki muuttuvat ajan myötä laitteistoon. Siellä on laitteistotakuu. Toimiiko se todella myyjän kertoessa? Voit arvioida sen tarkalla. Tulit sisään, ja mitä täällä tapahtui, he käytännössä panivat uuden tallennusyksikön, mutta kun tallennusjärjestelmän ylläpitäjät katsoivat vain säilytysyksikkötasoa, he näkivät paljon kiistaa ja uskoivat, että tässä uudessa tallennusyksikössä saattaa olla ongelma . Tarkastellaan enemmän loppupäästä, tarkalleen sen osoittamiseksi, missä se todella tapahtuisi. Niiden lähtötaso oli tosiasiassa noin 400 meg sekunnissa, missä varastointi vastasi 38 prosenttia vasteajasta, joten se on aika korkea. Uuden varastointiyksikön avulla me todella kasvatimme läpimenoaikaa kuuteen, seitsemään sataan megiin sekunnissa, eli periaatteessa kaksinkertaiseksi, ja pystymme leikkaamaan varastointitason osuuden tapahtuma-aikaan puoliksi. Pystyn tosiasiallisesti piirtämään sen aikaisemmin, tämä on leikkausaika ja sen jälkeen.
Joten jälleen kerran dokumentaatio, joka todistaa, että laitteistoinvestointi oli sen arvoista, ja toimittivat niin kuin kyseinen myyjä oli odottanut. Asioiden monimutkaisuuden ja lukumäärän vuoksi on kaikenlaista, mitä voi tapahtua. Tässä tapauksessa heillä oli tosiasiassa tilanne, jossa kaikki syyttivät jonkin verran DBA: ta, DBA oli kuin ”No, ei niin nopea.” Täällä tarkastellaan todella SAP-sovellusta, mielestäni tämäntyyppiset skenaariot ovat melko yleisiä . Mitä tapahtui, he kehittivät käyttäjälle räätälöityjä tapahtumia. Käyttäjä on kuin: "Tämä on niin hidasta." ABAP-kooderi - joka on SAP: n ohjelmointikieli - sanoi: "Tämä on tietokantaongelma." He päätyivät avaamaan Tarkkoja; he mittasivat loppukäyttäjän 60 sekuntia, niin selvästi yli minuutin. Viisikymmentä kolme sekuntia vietettiin takaosaan. He poraavat takaosaan ja he todella pystyivät paljastamaan SQL-käskyn, joka on esitetty laskevassa järjestyksessä.
Tämä top SQL-käsky, joka vastaa 25 prosenttia resurssien kulutuksesta, sen keskimääräinen suoritusaika on kaksi millisekuntia. Et voi syyttää tietokantaa. Tiedätkö, hei, ei niin nopeasti, kaveri. Kysymys kuuluu, miksi teloituksia on niin paljon? No, he palauttivat sen takaisin ABAP: hen, hän meni sisään, tutki silmukan pesää, sai selville, että he kutsuvat tietokantaa väärään paikkaan, he käytännössä tekivät muutoksen, testasivat muutosta ja nyt uusi vastausaika on viisi sekuntia. Hieman hidasta, mutta he voisivat elää sen kanssa. Paljon parempi kuin 60 sekuntia. Joskus vain fermentoimalla, onko se sovelluskoodi, onko se tietokanta, onko se varastointi? Ne ovat alueita, joilla Precise, kun otetaan huomioon päästä päähän -tapahtumat, on siinä, missä Precise tulee esille. Periaatteessa lopetat nuo asiat.
Katson tuolloin, näyttää siltä, että meillä on vielä vähän aikaa käydä läpi pari muuta näistä. Aion seurata näitä. Sovellusta kehitettiin yli vuoden ajan. 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.
Täältä näet alla olevien taulukoiden rivien määrän kasvavan ja tämä on tyypillistä yritykselle. Haluat, että pöydät kasvavat. Asia on se, että lauseet ovat jäsentäviä, SQL-käskyjä tulee sisään, optimoijan on päätettävä, mitä tehdä ja valita, kun suoritussuunnitelma on nopea, valita toinen suoritussuunnitelma, kun se on hidasta, aiheuttaen näytön jäätymisen. Perusteellisen teknologian perusteella minun on tiedettävä, mikä on suoritussuunnitelma, ja Precise siepaisee sen minulle täydellisenä päiväyksen ja aikaleiman kanssa. Tämä on nopea ja tehokas, tämä on hidas ja tehoton. Tämä suodatinliittymä käyttää yksinkertaisesti paljon enemmän CPU: ta sovittaakseen tämän SQL-käskyn. Niillä on edelleen sama lopullinen vaikutus, mutta tällä on pohjimmiltaan hitaampi, vähemmän tehokas resepti tulossarjan toimittamiseksi. Joten, astumme läpi. Hei, meillä on aikaa pari lisää?
Eric Kavanagh: Joo, jatka sitä.
Bill Ellis: Okei, hyppään eteenpäin. Yksi asia, jonka haluan sinun huomioivan, puhuimme laitteistosta, puhuimme SAP: sta, .NET: stä, JD Edwardsista ja Java-SQL Server -ympäristöstä. Tämä on SAP, tässä tarkastelemme PeopleSoftia. Tarkan tukimatriisi on leveä ja syvä. Jos sinulla on sovellus, enemmän kuin todennäköistä, voimme instrumentoida sen tuottamaan tämän tason näkyvyyden. Yksi suurimmista muutoksista, jota tällä hetkellä tapahtuu, on liikkuvuus. PeopleSoft esitteli liikkuvuuden Fluid UI: llä. Fluid UI käyttää järjestelmää hyvin eri tavalla. Tämä sovellus on kehittymässä. Fluid UI - mitä hallinnan kannalta tekee, se antaa loppukäyttäjille mahdollisuuden käyttää puhelintaan ja se lisää tuottavuutta huomattavasti. Jos sinulla on satoja tai tuhansia tai jopa enemmän työntekijöitä, jos pystyt lisäämään heidän tuottavuuttaan, 1–2 prosenttia, sinulla voi olla valtava vaikutus palkanlaskentaan ja kaikkeen muuhun. Mitä tapahtui, tämä kauppa avasi PeopleSoft Fluid UI: n. Nyt puhutaan monimutkaisuudesta, tämä on PeopleSoft-pino. Yksi sovellus, vähintään kuusi tekniikkaa, lukuisia loppukäyttäjiä. Kuinka aloitat sen?
Precise aikoo jälleen kerran seurata näitä liiketoimia. Tässä näytetään pinottu pylväskaavio, joka näyttää asiakkaan, web-palvelimen, Java, Tuxedo-tietokannan ja PeopleSoft-sovelluspinon. Vihreät kartat J2EE: lle, joka on tavallaan hieno tapa sanoa WebLogic. Tämä on leikkaus. Loppukäyttäjät alkavat käyttää fluidi-käyttöliittymää ja reaktioaika kuluu ehkä puolitoista, kaksi sekuntia, noin yhdeksään, kymmeneen sekunniin. Mitä tämä yksi näyttö ei näytä, on joukko ihmisiä, jotka “eivät vastaa”. He todellakin näytön jäädyttävät sovelluksessa. Katsotaanpa sitä näkyvyyttä, jonka Precise pystyy tarjoamaan tälle asiakkaalle.
Ensinnäkin, kun tarkastelen PeopleSoftin liiketoimia, he näkevät pohjimmiltaan, me näimme tämän tyyppiset asiat kautta linjan. Vaikutettiin kaikkiin tapahtumiin, samoin kuin kaikkiin toimipaikkoihin. Muuten, kun tarkastelet tätä, voit tosiasiallisesti nähdä paikkoja ympäri maailmaa. Aasiasta ja Tyynenmeren alueelta Eurooppaan ja Pohjois-Amerikkaan. Suorituskykyongelma ei sijainnut tietyssä tapahtumassa tai tietyssä maantieteellisessä sijainnissa, se on järjestelmän laajuinen. Se on eräänlainen tapa sanoa, että muutos tai tapa, jolla Fluid UI oli globaali, vaikutti. Täältä näet skaalautuvuuden näkökulmasta, ihmiset yrittävät tehdä saman tyyppisiä aktiviteetteja, mutta vasteaika on periaatteessa vain huonontunut ja huonontunut. Voit nähdä, että asiat eivät ole mittakaavassa. Asiat menee hyvin, erittäin huonosti. Täällä, kun tarkastelen akselien lukumäärää ja samanaikaisia yhteyksiä, näet jotain, joka on erittäin mielenkiintoinen pääsymäärästä ja yhteyksistä. Täällä skaalaamme vain noin 5000 ja katsot noin, tämä ylittää 100 samanaikaista yhteyttä. Tämä tehdään jälkeen; tämä on ennen. Joten mikä on todellinen järjestelmäni vaatimukseni, jos tämä asia voisi mitoittaa, se on 300 000: n alueella. Vanhalla ajalla klassisen käyttöliittymän avulla tarkastelet 30 samanaikaista yhteyttä.
Nyt tämä kertoo sinulle, että Fluid-käyttöliittymä käyttää vähintään kymmenkertaisia lukumääriä samanaikaisia yhteyksiä. Alamme vetää taaksepäin mitä kansien alla tapahtuu PeopleSoftin kanssa, jotta voit alkaa nähdä vaikutus web-palvelimiin, tosiasia, että SLA: t alkavat rikkoa. En aio mennä kaikkeen, mutta lopulta tapahtuu, että he luottavat periaatteessa viestintään. Periaatteessa he käyttävät WebLogic-ohjelmaa ja aiheuttavat jonotuksen Tuxedossa. Oli todella monitasoinen riippuvuusongelma, joka ilmestyi Fluid-käyttöliittymän kanssa, mutta Tarkko pystyi osoittamaan, että koko joukolla erilaisia asioita voimme keskittyä siihen, mikä ongelma oli. Osoittautuu, että myös itse tietokannassa oli ongelma. Itse asiassa on olemassa lokitiedosto, ja kaikkien samanaikaisten käyttäjien takia lokitiedosto lukittiin. Periaatteessa siinä oli asioita viritettävissä jokaisessa sovelluspinoon kuuluvassa tasossa. Puhutaan monimutkaisuudesta. Tässä on Tuxedo-taso, joka näyttää jonotuksen, ja voit nähdä suorituskyvyn heikentyvän myös tässä tasossa. Voin nähdä prosessit; Voin nähdä verkkotunnukset ja palvelimet. Tuxedossa ihmiset avaavat käyttää sitä yleensä avaamalla uusia jonoja, verkkotunnuksia ja palvelimia, kuten supermarketissa ruuhkien lieventämiseksi, jonotusajan minimoimiseksi. Viimeinen ja viimeinen vaihtoehto, Tarkka näyttää paljon tietoa.
Kuten olen aiemmin maininnut, jokainen merkittävä tapahtuma on vuorovaikutuksessa tietuejärjestelmän kanssa. Tietokannan näkyvyys on ensiarvoisen tärkeää. Tarkka näyttää mitä tapahtuu tietokannassa, WebLogicissa, Javassa, .NET, selaimessa, mutta paikka, josta Precise todella etenee, on tietokannan tasossa. Tämä sattuu olemaan kilpailijoidemme heikkous. Annan näyttää sinulle yhden tavan, jolla Precise voi auttaa sinua läpi tämän. En aio viettää aikaa tietokannan optimoinnin kolmioon, mutta tarkastelemme periaatteessa edullisia, alhaisen riskin, laaja-alaisia, korkean riskin, kalliita tyyppimuutoksia. Tosin twiitit tämän dion myöhemmin, jos ihmiset haluavat kokeilla sitä. Se on mielestäni melko iso opas viritysongelmiin. Tässä on tarkka Oracle-asiantuntija-näkymä. Löytöraportin kärjessä 60% vaikutus on tähän tiettyyn SQL-lauseeseen. Jos avaat tämän aktiviteettinäytön, se näyttää sen siellä. Voin tarkastella tätä valittua lausetta, siinä on yksi suoritussuunnitelma. Jokainen teloitus vie sekunnin - 48 000 teloitusta. Se lisää jopa 48 000 tuntia teloituksia.
Tummansininen on jälleen kerran CPU. Tämä asia on sidottu prosessoriin, ei odotustila, ei loki. Korostan, että koska jotkut kilpailijoistamme katsovat vain odotustiloja ja lokitapahtumia, mutta yleisesti ottaen CPU on vilkkain suoritustila ja tarjoaa eniten takaisinostoa. Päästyään tähän asiantuntijanäkemykseen - ja menen hyvin nopeasti - mitä tein, katsoin pöytää, 100 000 riviä, 37 000 lohkoa. Teemme koko pöydän, mutta meillä on kuusi hakemistoa tästä asiasta. Mitä täällä tapahtuu? No, kun tarkastelen missä lauseessa, mitä tämä lause tekee, se on todella muuntaa sarakkeen isoiksi ja se sanoo, missä se on yhtä suuri kuin iso, löytää muuttuja. Tapahtuu joka kerta, kun tämä asia suoritetaan, Oraclen on muutettava tämä sarake isoiksi. Sen sijaan, että se tekisi lähes viisikymmentä tuhatta kertaa, on paljon tehokkaampaa rakentaa kyseinen hakemisto toimintoperusteisen hakemiston isoina kirjaimina ja se on saatavana paitsi Oracle-yrityksen, myös standardi, toimialaan. Kun teet niin, mitä voit sitten tehdä, on tarkistaa suoritussuunnitelma, joka myöntää uuden hakemiston käyttäjän perm-iso kirjainkoko, se oli juuri oma juttuni.
Sitten ennen ja jälkeen mittauksesta tarkastellaan yhden sekunnin suoritusaikaa, aggregoitua jopa 9 tuntiin 54 minuuttiin samalla tarkalla SQL-käskyllä, mutta kun hakemisto on rakennettu isoilla kirjaimilla 58 000 toteutusta varten, vastaus aika putoaa alle millisekunteihin, aggregoituna yhteen, se tulee jopa seitsemään sekuntiin. Säästin periaatteessa kymmenen tuntia prosessoria palvelimelleni. Tämä on valtava. Koska en tarvitse palvelimen päivitystä, voin elää sillä palvelimella. Lasen palvelimen käytön tosiasiallisesti 20 prosentilla ja näet tosiasiallisesti ennen ja jälkeen. Se on sellainen näkyvyys, jonka tarkka voi tarjota. Siellä on myös joitain lisäasioita, joista saatamme katsoa, miksi sinulla on kaikki nämä hakemistot, jos niitä ei käytetä? He voivat seurata sitä. Siellä on arkkitehtuuria, ja kääritän sen, koska olemme saavuttaneet tunnin huipun. Olen todellinen uskovainen tähän ratkaisuun ja haluamme sinun olevan todellinen uskovainen. IDERAssa uskomme, että kokeilu saa asiakkaan, joten jos olet kiinnostunut, pystymme tekemään arviointeja sivustossasi.
Sen avulla välitän majakka takaisin.
Eric Kavanagh: Niin, tämä on ollut valtava yksityiskohta, jonka osoitit siellä. Se on todella kiehtovaa. Luulen, että olen ehkä maininnut teille aikaisemmin, että - ja tiedän joistakin muista IDERA: n kanssa tekemistämme verkkolähetyksistä - olen todella seurannut tarkkaa jo ennen kuin IDERA on hankkinut sen, aina takaisin vuoteen 2008, luulen tai 2009. Minua kiehtoi siitä tuolloin. Olen kiinnostunut tietää, kuinka paljon työtä tulee pysyä uusien sovellusjulkaisujen päällä. Mainitsit SAP HANA: n, joka on mielestäni melko vaikuttavaa, että voit itse tutkia HANA-arkkitehtuuria ja tehdä siellä joitain vianmäärityksiä. Kuinka monta ihmistä sinulla on? Kuinka paljon vaivaa se on teidän puolestanne ja kuinka suurta osaa siitä voidaan tehdä jonkin verran dynaamisesti, mikä tarkoittaa, että kun työkalu otetaan käyttöön, ryhdytte indeksoimaan ja näkemään erilaisia asioita? Kuinka suuri osa siitä voi olla dynaamisesti, eräänlainen, työkalun varma, jotta voit auttaa ihmisiä vianmäärityksessä monimutkaisissa ympäristöissä?
Bill Ellis: Kysitte siellä paljon kysymyksiä.
Eric Kavanagh: Tiedän, anteeksi.
Bill Ellis: Annoin paljon yksityiskohtia, koska näihin sovelluksiin nähden koodia paholainen on yksityiskohdissa. Sinulla on oltava niin yksityiskohtaiset tiedot, että todella voi olla jotain, joka on toimiva. Ilman toimivia mittareita tiedät vain oireista. Et oikeastaan ratkaise ongelmia. IDERA on ongelmien ratkaiseminen. Pysyminen uusien julkaisujen ja muiden tavaroiden päällä on iso haaste. Kysymys siitä, mitä sen tekemiseen tarvitaan, se on todella tuotteen hallintaa varten. Minulla ei ole paljon näkyvyyttä joukkueessa, joka periaatteessa pitää meidät ajan tasalla asioista. HANA: n kannalta se on oikeastaan uusi lisä IDERA-tuotelinjaan; Se on todella jännittävää. Yksi HANA: n asioista on - anna minun puhua sekunnista. SAP-kaupat tekisivät tehtävässä replikoivan tietokannan raportointia varten. Sitten sinun pitäisi saada ihmiset sovittamaan se, mikä tosiasiallisesti on nykyistä. Sinulla olisi nämä eri tietokannat ja ne olisivat eri tasojen synkronoimattomia. Kaiken tämän ylläpitämiseen tarvitaan vain paljon aikaa ja vaivaa sekä laitteistot, ohjelmistot ja ihmiset.
HANA-idea on erittäin samansuuntainen muistitietokanta, jotta pohjimmiltaan vältetään päällekkäisten tietokantojen tarve. Meillä on yksi tietokanta, yksi totuuden lähde, se on aina ajan tasalla, sillä tavalla vältät tarvittavan kaiken tämän sovinnon. HANA-tietokannan suorituskyvyn merkitys kasvaa - sanon 10x tai ainakin arvokkaampaa kuin kaikkien muiden tietokantojen, laitteistojen ja resurssien summa. Koska pystyt hallitsemaan HANA: ta, nyt, kun komponentti on todella beta-testauksessa, se on jotain, joka menee GA: n käyttöön pian. Joten se on aika jännittävää IDERAlle ja meille periaatteessa SAP-alustan tukemiselle. En ole varma, mitä muita kysymyksesi osia olen tyypillisesti muuttanut, mutta -
Eric Kavanagh: Ei, siinä on kaikki hyvää. Heitin koko joukon teitä kaikkia kerralla, niin pahoillani siitä. Olen vain kiehtonut, tarkoitan, että tämä ei ole kovin yksinkertainen sovellus, eikö niin? Kaivaat syvällisesti näitä työkaluja ja ymmärrät kuinka ne ovat vuorovaikutuksessa keskenään ja pisteesi kanssa, sinun on pakko juttua juttu yhdessä päässäsi. Sinun on yhdistettävä bittiä tietoja ymmärtääksesi mitä todella tapahtuu ja mikä aiheuttaa sinulle ongelmia, jotta voit mennä sinne ja ratkaista nämä ongelmat.
Yksi osallistujista kysyy, kuinka vaikeaa on tarkan käyttöönotto? Toinen henkilö kysyi, keitä ihmiset ovat - tietysti DBA: t - mutta mitkä ovat organisaation muut roolit, jotka käyttäisivät näitä työkaluja?
Bill Ellis: Tarkkuuden käyttöönotto on hieman monimutkaisempaa. Sinulla on oltava jonkinlainen tieto sovellusympäristöstä, sillä, mitä tiedät, tämä sovellus toimii tässä tietokannassa, se tarvitsee tai - keskitason verkkopalvelimia jne. Mielestäni joidenkin näiden sovellusten monimutkaisuuden vuoksi, se on oikeastaan suhteellisen helppoa. Jos voin sovittaa verkkopalvelimen tietokantaasi, voin tehdä sen päästä päähän. Huomaat, että en sanonut mitään loppukäyttäjäasiakkaan instrumentoinnista, ja se johtuu siitä, että mitä teemme, sisällytetään itse asiassa dynaamisesti, joten sinun ei tarvitse muuttaa koodiasi tai jotain muuta. JavaScripti menee sovellussivun kehykseen. Riippumatta siitä, missä käyttäjä maailmassa on, kun he käyttävät sovelluksesi URL-osoitetta ja he alaavat sivun, sen mukana toimitetaan tarkkuus. Tämän avulla voimme valita käyttäjätunnuksen, heidän IP-osoitteensa, myös kunkin sivukomponentin komentosarjan suorittamisajan ensimmäisen tavun esittämisajan loppukäyttäjän selaimessa.
Tapahtumien kannalta sinun ei tarvitse kartoittaa tapahtumia, koska ne ovat tiukasti kytkettyinä toisiinsa. Tästä URL-osoitteesta tulee sisääntulopiste JVM: ään ja kutsutaan sitten tämä viesti, mikä johtaa JVC: n kaappaukseen tietokannasta. Pystymme periaatteessa tarttumaan noihin luonnollisiin yhteyspisteisiin ja esittämään ne sitten sinulle siinä transaktionäytössä, jonka osoitin sinulle, missä laskimme myös kuinka paljon aikaa tai prosentuaalinen aika kului kussakin yksittäisessä vaiheessa. Kaikki tämä tapahtuu automaattisesti. Yleisesti ottaen meillä on 90 minuuttia aikaa tehdä - tarkan ytimen asentaminen pohjimmiltaan ja sitten aloitamme sovelluksen toteuttamisen. Sovelluksen tietämyksestä riippuen voi viedä meille ylimääräisiä istuntoja saadaksemme koko sovelluksen instrumentiksi. Monet ihmiset käyttävät vain Precise-tietokantakomponenttia. Se on hieno. Voit periaatteessa rikkoa tämän, hajottaa sen komponenteiksi, jotka sinusta tuntuvat sivustosi tarvitsevan. Uskomme ehdottomasti, että koko sovelluspinon instrumentti, jonka avulla voit nähdä, että tason riippuvuus todella suurentaa yksittäisen tason seurannan arvoa, on tosiasia. Jos joku haluaa tutustua sovelluspinonsa instrumentointiin, siirry verkkosivuillemme - luulen, että se on helpoin tapa pyytää lisätietoja, ja keskustelemme siitä vähän tarkemmin.
Eric Kavanagh: Annan heittää sinulle yhden tai kaksi nopeaa kysymystä. Arvaan, että keräät ja rakennat arkistoa ajan mittaan, sekä yksittäisille asiakkaille että kokonaisuutena yhteisölle, vuorovaikutuksesta eri sovellusten ja eri tietokantojen välillä. Toisin sanoen skenaarioiden mallintaminen on mielestäni viittaus. Onko niin? Pidätkö itse asiassa eräänlaista arkistoa yleisiä skenaarioita siten, että voit tehdä ehdotuksia loppukäyttäjille, kun tietyt asiat tulevat peliin? Kuten tämä E-Business Suiten versio, tämä tietokannan versio jne. - teetkö paljon siitä?
Bill Ellis: No, tämäntyyppiset tiedot on sisällytetty havaintoraporttiin. Havaintoraportissa kerrotaan, mitkä ovat suorituskyvyn pullonkaulat, ja se perustuu suoritusaikaan. Osa havaintoraportista on lisätietoja ja mitä teet seuraavaksi. Asiakkaiden tiedot tai kokemukset ja niin edelleen sisällytetään periaatteessa kyseiseen suosituskirjastoon.
Eric Kavanagh: Okei, se kuulostaa hyvältä. Hyvin ihmiset, upea esitys tänään. Bill, rakastin kuinka paljon yksityiskohtia sinulla oli siellä. Ajattelin vain, että tämä oli todella upeaa, rakeista, rakeista tietoa, joka osoittaa kuinka kaikki nämä asiat tehdään. Tietyssä vaiheessa se on melkein kuin musta taikuutta, mutta oikeasti, se ei ole. Se on hyvin spesifinen tekniikka, jonka te kaverit yhdessä ymmärrät hyvin, hyvin monimutkaisista ympäristöistä ja tee ihmisistä onnellinen, koska kukaan ei pidä, kun sovellukset toimivat hitaasti.
No, ihmiset, arkistoimme tämän webcastin. Voit hypätä verkossa Techopediaan tai insideanalysis.com-sivustoon ja wow, kiitos ajastasi, otamme sinuun yhteyttä seuraavalla kerralla. Ole varovainen.
