A Techopedia munkatársai, 2017. szeptember 6
Elvihető: Eric Kavanagh a házigazda megbeszélte a PeopleSoft teljesítménymenedzsmentet Matt Sarrel és Bill Ellis-kel a Hot Technologies ebben a részében.
Eric Kavanagh: Jól van, hölgyeim és uraim. Üdvözlet és üdvözlöm még egyszer. Szerda van 4 órakor, keleti irányban, és az utóbbi néhány évben azt jelentette az informatika, a nagy üzlet és az adatok világában, itt az ideje a Hot Technologies számára. Igen, nevem Eric Kavanagh. A mai rendezvény moderátora vagyok.
Az üzleti tevékenységet folytató rendszerekről fogunk beszélni, emberek; a PeopleSoft-ről beszélünk, hogyan lehet kezelni a komplex környezetek teljesítményét. Mindig szeretnék megemlíteni, hogy nagy szerepet játszik ezekben az eseményekben, ezért kérlek, ne légy félénk. Bármikor kérdezze meg kérdését; ezt megteheti a csevegőablak vagy a Kérdések és válaszok segítségével - akárhogy is átjut. Szeretném hallani, mit szeretne tudni, és ez a legjobb módszer; Ön a lehető legjobban megkapja az idejét. Mindezeket az internetes adásokat archiváljuk későbbi meghallgatás céljából, tehát csak ezt tartsd szem előtt.
Ha a rendszerek lassan működnek, ne feledje, hogy milyen volt az élet. Ez a fotó valójában 1968-ból származik, Danelle nevű hölgy jóvoltából, és azt kell mondanom, hogy ez valóban emlékeztető arra, hogy mennyire változtak a dolgok. A világ jelentősen összetettebbé vált, és természetesen az üzleti igények és a felhasználói élmény általában kéz a kézben járnak. De manapság van egy kis leválás. Van egy eltérés, amint gyakran mondjuk, és az a tény, hogy az üzletemberek mindig gyorsabban és gyorsabban akarnak dolgokat, az informatikai csapatoknak, akiknek szállítást kell tenniük, nyomást gyakorolnak rá, hogy a munkát elvégezzék, és ez egy intenzív világ.
Azt kell mondanom, hogy a verseny mindenütt felmelegszik. Ha csak egy iparágra néz, láthatja, hogy manapság jelentős fejlemények vannak - például az Amazon vásárolja a Whole Foods terméket. Biztos lehet abban, hogy az élelmiszeripar kemény pillantást vet erre. Az egész helyet látjuk, tehát az üzleti vezetőknek ténylegesen kötelesek megbizonyosodniuk arról, hogy kitalálják, hogyan lehet digitális módon átalakítani - és ez itt a mai szólószó -, hogyan lehet a régi kapcsolótáblán túlmenni sokkal új és robusztus rendszerekhez. Erről beszélünk ma.
Az egyik kérdés, amely sok szervezettel szembesül, különösen azok, amelyek már egy ideje működnek, ezek a régi rendszerek. Ez egy régi IBM mainframe a nap folyamán. Régi rendszerek vannak mindenhol. Az egyik vicc az, hogy a régi rendszer egy termelés alatt álló rendszer, azaz a gyártásba lépés pillanatában, technikailag ez egy régi rendszer. Mindig lesznek új módszerek a dolgok elvégzésére.
És van néhány nagyon érdekes fejlemény az elmúlt években a rendszerek gyakorlati összehangolásának módjairól annak érdekében, hogy ne csak egy rendszer teljesítményét javítsák, hanem hogy megtalálják a módját, hogy létrehozzanak valamiféle kiugró vagy kirakodási taktikát a teljesítmény kezelésére. más módon. Ma többet fogunk beszélni arról, hogyan lehetne javítani egy olyan rendszer teljesítményét, mint a PeopleSoft, amely természetesen hihetetlenül összetett. De ha jól csináljuk, amikor betöltjük, ha megvalósítjuk, ha jól kezeljük, akkor csodálatos dolgokat is képes csinálni. De ha nem sikerül jól kezelni, akkor mindenféle probléma merül fel.
Mi történik? Reálisnak kell lennie a dolgok iránt és bármilyen környezetben, ha a felhasználók nem kapják meg azt, amit akarnak, előbb vagy utóbb árnyék rendszerekbe mennek. Mindig megtörténik. Az árnyékrendszerek nagyon eredményesek lehetnek, segíthetnek az embereknek a munkában. De természetesen sok kérdés van. Természetesen az előírások betartásának és a szabályozásnak az egész területén az árnyékrendszerek nagy "nem-nem". De vannak odakint, és azt hiszem, fontos megjegyezni, hogy ha a fő rendszer nem működik gyorsan vagy nem működik hatékonyan, előbb vagy utóbb megoldások lesznek, és ezeket a megoldásokat nagyon nehéz megtalálni, nehéz lehet napnyugtakor, mert a vállalkozás szempontjából kritikus jelentőségűek. Nehezen integrálható, ezért ne feledje, hogy odakinn van, és ez csak egy új ok a teljesítmény javítására.
Nemrég hallottam erről a kifejezésről, és oda kellett dobnom: „a sürgősség zsarnoka”. Azt hiszem, hogy csak azt hallottam, hogy valószínűleg tudod, miről beszélek, és mi történik a legtöbb szervezetben, hogy a munkaterhelés eléri a kritikus tömeget., és az emberek mindent megtesznek, és nagyon nehéz bármit megváltoztatni. Befejezi a „sürgősség zsarnoka” szenvedését - mindent azonnal meg kell tenni. Nos, a rendszer frissítése nem azonnal történik.
Bárki, aki valaha is átélte az ERP egyik verzióról egy másikra történő frissítését, tudja, hogy ez egy viszonylag fájdalmas folyamat, ezért ne feledje ezt: Ha látja a szervezetben, ismeri fel. Remélhetőleg megismerkedhet valakivel, vagy ha Ön idősebb ember, mint például CIO, CTO vagy vezérigazgató, akkor ismerjük fel, hogy ez egy nagyon veszélyes forgatókönyv, mert ha egyszer a nyolc labda mögött vagy, nagyon nehéz kijutni a nyolc labda.
Ez olyan, mint az egész maratoni összecsapás: Ha valamilyen versenyben messze elmaradsz és mindenki előtt állsz, és még mindig futtok, akkor nagyon nehéz lesz felzárkózni, ha túl messzire lemaradsz. Tehát csak vigyázz erre és tartsd ezt szem előtt.
És ezzel átadom Matt Sarrelnek, hogy betekintést nyújtsunk nekünk arról, hogyan kell kezelni a bonyolultságot a PeopleSoft környezettel. Matt, vedd el.
Matt Sarrel: Rendben, köszönöm, Eric. Üdv mindenkinek. És hát, lássuk, elkezdem azzal, hogy elmondjam neked, miért gondolom, hogy én vagyok a megfelelő ember, hogy beszéljek veled a teljesítmény irányításáról. Tehát 30 éves tapasztalattal rendelkezem a technológiában. Szeretném mondani, hogy felépítettem magam, amikor gyakorlati hálózatvezetőként, hálózati adminisztrátorként, informatikai igazgatóként és mérnöki osztályvezetőként dolgoztam néhány induló vállalkozásnál. Aztán ezt az átmenetet a PC Mag műszaki igazgatójává tettem. Ott van a képem, de alapvetően úgy nézek ki, mint egy kis gyerek.
Ezután újságíróként dolgozik számos különféle kiadványban, mint például az eWeek és az InfoWorld, elemzője a Gigahome-nak, hálózatépítést folytat a Bloor Csoporttal és konzultációt is működtet. És ott vagyok én: Ez a bal oldali kép néz ki most. Ez a középső kép olyan, ahol nagyon boldog vagyok - egy vezetékekkel és villogó fényekkel teli helyiségben, ahol hideg van -, nagyon hidegnek kell lennie, és mindenkinek kellemetlennek kell lennie, hogy jól érzem magam a hőmérsékleten- bölcs. És ott van az elérhetőségeim, ha további kérdése van.
Itt akarom állítani a színpadot, csak beszélni a teljesítményről, ahogy Eric is beszélt. Most belépettünk ebbe a világba, ahol a felhasználóknak ez az elvárásuk van, amelyet a fogyasztói alkalmazások és webhelyek határoztak meg. És az emberek hajlandóak voltak dolgozni menni, ott ülni, és várni a rendszerüket, mert erre volt szükségük, és most az emberek nem igazán hajlandóak ott ülni. Tehát az a kérdés, hogy akarják-e ezt a motorkerékpárt a pálya körül repülni. Valószínűleg nem akarják, hogy a srác lovagoljon a motorján és vezesse lányát az iskolába. De mit fogsz nyújtani?
És nehéz, mert - valóban nagyvonalúan nagylelkű voltam ezzel az egy-három másodpercig -, az emberek azonnali választ akarnak, és bárhonnan hozzáférést akarnak. Ez bárhol lehet az épületben vagy az egyetemen, vagy bárhol a világon bármikor lehet, attól függően, hogy mennyire jól működik vállalkozása. És azt hiszem, amit építek: az, hogy amikor a teljesítményről beszélünk, fontos a teljesítményre gondolkodni a felhasználói élmény szempontjából.
Fontos a teljesítménycélok meghatározása a mérés és a hangolás előtt. Nekem van ez a kép egy hangolóról, majd egy hangolóról. A valódi ember, aki hangoló, tudnia kell, hogy mit hangol, vagy nincs értelme valójában kezét a zongorára tenni, és behangolni. Tehát a célok előzetes meghatározása úgy fogja megőrizni, hogy a célokat a jelenlegi helyzethez igazítsák. Fontos figyelemmel kísérni a mutatókat az idő múlásával és felismerni, hogy a rendszerek hogyan változnak a felhasználói betöltési alkalmazások teljesítményével, amelyet az erőforrás jelenetek és a használati szokások befolyásolnak.
Mindig fontos mindezt összekapcsolni a felhasználói élménnyel vagy a támogatási eseményekkel, meg kell határozni az alapot annak a teljesítménynek, amelyet elvár, hogy képes lesz nyújtani, és ha közeledik az alaptól való eltéréshez, proaktív figyelmeztetésekkel rendelkezzen, hogy lépéseket tehessen. mielőtt elérnénk a „kurt bálna” státuszt. És tudod, hogy ehhez a képességhez szükséges a teljesítmény kérdésének nagyon gyors és egyszerű meghatározása és kezelése. És ismét, ez a korábbi, annál jobb, ugye?
Tudjuk, hogy a múlt története alapján a fejlesztési erőfeszítéseket tekintve minél előbb találhat és javíthat teljesítményproblémákat, annál jobb. Ha megvárja, amíg az összes kód vagy a rendszer működik, hogy megkezdje a teljesítmény tesztelését vagy a problémák feltárását, nem fogom mondani, hogy már késő, de ismét, most te vagy a srác, aki rosszul indult a maratonon, és most felzárkóztatást játszik, ahelyett, hogy rögtön kiugrott volna és előre lépne. Szóval hogyan csinálod ezt? Előre látja az átlagát és a csúcsterhelését?
És megy előre, és méretezi a fizikai kiszolgálókat vagy a virtuális kiszolgálókat, a felhőpéldányokat vagy a tárolókat és a tárolói erőforrásokat, majd futtatja a koncepció igazolását és futtat egy pilótát? Ez az az idő, amikor ez a fajta, és véget ér annak, amikor el szeretne érni valamit, bár ennek ellenére jobb, ha elkapja a termelésben, mint ha nem veszi figyelembe. De valóban, amíg pilótaként tartózkodik, már meg kellett volna határoznia a módszertant és az eljárásokat a folyamatos figyelemmel kísérés és fejlesztés körül.
Oké, tehát sok cég - beszélünk a digitális átalakulásról. A DevOps, a DevOps forradalomban óriási szerepet játszik abban a digitális átalakulásban. És ez egy teljes folyamat, amely valójában soha nem áll le. Tehát olyan, mintha a két kéz rajzolná egymást, és ez jó dolog. Ez egy végtelen hurok a terv, a kód, a készítés, a tesztelés, a kiadás, a telepítés, a működtetés, a monitor, a terv két kezének között. Ez táplálja magát, és mi automatizáljuk, így gyorsan megy. Létrehoz egy termelési teljesítmény-figyelő visszacsatoló hurkot, és azt felhasználja a teljesítményproblémák proaktív feltárására és kijavítására, még mielőtt azok kihatnának a teljes felhasználói bázisra.
És egy másik dolog: most, hogy megvan, az informatikai fejlesztők és az üzemeltetési személyzet nagyon gyorsan mozog és igazodik egymáshoz, ezeket az erőfeszítéseket az üzleti személyzettel is könnyen összehangolhatja. Az vállalati szoftverek teljesítménye összetett állat. Össze lehet hasonlítani egy olyan labdarúgó-válogatottkal, amely egy táblára áll, szemben az iránymutatással, és minden külön működik, és minden együtt működik. Mindig úgy gondolom, mint a régi történetre, amikor megszereztem az első autómat és rögzítettem egy dolgot. Rögzítettem a légkondicionálót, és akkor történt, hogy a hűtőrendszer többi része meghibásodott. Tehát megvan a fájdalom pontjai, és minden együtt megy, és kiigazításokat végez. Mindent oly módon kell megszerveznie, és a folyamatokat úgy kell felépítenie, hogy a változtatások végrehajtásakor megértse, hogy minden hogyan befolyásolja mindent.
Legyen óvatos és ellenőrizze ismét. Tesztelje, érvénytelenítse, végrehajtja. És ismét a folyamatos felügyeleti és teljesítményjavító programok felépítésének kérdésével foglalkozunk. És ez valójában az utolsó dia. Miközben erről a bonyolultságról beszélünk, és ez gyönyörű bonyolultság, akárcsak az óra belseje, oly sok mozgó darab van a PeopleSoft-be. Mindegyik dolog egészre és a felfelé és lefelé hatással van. Olyan sok olyan helyen található, ahol kulcsot kereshet a teljesítmény problémájához, amelyek könnyen eltévedhetnek a megfelelő eszköz és a megfelelő folyamat nélkül. És mindent megismételve, sok esetben azt gondolom, hogy megtanultuk, hogy elháríthatja az infrastruktúrát, de a hatalmas változó lesz az Ön egyedi alkalmazáskódja. Ezért kulcsfontosságú a megfelelő folyamatok gyakorlása az alkalmazáskód tesztelésére és folyamatos fejlesztésére.
És tehát ez a részem vége, és ezt Billnek adom át.
Eric Kavanagh: Rendben, Bill, hadd adjak neked a WebEx kulcsait itt. Tetszik ez a gyönyörű komplexitás - ez egy szép. Van néhány nagyon jó idézetted, Matt. Oké, Bill, vedd el. Ha meg akarja osztani a képernyőjét, lépjen a „gyors indításhoz”. Csak te.
Bill Ellis: Köszönöm, Matt, és köszönöm, Eric. Csak megerősítésként láthatják most a képernyőmet?
Eric Kavanagh: Igen, valóban.
Bill Ellis: Tehát az IDERA Precise for PeopleSoft termékéről és annak láthatóságáról fogunk beszélni, amely segítséget nyújt Önnek a komplex alkalmazáscsomag kezelésében. A nehézségek megoldásának egyik módja az, hogy egy alkalmazás, legalább hat technológia, számos végfelhasználó, és ez még az egyszerű kérdések megválaszolását is megnehezíti. Probléma van a végfelhasználóval? Ki a végfelhasználó, mit csinálnak, mi a fő oka?
Amit általában látunk, ez a helyzet - és ez vonatkozhat a PeopleSoft-ra, valamint más alkalmazásokra vagy a PeopleSoft-re más alkalmazásokkal kölcsönhatásba lépve - az adatkészletben található, vagy manapság felhő lehet a felhő, a végfelhasználót nem igazán érdekli az összetettség. Csak be akarják fejezni a tranzakciót, a megközelítéseket, a leltárkeresést, a jelentési időkártyát, az ilyen típusú dolgokat. Ha a dolgok lassúak vagy nem állnak rendelkezésre, ezeknek az intelligens, jó szándékú embereknek általában nincs tudomása, amíg a végső felhasználó panaszkodik.
Ez egyfajta láthatósági rés van ott, és akkor mi történhet, az elindíthat egy időigényes és frusztráló folyamatot, ahol az emberek megnyithatnak egy szerszámot, és sajnos csak az alkalmazáshalom egy részletét tekintik meg. Tehát továbbra is megmaradnak az alapvető kérdések megválaszolásának nehézségei.
Sokszor előfordulhat, hogy probléma van, és elmegy a WebLogic adminisztrátorához, aki azt fogja mondani: „Nos, a memória, a szemetes gyűjtemények mindegyike nagyon jól néz ki. Nem igazán hiszem, hogy ez a WebLogic. ”Megy a DBA-rendszergazdához, és azt mondják:„ Nos, az adatbázis, ugyanúgy fut, mint tegnap. Az első tíz jól néz ki. Lehet, hogy a tároló adminisztrátora olyan mutatókkal talál meg téged, mint például a másodpercenkénti I / O vagy átviteli sebesség, amelyek keretszintű metrikák és esetleg nem tükrözik az adott alkalmazást, még kevésbé az adatbázist vagy az adott folyamatot.
És tehát mindegyikük rendelkezik ezekkel a mutatókkal, amelyek látszólag azt mutatják, hogy a probléma máshol van, mégis ennek a végfelhasználónak van problémája, vagy bejelentett egy problémát, de hogyan tudjuk ezt jobban megoldani? És a jobb módszer, hogy a pontos módszer - vagy ez az egyik mód, amelyet kínálunk - a felhasználói tranzakciók mérése a böngészőből a hálózaton keresztül, a webszerverre, a Java Joltra, a Tuxedóra, az adatbázisba, beleértve a DB2-t is. majd végül a tárolásba.
És ezt megmutatja, hogy a teljes idő azt mondja: „Nos, ki okoz problémát?” És akkor meghatározzuk a végfelhasználót az alapján, hogy miként írták alá a PeopleSoft-ot, és a Tuxedo fordítás segítségével felvehetjük azt is, amit a PeopleSoft panelek végrehajtanak.
Tehát az időzítéseket bevezetjük egy történelmi tárolóba, amelyet teljesítménymenedzsment-adatbázisnak nevezünk, és ez egyetlen zeneművé válik, amely nagyszerűsíti a ki, mit, mikor, hol, miért. A pontos javaslatokat is tartalmaz. Valószínűleg a legfontosabb, mert az összes információt állandóan rögzítjük - mind a műszaki informatikai személyzet szintjén -, hogy meg tudja mérni az előzőt és utána. Tehát méréssel vagy Six Sigma-val hozhatja a teljesítmény teljes működését.
Tehát vessünk egy pillantást az „egy napra az életben”. Először is előfordulhat, hogy megnyitja a Pontos riasztás képernyőt, és itt fog figyelmeztetni. A legfontosabb riasztás az, ha tevékenységi riasztások vannak. Tehát a felhasználók tranzakciókat folytatnak, és alapvetően nem teljesítjük SLA-kat. Hasonlóképpen van egy állapotunk, amikor rendelkezésre állunk - és ez alapvetően azt jelenti, hogy alkalmazásinfrastruktúránk egy része nem érhető el -, így belefúrhatunk és valójában láthatjuk, hogy a Tuxedo példányai milyen formában vannak, és valójában láthatjuk, hogy az egyik példányok nem megfelelőek. Az összes tevékenységet erre az egyetlen példányra tolják, és ezzel foglalkoznia kell. Alapvetően szűk keresztmetszetet teremtettünk.
Most, mint dolog, az erre futó tevékenységhez valójában megismerkedhet azzal a megállapítással, hogy annak ellenére, hogy van ez az általános infrastrukturális probléma, van mód a feldolgozás hatékonyságának javítására az adott JVM for WebLogic számára. És itt van ez egy igazán fontos dolog: Sokszor az emberek mozognak, mint egy felhőbe, és azt mondják: "Nos, mennyi CPU-ra és mennyi memóriára van szükséged?"
Nos, az érme kapacitásaként ismert másik oldala a feldolgozási hatékonyság. Ha kevesebb memóriát, kevesebb processzort használok, egyszerűen nem kell annyira. És mint Matt korábban mondta, minden valamilyen kapcsolatban áll. Most már tudom megnyitni a PeopleSoft tranzakciós képernyőt, és a képernyőn az y tengely a válaszidő, az x tengely a napi idő.
Van egy oszlopdiagramon, amely megmutatja az ügyfél idejét. Valójában ez a böngésző, a webszerver. A zöld a Java idő, a rózsaszín a Tuxedo, a sötét kék az adatbázis idő. Ez a profil nem önmagában történt meg; ez történt az egyes PeopleSoft panelek miatt - végrehajtották őket, és válaszidővel mutatják be nekik. Valójában megtalálható az alkalmazás minden lépésének ütemezése, valamint egy veremtábla, amely az alkalmazást itt panelenként mutatja. Emellett képesek vagyok fúrni és megtalálni egy adott felhasználót, vagy rangsorolni a felhasználóimat.
Ez a képernyő lehetővé teszi, hogy bejelentkezési név alapján meghatározzam egy adott felhasználót. Gondolj arra, milyen figyelemre méltó vagy milyen erős ez. Sokszor nem csak az infrastruktúráról és annak felállításáról szól, hanem arról is, hogy a végfelhasználók hogyan használják a rendszert. Lehet, hogy új bérleti díja van, vagy valakinek van új munkalehetősége: Lehet, hogy nem tudja, hogyan kell az alkalmazást helyesen használni. Ez valójában elősegítheti a képzési lehetőségek azonosítását.
Az érme másik oldala az, ha egy adott felhasználóra tudok összpontosítani - itt a felhasználót vizsgálom az adott tranzakcióikban és a tapasztalt válaszidőben -, közvetlenül tudom kezelni egy adott felhasználó felhasználói élményét. felhasználó. Ez már nem a rendszerszintű általános mutatókról szól, hanem a végfelhasználói élményről, és ez nagyon erős. A környezet egy része természetesen belső lesz, HR, stb. Vannak olyan részek is, amelyekkel az ügyfelek szembesülnek. Akárhogy is, a lehető legjobb, legtermékenyebb vevői élményt szeretné biztosítani.
Most egy adott panelnél bemehetek és fúrhatnék a kérdéseket. Tehát ez egyfajta mély merülés, amelyet meg tudunk tenni annak érdekében, hogy felfedezzük, mi történik, és ezt a mély merülést megtehetjük még mielőtt felhívnánk egy végfelhasználót, vagy ha a végfelhasználó felhívta Önt, akkor kezdeményezhet egy folyamatot a mondjuk: „Nos, pontosan hol van a kiváltó ok?” És ez nem lesz olyan, mint a CPU kihasználtsága és felülbíráló, hanem az alkalmazáskódnál lesz, amelyet gyakorolnak.
Vizsgáljuk meg a tartalomkezelést, és valóban megnézhetjük a tranzakció elemzését: indítsuk el a böngészőt, lépjünk be a webszerverre a Java Jolt alkalmazásba, és valójában megjelenítjük a kódot, amely végrehajtja a Szmoking panel, végül az SQL utasításhoz, ahol a Precise az SQL utasítás szövegét tárja fel, amelyet az adott PeopleSoft panel futtat.
Mindenkinek, akivel beszélünk, rendelkeznek eszközök, de nincs kontextusuk. A pontok összekapcsolása vagy a tranzakció követése a böngészőből egészen az SQL utasításhoz kontextus. Ez mit jelent, mint például a DBA, az, hogy inkább a példák vagy az adatbázis szintjén vizsgálja meg a dolgokat, most SQL utasítás szintjén tudom vizsgálni.
Tehát azt mondhatom: „Nos, mi akadályozzák az egyedi SQL utasításokat”, és ez rendkívül nagy teljesítményű. Vegye figyelembe, hogy ez a tranzakció nem haladhat meg gyorsabban, mint az SQL utasítás, és minden jelentős üzleti tranzakció kölcsönhatásba lép a rekordrendszerrel. Az adatbázis, akár tetszik, akár nem, a teljesítmény alapja, és ha annyira finom vagyok, hogy az üzleti tranzakció szempontjából elengedhetetlen egyes SQL utasításokra tudok összpontosítani, valóban átvinnem a játékomat a következő szintre.
Egy másik dolog, amelyet itt észrevehet, egy olyan százalékos hozzájárulás kiszámítása, amelyet a Precise nyújt. Maga a böngésző valójában az alkalmazáscsomag jelentős része. JavaScript végrehajtása van, renderítési ideje van, oldal-összetevők, GIF-ek, JPEG-ek vannak. És valóban azt tapasztalja, hogy az alkalmazás nagyon eltérően viselkedik a Chrome, szemben az IE és a különböző verziókkal. A pontos tudni fogja ezt mutatni Önnek is, és előfordulhat, hogy a böngészőben valójában szűk keresztmetszet vagy vita merül fel, ami a képernyő lefagyását okozhatja.
Az a képesség, hogy azonosítsa azt, amely lehetővé teszi az informatika számára, hogy nem a megfelelő fát ugatja fel, hanem kezelheti a felmerülő különböző kérdések alapvető okait. Most azt tudom megtenni egy adott SQL utasításhoz, majd pontosan elemezni tudom, mi történik az SQL utasításon. Tehát itt az adatbázis-szakértő nézethez jutottunk.
Az egyik pont, amely megkülönbözteti a pontosságot az adatbázis szintjén, az, hogy másodpercenként alkotunk mintát. Ez összehasonlítva a versenytársainkkal, amelyek csak tízenként, 15 percenként egyszer néznek ki. Annak érdekében, hogy a részletesség, a felbontás szintje nagyságrenddel jobb, mint a versenytársaink.
És ismét, mivel az adatbázis az alapítványunk része, megengedjük, hogy az Ön DBA-ja valóban a következő szintre emelje teljesítményét. Tehát látom, hogy ez az SQL utasítás ténylegesen 50 százalékot költött, ha ideje gyakorolni a tárolt alrendszer elérését, ideje 50 százalékát a CPU segítségével. Kattintson a dallam gombra, majd bemegyek és részletesebben kidolgozzam a végrehajtási terveket és pontosan mi vezette ezt a használati szokást.
Most árajánlatunk egyik ügyfelünktől - ha nem voltak az Oracle Shop-ban, akkor az Oracle eszközt használják, az OEM nevű és az OEM valóban egyfajta adatbázisra vagy példányra összpontosítva - a DBA-k folyamatosan vizsgálják, hogy mi a top 10 lista? De a Precise segítségével összekapcsolhatjuk a pontokat az egyes SQL utasításokkal, és így a granularitás lehetővé teszi a DBA számára, hogy valóban beállítsa a tranzakció szintjét, és nem csak a sokkal magasabb adatbázis szinten.
A második pont, amely nagyon fontos volt ezen ügyfél számára, az, hogy a pontos, ha lefordítja egy bonyolult URL-jét PeopleSoft panelenévé - ha informatikus vagyok, és fakezelőről, tartalomkezelőről, egy adott HR oldalról tudok beszélni, így az a személy, akinek segíteni próbálok, tudja, hogy valóban keresek és megértem, mit néznek, mert már nem ezek a hieroglifák, hanem a neve, amelyet ismernek.
Az egyik feltett kérdés - ez mindig is úgy tűnik, ezért gondoltam, hogy csak proaktívan válaszolok meg a kérdésekre - hogyan rögzíti a világon azt a PeopleSoft felhasználói azonosítót? Hadd menjek át a lépcsőn. Itt van egy PeopleSoft bejelentkezési képernyő. A hozzáféréshez meg kellett navigálnom a webszerveremre, és ez a képernyő jelenik meg. Ha az alkalmazás műszerezésekor a Precise készüléket használja, ez a képernyő valójában tartalmaz egy pontos szkriptet, és jobb kattintással megnézhetem a forrást. És ez valóban megmutatja nekem azt a kódot, amely alátámasztja az oldalt, és itt az oldalkeretben valójában a Pontos webkód, és ez lehetővé teszi számomra a bejelentkezési képernyő, az IP-cím, a böngésző típusa, az egész rengeteg információ a megjelenítésről és a valódi végfelhasználói élményről. És tehát amikor beteszem a felhasználónevemet és kattintva jelentkezem be, akkor a Precise meg tudja mérni, mit csinálok.
Megnyílok, megyek a fakezelőhöz, keresési műveletet akarok végrehajtani, kitölteni a mezőt, és rákattintom a keresésre. Az eredménykészlet bemutatásra kerül nekem, tehát egyértelműen átjutottam az egész alkalmazáscsomagot egészen az adatbázisig. Hogyan mutatja ezt a Precise? Menjünk előre, és nézzünk meg. Nyisd meg pontosan, bemegyek, látom a tevékenységet, rákattinthatok a tevékenység fülre, amely megjeleníti ezt a képernyőt. Ezek a nem fordított URL-ek. Meg tudom mutatni a felhasználókat, és itt van a felhasználói azonosítóm, amelybe éppen bejelentkeztem, és itt van a tevékenységem.
Láthatta, hogy a Firefox 45-ös verzióját használtam felhozni ezt. Az alkalmazást 12 alkalommal gyakoroltam, és alapvetõen az elhagyás az, amikor valaki elhagy egy weboldalt, még mielõtt teljes mértékben megjelenne, ami üzleti kérdést vet fel. Szóval így tudtuk felvenni a végfelhasználói azonosítót. Nagyon szép, az emberek igazán értékelik, ha pontosan tudja, mi történt.
Most egy kicsit furcsát akarunk váltani. Később megvizsgáltuk a tranzakciót. Mélyre merültünk egy adott tranzakcióval és megvizsgáltuk az SQL utasításokat. Most át szeretné váltani a sebességváltókat, és megnézném a PeopleSoft alkalmazáscsomag többi technológiáját, a WebLogic-től kezdve.
Tehát itt van egy WebLogic példány, és láthatja a tevékenységet az idő múlásával. Van pénzügyi jelentése. Azt mondja nekem, hogy közvetlenül a denevérről van szó, a memória maximálisan felhasználásra kerül. Az egyik dolog, amit találunk, hogy a legtöbb ember a teljes alkalmazáscsomagot vagy legalább egy részét megosztott környezetben futtatja, gyakran VMware. Meg kell egyensúlyoznia, hogy mennyi erőforrást igényel, és mennyit igényel. Nem akarsz erőforrás disznó lenni. Hasonlóképpen, ebben az esetben nem akarja megtenni a feldolgozási korlátozást azáltal, hogy nem kér elegendő memóriát.
A konfiguráció elengedhetetlen a teljesítmény menedzsmenthez is. Tehát bejuthatunk a memóriaszemét-gyűjtésbe és a JMX WebLogic összes számlálójába, így pontosan ismerem a WebLogic-formám egészségi állapotát.
Most Tuxedóba. Számos üzlet szmokingja egyfajta fekete doboz, és ez a PeopleSoft nagyon fontos része. Ez egy olyan ragasztó, amely mindent összetart, így szinte gondolok rá, mint az operációs rendszer kiterjesztésére. Ezt nagyon óvatosan használja és konfigurálja. Egyébként - ez egy kis mellékmegjegyzés - a nyitó megjegyzésekben Eric megemlítette a „sürgősség zsarnokságát”, és azt hiszem, hogy ez tényleg akkor jön létre, amikor a PeopleSoft üzletek fontolóra veszik a klasszikus felhasználói felületről a folyékony felhasználói felületre való áttérést, mert úgy találja, hogy a görbe mögött áll annak oka miatt, ahogyan a folyékony felhasználói felület gyakorolja a PeopleSoft környezetet.
Most problémái vannak a WebLogic, a Tuxedo, az adatbázis és az itt található tárolóhelyen, csak azért, mert a HTML5 hatalmas mennyiségű üzenetkezelést nyújt. Valószínűleg legalább tízszerese annak, amit a klasszikus felhasználói felület tesz, és hogy a további üzenetküldés további forgalmat jelent. Tehát a Tuxedo konfigurációját módosítani kell a kiegészítő forgalom befogadására. Néhány dolog ennek a képernyőnek a vége, a jobb oldalon vége. Van időbeli grafikonok a súlyozott válaszidő, az átlagos válaszidő és a végrehajtás számához.
Itt van információ a környezetben található összes Tuxedo-domainről. Felosztottuk a szolgáltatásokat, a felhasználókat, a szerverfolyamatokat és az IP-ket. Ezt át tudom változtatni a végrehajtás számlálására, és csökkenő sorrendben mutatom be, így látom, hogy mi kerül végrehajtásra a leggyakrabban. Le tudok gördülni a domének felfedéséhez is; a legtöbb embernek több domain van a környezetében, hogy alapvetően eloszlassa a tevékenységet, és tudom beállítani az SLA-megfelelést, ezért figyelmeztetést adok a Tuxedo rétegre.
Ha sorban áll, akkor különböző problémák merülnek fel a konfiguráció miatt. Általában - mivel globális a hatása - általában nem fog változtatásokat végrehajtani menet közben. Azt szeretné, hogy fokozatosan fokozza a rendszert a minőségbiztosítási folyamat részeként, amely visszatér arra a pontra, amelyet Matt már korábban megfogalmazott a teljesítmény korai kérdéseivel kapcsolatban. Sokkal jobb, ha a konfigurációnak helyesnek kell lennie, ha termelésre megy, nem pedig termelésre, és kiderül, hogy a konfiguráció nem felel meg a használati szokásoknak. Nagyon szeretem a bevezetést, amelyet Eric és Matt ma nyújtottak be. Gondoltam, hogy valóban megcélozták azokat a kihívásokat, amelyekkel szembe kell néznie a PeopleSoft környezet kezelésében és fejlesztésében.
Ezt már egyszer mondtam - azt hiszem, érdemes újra megmondani: Minden jelentős üzleti tranzakció kölcsönhatásba lép az adatbázissal. Tehát vizsgáljuk meg, hogy a Precise hogyan nyújthat további információkat. Itt van egy adott Oracle példány. Ugyanaz a pontos megközelítés, mint amit láttunk - az y tengely a végrehajtási idő, az x tengely a napi idő, de a verem oszlopdiagramjai az Oracle-en belüli végrehajtási állapotok. Ez megmutatja nekünk, hogy milyen korlátozások vannak a rendszerre. Itt van egy ténymegállapítási jelentés, amely azt mondja nekem, hogy megvan ez a nagy redo napló puffer.
A PSVersion ezt a választott verziót is megnézem. Valójában sok erőforrást fogyaszt. Mellesleg, mivel mintavételt készítünk, és ezen nagy felbontású képet nyújtunk arról, hogy mi történik a rendszeren, akkor meglepődhet, mi a valódi erőforrás-fogyasztó a rendszerben, mert ha csak 10 percenként keres, akkor nem megmutatom neked, hogy mi az erőforrás-fogyasztó. És tehát azzal, hogy megtudja, mi az igazi erőforrás-fogyasztó, valójában a szűk keresztmetszeteken vagy a rendszeren kezelheti a valódi feldolgozást.
Most itt átugrottuk a tevékenység fülre, és ez a tevékenység. Láthatjuk, hogy a CPU-t, a tárolási alrendszert, az alkalmazás zárolását, az operációs rendszer várakozásait, a RAC-ot, az átadást, az Oracle szervert, a kommunikációt és a belső aggregátumot vizsgáljuk együtt. Ez az y tengely, ez a teljes végrehajtási idő.
Itt találhatók az a SQL utasítások, amelyek ezt a profilt vezetik, és az egyik látott dolog az alacsony késleltetés - két milliszekundum, de csaknem 4500 végrehajtással azt jelenti, hogy az SQL utasítás valójában az első számú erőforrás-felhasználó a rendszerén, és ez jó tudni. Ugyancsak nem várakozás zárakra vagy várakozásra. Az idő 100% -át használja a CPU-t. Ez nem azt jelenti, hogy nincsenek dolgok, amelyeket nem tehetek. Sok mindent megtehetek, ha tudom, hogy milyen SQL utasításokhoz és objektumokhoz férnek hozzá. És tehát ezek csak néhány módon segíthetnek.
Itt van ez a kidolgozás, és ez az egyes PeopleSoft-programok összefüggésében hozhat minket, és ezek a programok különféle célokat szolgálnak a PeopleSoft-en belül. Valójában az adatbázis szintjén kezdheti meg foglalkozni az alkalmazás használatával.
És ha kiválasztom egy adott programot, elkülöníthetem a program által benyújtott SQL utasításokat, így nagyon alkalmazás-orientált vagyok, és nem az adatbázis-technológiára összpontosíthatom, amikor alapvetően az adatbázis optimalizálását és az adatbázis-konfigurációt keresek. Csak fel akarom hívni erre a figyelmét. Gyakran sok nagy szervezet fel van osztva infrastruktúra-DBA-kra és alkalmazás DBA-kre. Pontos, ha megmutatjuk az alkalmazást és az erőforrás-felhasználást, valójában képesek vagyunk áthidalni a rést, és ez a megoldás hasznos mindkét típusú up DBA-nál a rendszeren.
Ez a rész valóban azt mutatja be, hogy mit tehetünk az adatbázis szintjén. És ami itt történt, az volt, hogy egy képernyő lefagyott, volt egy választás a PS_Prod közül, és amit csináltunk, akkor rákattintunk erre a dallam gombra, és mi ez, az hozza minket ebbe az SQL munkaterületbe. Most azoknak az embereknek, akik nem DBA-k, ez valószínűleg nem tűnik igazán izgalmasnak. Azok számára, akik DBA-k, valószínűleg ez nagyon izgalmas. Amit itt mutatunk, az adott SQL utasítás időtartama a rendszer változásaival szemben. És ez azt mutatja, szerdán, csütörtökön, pénteken, az időtartam kb. 2/10 másodperc. Szombaton és vasárnap ez a cég nem működik - szerencsés nekik. Gyere hétfő, változás történt: Megváltozott a hozzáférési terv. Az új hozzáférési terv hirtelen felfelé halad. Ez valójában elég lassú, és a képernyő lefagy.
Most, ha DBA vagyok, további információra van szükségem, hogy megismerjem a valódi kiváltó okot. Tudnom kell a választott adatbázis-optimalizálót. Tehát a Precise ezt az összehasonlítást kínálja, amely megmutatja a gyors és hatékony végrehajtási tervet, amikor a dolgok jól működtek, valamint a végrehajtási tervet, amely lassú és nem hatékony. Ez a szűrőcsatlakozás általános a DBA-k számára, amelyek a PeopleSoftot futtatják. Amit a szűrő végzi, úgy néz ki, hogy egy sor minden egyes sora megnéz, az összekapcsoló táblázat minden egyes sorát megvizsgálja - ez sok CPU-t igényel. Rendkívül nem hatékony, mivel nem csak a szükséges sorok részhalmazának a szűrését szűrjük, hanem az SQL utasítás és ez a hatékonyság a lassabb végrehajtási időt eredményezi. Ezért végül lelassítják a PeopleSoft panelt a képernyő befagyasztása során, és a Precise sikerült elérni azt az igazi okot, amelyről soha nem tudhatna, hacsak nincs olyan eszköze, amely felfedi az alkalmazáskódot, az SQL utasításokat és így tovább.
Ez volt a mély merülés. Most tovább emeljük a képet a műszerfal 10 000 négyzetláb nagyságára. Pontosabban: az irányítópultok valójában nem a műszaki csapatnak szólnak - valójában az, hogy információt osszon meg műveletekkel, talán az alkalmazási csoporttal, talán a parancsnoklánccal. És így egy műszerfalkészlet megjelenítheti a PeopleSoft paneleket és az ügyfélidejét, így tudhatja, mi a végfelhasználói élmény. Lehetséges, hogy egy másik műszerfal konfigurálva lett a műveletekhez, és ez az irányítópult megnézheti, hogy vannak-e riasztások? Valójában riasztások vannak az operációs rendszer, a web, a WebLogic, a Tuxedo és az adatbázis szintjén. Nincs riasztás itt, átlagos válaszidő. Láthatjuk, hogy a második kb. Itt ténylegesen megnézem az infrastruktúrámat, és megmutatom nekem a környezetben lévő összes virtuális gépet, és elkezdem kezdeni a feldolgozást, a terheléselosztást, és megnézem a Tuxedo domainjeimet is. Ebben a környezetben hat különböző domain van, tehát látom ezeket a területeket, és valóban bele tudok lépni a webes egyensúlyba.
A Precise történelmi adattárában, a PMDB-ben, a teljesítménykezelési adatbázisban rengeteg metrika található. És néha valaki meg akarja tudni a böngésző hozzáférési számát, vagy megteheti a hozzáférés számlálóját a böngésző típusa szerint, vagy a teljesítményt a böngésző típusa szerint. Egy csomó dolgot lehet tenni a rendszer további láthatóságának biztosítása érdekében.
Ez a, valójában a WebLogic memóriahasználatát vizsgálja, és látja ezt a szép fűrészfog-mintázatot, a memóriahasználatot. Ott van a hulladékgyűjtés, beolvassa a hivatkozásokat. Visszamegy felfelé, és így ez egy nagyon szép minta, amelyet szeretsz látni. Tehát ez egyfajta nézetet nyújt a PeopleSoft környezetre, mint alrendszerek gyűjteményére, és ez megfelelő lenne a műveletekhez. A legalapvetőbb kérdés: „Nos, mi történik a szerveren?” A precíz mindezen láthatósággal rendelkezik. Ezenkívül kiszolgálói mutatókat is biztosít. Tehát itt valóban meg tudja mérni a CPU-t, a memóriát, az I / O-kat, a szervert, a rendszer felhasználóit, és így teljes láthatóságot élvezhet. És ez a módja - a hosszú távú trenddel kombinálva -, hogy az emberek miként használják a Precise-t a kapacitástervezéshez.
És csak egy kis hangot akarok oda dobni oda. Általában egy üzletnek annyi költségvetése van a hardverre, a szerverre, és a költségvetés a személyzetre. Hogyan fogsz befektetni, hová fogod tenni a tétet? A Precise használatával előnyt kap, mert látja, hogyan kell használni a tárolási alrendszert. Ha sok véletlenszerű I / O-t csinálsz, akkor a Precise ezt megmutatja. Ez segíteni fogja a szilárdtestalapú tárolásba való beruházás igazolását. Ez fontosabb lehet üzlete számára, mint kiegészítő CPU vásárlás, ha a CPU kihasználtsága alacsony.
Befektetni szeretne ott, ahol a valódi feldolgozási szűk keresztmetszetek vannak, ahol valóban megtérülhet. És azáltal, hogy pontosan foglalkozik mindennel, az alkalmazáskód-feldolgozási hatékonyságtól egészen a kapacitástól kezdve, lehetővé teszi, hogy felmérje és dokumentálja, hol vannak ezek az igények számokkal.
Most az utolsó darab figyelmeztet, és a riasztás valójában így kezdődött. Emlékezz arra? Láttuk a figyelmeztetést, hogy van egy teljesítmény SLA, és láttuk, hogy egy WebLogic példány nem működik. Vessen egy pillantást a riasztási felületre. És ismét, mi történik? Az egyik dolog, amelyet rá szeretnék emelni erre a nézetre, hogy a Precise nemcsak ezeket a teljesítményriasztásokat és állapotfigyelmeztetéseket tartalmazza a rendelkezésre állásról, hanem trendkapcsolatos riasztásokkal is rendelkezik. A trendfigyelmeztetéseknek az a fontos oka, hogy ha a rendszer tétlen vagy egy vagy két felhasználóval rendelkezik, akkor valószínűleg a dolgok jól működnek. Csak akkor, amikor elkezdi hozzáadni a felhasználókat, és egyre több tevékenységet kezdenek elvégezni, elkezdi az adatok, a Tuxedo szintű erőforrások, a WebLogic szint, a hálózati és az adatbázis szintű erőfeszítéseit. Ez a vita a teljesítmény romlását eredményezi, és végül átléphet egy sort, és ez egy teljesítményriasztás, és ez alapvetően nem teljesíti a szervezet SLA céljait. És tehát ezek a figyelmeztető jelzések nagyon szépek.
A webszint, a bal oldalon, a webszint valójában a végfelhasználói élményt méri, majd bejut a technológiákba az alapul szolgáló alkalmazáscsomagban. Ez egyfajta építészeti képernyőn látható, hogyan csináljuk mindezt. Ideális esetben szeretne egy pontos kiszolgálót, amely független a megfigyelt környezettől vagy környezetektől. Egy pontos kiszolgáló számos alkalmazást képes kezelni.
A PeopleSoft, az Oracle és a DB2 adatbázishoz helyi ügynököt igényelünk. Ha a PeopleSoft környezetet az SQL Server védi, akkor lehetősége van arra, hogy ügynököket csináljon. A Sybase-hez ügynökök is vannak. Biztonsági modellünk középpontjában az áll, hogy itt gyűjtik az adatokat, míg a Precise felhasználói hitelesítik a Precise-t. Teljesen különálló folyamatok, külön hitelesítő adatok, külön hitelesítés, és így ez a biztonsági modellünk része. És vannak további részletek.
Úgy gondolom, hogy ez egyelőre elegendő bevezetés az építészetbe. Ha bármilyen kérdés merül fel, kérjük, tegye fel őket, ahogy Eric említette.
Csakúgy, mint egy gyors visszatérítést, ezt a megoldást a gyártás során a 24 és 7 közötti méretre tervezték. Nagyon ajánlott, hogy minket használjon a minőségbiztosításban. Ha házon belüli fejlesztést hajt végre, kezdje el felhasználni minket a fejlesztésben. A bonyolult URL-t, URI-t lefordítjuk a PeopleSoft panelenévé. Amikor a termelésről beszélek, akkor rendkívül alacsony a fejünk, tehát láthatósága van, mindig tudja, mi történik, azonosítja a végfelhasználót.
Nem kellett bemennem és meghatároznom ezeket a tranzakciókat - csak természetes kapcsolódási pontok vannak a böngészőből, az URL, a belépési pontok, a webszerverhez való kapcsolódás a WebLogic-ba, a meghívási környezet lefelé, amely az SQL utasítást tartalmazza. Akkor képesek leszünk rögzíteni az SQL utasítást és azt, amit csinál. A precíz az adatbázis-intelligens, és azt hiszem, ez megkülönböztető tényező számunkra, és lehetővé teszi a DBA számára az együttműködést, az alkalmazások láthatóságának javítását.
A végső pont az, hogy mindig vagyunk, mindig gyűjtünk, bármikor mérhetjük a fejlesztést, előtte és utána, és számszerűsíthetjük azt, vagy abban a ritka esetben, ha megváltoztatta a teljesítményt, ezt tudná, és el is dobhatja. azonnal vissza. A legtöbb versenytársunk azt teszi, ha további információkra van szüksége, akkor be kell kapcsolnia a további láthatóságot, és általában az, hogy a további láthatóság sok fölöséget jelent. A Precise segítségével mindig látható vagy, és mindig meg tudja oldani a problémát. Tehát ha a Precise webhelyre látogat, kérjük, ellenőrizze a Precise termékeket, függetlenül attól, hogy az Precise for Oracle. Pontos alkalmazásteljesítmény-platformként szerepelünk, és van egy gomb a demó igényléséhez.
Valójában, ha megosztom a képernyőmet, azt gondolom, hogy csak navigálhatnék oda, hogy megmutassam Önnek, hogy néz ki, csak hogy láthassa ezt előtte. Itt található az IDERA webhely. Ön megy a termékekhez. Bármelyik ilyen precíz komponens közül választhatok, és csak működés közben szeretném látni. Ez megkezdi a további információk megosztásának folyamatát, amely fontos lehet az Ön webhelyén. Vagy ha többet szeretne tudni a folyékony felhasználói felületre történő migrációról, kérjük, vegye fel velünk a kapcsolatot.
És erre, Eric, szeretném átadni neked a botot.
Eric Kavanagh: Rendben, jó üzlet. Még egyszer el kell mondanom - meglehetősen átfogó és lenyűgöző bemutató ott, Bill. Ön egy egész csomót említette, amiről szeretnék kérdezni. Nincs sok időnk - körülbelül kilenc perc -, és szeretném, ha Matt kapna egy esélyt egy pár kérdés feltevésére, és legalább egy vagy kettő van a közönségből.
De megemlítettél egy olyan véleményt, amely nagyon-nagyon érdekes abban a tekintetben, hogy a Precise hogyan tud segíteni az IT-csapat beszerzésében, mert rámutathat arra, hogy megteheti az ügyet annak, aki ezt a döntést hozza, hogy amire szüksége van, szilárdabb állapotú például tárolás, vagy amire szükséged van a hálózat fejlesztése, vagy bármi is legyen. De ez nagy ügy. Gyakran látja a vállalatokat, hogy felismerik ezt, és ezt használják, vagy még ennél is többet próbálnak evangelizálni?
Bill Ellis: Nos, valójában mindkettő, és az a lényeg, hogy a használati szokások, még olyan csomagkezelő alkalmazások esetében is, mint például a PeopleSoft, a felhasználási minták minden webhelyen különböznek. Szerencsém volt egy PeopleSoft migrációt végrehajtani egy banknál, és a bankok nagyon eltérően használják a főkönyvi rendszert, mint a legtöbb szervezet. Lehetséges, hogy egyedi tranzakciókat is végrehajtottak, amelyeket fióktelepen hajtottak végre, mindegyiküket a főkönyvbe utalják.
És így ahelyett, hogy több tucat vagy száz főkönyvet feladna, valójában százezrek fekszik. Tehát így bekapcsolódtam a Precise-be a használati szokások miatt, és ez lehetővé tette számunkra, hogy foglalkozzunk, de az alkalmazás igényeinek mind kódszintű, konfigurációs szintű, valamint infrastruktúra-szintűek. Szóval abszolút nagy hívő vagyok, és ezt is evangelizálni akarom, mert nem kellene a hardver döntéseket egyszerűen a felhasználás alapján meghoznia. A környezet igényeire kell alapoznia.
Eric Kavanagh: És van egy kérdés egy résztvevőtől, majd Matt, megválaszolom neked egy vagy két kérdést. Nos, ez jó és vicces, mert nagy, hosszú választ adhat. A résztvevő azt kérdezi: „Hogyan gyűjthet teljesítménymutatót a felhasználó végén a telepítés után és a tesztelés során?”
Azt hiszem, nagyon jó munkát végzett azáltal, hogy belemerült a teljesítménymutatók mélységébe és gazdagságába. Ezen dolgok némelyikében még a másodpercről is beszéltél, minden öt vagy tíz percre vetítve. Ekkor fogja megkapni a szükséges részletességgel a válaszokat, ugye?
Bill Ellis: Igen, tehát döntő jelentőségű az, hogy a teljesítményinformációk gyűjtői technológián alapuljanak. Tehát, amikor telepítünk, tudnunk kell az alkalmazásköteg felépítését, kezdve az operációs rendszerrel, annak verziójával, a Tuxedo, a WebLogic melyik verziójával, a People eszközök milyen verziójával.
És valóban az ügynökök tervei teszik ezt, az adatgyűjtés lehetővé teszi számunkra, hogy felfedjük, hogy a precíz láthatósági szintet biztosítja. És ez a láthatóság, azt hiszem, néha kissé megfélemlítheti az embereket. De ha a cél az, hogy valóban bejuthasson és javítson a dolgokon, és a teljesítményt 11-re tegye, akkor ez valóban olyan láthatósági szint, amelyet szeretne. És ha a Precise képes biztosítani, és alacsony az általános költsége, akkor a kérdés az, miért nem? Tehát azt hiszem, hogy ez egy nagy kérdés, és kérjük, vegye fel velünk a kapcsolatot, ha szeretné megvitatni ezt tovább.
Eric Kavanagh: Oké, jó. És Matt, volt kérdése?
Matt Sarrel: Azt hiszem, jól vagyok. Úgy értem, már foglalkoztam azzal, hogy a WebEx itt összeomlik.
Eric Kavanagh: Ó, nem. Pontosnak kell lennünk, hogy pontosan megértsük miért.
Matt Sarrel: Igen, azt hiszem, hogy a kérdésemre, amire gondoltam, miközben beszélgettél, Bill, az volt, ha kicsit megvitathatná arról, hogy miként léphetnek fel több csapat ugyanazon az oldalon, amikor hibaelhárításra kerül sor, mert tudom, hogy ez valami újra és újra felmerül, ki és miért felelős mindenért, hogy együtt dolgozzanak a legjobb minőség biztosítása érdekében az alkalmazottak számára.
Bill Ellis: Igen, így az informatikai személyzet általában drága. A legtöbb üzletben a technológián alapuló csapatokra van osztva, tekintettel a technológia összetettségére. Az egyik nagy dolog, ami történik, egy teljesítmény kérdése, és sokszor a konfliktus, a háborús terem összehívódik. És itt mindenkinek megvan a metrikája, hogy valahogy felmentje a szintjét, mert nincs a kontextus. Nem a tranzakciós kód szintjén, hanem a WebLogic szintjén zajlanak. Vagy inkább az adatbázis szintjén tekintik, nem pedig a tranzakció egyedi SQL utasítását.
És azáltal, hogy pontosan meg tudja határozni a probléma szintjét és a probléma kódját az adott rétegben, az megszabadítja a többi csapatot, hogy ne menjen el, vagy időt töltsön az erőforrásokban olyan problémákat keresve, amelyek nem a területükön vannak. Ha ez adatbázis-probléma, vegye fel a DBA-t az információkkal, amelyekre szükségük van a probléma megoldásához. Örülnek, hogy megteszik.
De hasonlóképpen, ne pazarolja a Tuxedo-t, a WebLogic segédcsapatot, amely az adatbázis problémáira összpontosít. Hasonlóképpen, ha a probléma a WebLogic konfigurációjában van, ne vegye a DBA idejét valamilyen háborúhelyiségbe, hogy megvédje magát. Csak menjen, és javítsa ki a problémát a WebLogic alkalmazásban.
Megállapítottuk, hogy az IT munkatársak az időmegtakarítás miatt értékelik a pontosságot, mivel ezek a háborús helyiségek általában nem szerepelnek az egyes FTE szervezetek ütemtervében. Olyan, mint a kiegészítő idő. Ezért nagyon fontos az a kérdés, hogy hatékonyan tudjuk kezelni ezeket a kérdéseket. És a folyamatos felhasználói felületet elindító szervezet számára az a tény, hogy képes méretezni a termelést és megoldani a termelés során ténylegesen tapasztalt problémáit, nem az egyes alkalmazottak vagy csapatok számára, hanem valójában az informatikai menedzsment számára, mivel igazán rossz hír lett volna. ha vissza kellene gurulniuk. Tehát nagy kérdés, mert nem csak a technológia. Valójában mindig az emberekről szól.
Matt Sarrel: Igaz, ez az emberek és a folyamatok. Igen, ez volt az egyetlen kérdés, amely felvette a bemutató során. Ha vannak mások a közönségből?
Eric Kavanagh: Igen, csak egy utolsóat dobok neked, Bill, és Matt erről röviden beszélt az előadásában. Megkezdtük látni ezt a termést. Még mindig nagyon előretekintő, de a konténerek és a konténerszállítás, valamint a Docker és az ilyen jellegű dolgok használata, mekkora gömbölyű gördítést okoz nektek?
Bill Ellis: Tehát a szó különböző dolgokat jelent, a különböző technológiáktól függően. Tehát fejlesztjük termékeinket annak érdekében, hogy adatbázis-és alkalmazás szintjén gondoskodjunk a konténerekről. És ennek részeként ez az egész környezet, a mozgásokkal, a felhővel, és a felhőn belül működünk. De van egy felfedezési folyamat, és attól függően, hogy hogyan fejlődnek ezek az alkalmazások - beleértve a PeopleSoft-ot is - fejlesztettük megfigyelő megoldásunkat, hogy biztosítsuk a mélység szintjét, amely a múltban ilyen értékes volt.
Eric Kavanagh: Igen. És azt kell mondanom, hogy minden alkalommal, amikor látom ezeket a demokat, csak csodálkozom a meglévő szemcsézettségről, és erre van szükség ahhoz, hogy össze tudjunk alkotni a megértést, és rendelkeznünk kell valamilyen ismeretekkel a normál helyzet körül, mi a szabvány.
És az emberek nagyon sok tartalmat kínálnak körülötte - segítenek az embereknek azonosítani, mi a normális, mi a nem normális. Beszélt például a figyelmeztető riasztásokról, ezek mind olyan mechanizmusok, amelyek segítségével jobban megértsék valami rosszat, valami nem hibát, és természetesen oda kell fúrnod, hogy megtalálja, de az összes adat megvan.
Bill Ellis: Igen, ez egy igazán fontos dolog; Azt hiszem, Matt beszélt erről. Mi a normális? A különböző környezetek normális szintje eltérő. Ha csúcskategóriás hardverrel, Oracle logikával és adatokkal dolgozik, akkor az üzletben szokásos, vagy az üzletben elérhető teljesítmény más lesz, mintha kevésbé erőteljes infrastruktúrán működne. Tehát az első dolog, hogy megtudja, mi a normális, kezdje el kiszámolni az alapvonalat, és így kezdje el innen fejlesztéseket végezni.
Eric Kavanagh: Rendben, ez jó dolog. Úgy tűnik, van még egy utolsó kérdésünk. Csak egy utolsó kérdést vetek fel neked, Bill. Van különbség az SQL és az adatbázis teljesítményének figyelése között rendszerszintű és alkalmazás szintű adatok szempontjából? Mi a különbség az SQL és az adatbázis teljesítményének monitorozása között?
Bill Ellis : Nos, az adatbázisban semmi sem történik, amíg az SQL utasítás végrehajtódik. Az SQL utasítás állítása mi - vezérli a zárolást, a várakozást, az erőforrások állítását adat- és SQL Server-szinten. És tehát ha látom az SQL utasítás vezérlőjét és annak rendszerre gyakorolt hatását, akkor eredményt okoztam; Össze tudom kapcsolni, hogy mi az, amelyet az DBA érdekel, az infrastruktúrával, amivel törődik, amíg nem tudom valóban a legtöbbet hozni a Precise eszközből.
Ha infrastruktúra-DBA vagyok, és olyan dolgokra gondolok, mint például a hasznosítás, akkor valóban olyan széles körű kezeléssel vagyok képes kezelni, ha megnézem az egyes SQL utasításokat, és ténylegesen minimalizálhatom az erőforrásokat. fogyasztás - akár CPU, memória, I / O - képes vagyok ugyanazon érme mindkét oldalát megcélozni.
Eric Kavanagh: Jól van, emberek. Alig több mint egy órát égettünk át. Nagy-nagy köszönet az IDERA barátainknak. Nagy köszönet Matt Sarrelnek, aki ma csatlakozott hozzánk. Mindezeket az internetes adásokat archiváljuk későbbi megtekintés céljából, tehát nyugodtan térjen vissza, és általában csak néhány óra alatt az archívum felmegy. Tehát nézd meg, és csak annyit kell mondanom, hogy szeretem ezt a cuccot, szeretem a Precise-t, szeretem, hogy bejuthassam a gyomra. És nem ismerek semmilyen más eszközt, amely lehetővé tenné az alkalmazás veremének különféle darabjaiba és részeibe való ásást, kivéve azt, amit ezek az emberek az IDERA-ban pontosan használnak.
Ezzel búcsút mondunk önnek, emberek. Újból köszönöm, legközelebb beszélünk veled.
