Elvitel: Rebecca Jozwiak házigazda az adatbázis-hibaelhárítási és hatékonysági kérdéseket tárgyalja Eric Kavanagh és Dez Blanchfield elemzőkkel, valamint Bill Ellis-rel az IDERA-tól.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Rebecca Jozwiak: Hölgyeim és uraim, üdvözlet és üdvözlöm a 2016-os Hot Technologies szakaszt. A mai téma: "Az alkalmazás lassan fut? Ideje pontosítani." És nem tudjuk-e valamennyien túl jól azokat a problémákat, amelyek akkor fordulhatnak elő, ha a cucc lassan fut? Rebecca Jozwiak vagyok, kitöltöm Ericét, aki ma itt új szerepet tölt be. Igen, ez az év forró, és tudod, amikor a technológiáról van szó, amint mondtam, az egyik, amit igazán nem akar, a rendszer bármely részének lassú futtatása. És csak a fogyasztói példa egyfajta felhasználására gondolok: ha van étterme, akkor nem számít, mennyire jó az étel, ha a szolgáltatás lassú, valószínűleg nem fog végül visszamenni. Most már könnyű, egyfajta étteremben kideríteni, hogy miért működnek lassan a dolgok. Lehet, hogy a konyhában kevés a személyzet, vagy hibás működött valamelyik berendezés, vagy lehet, hogy a várakozási személyzet kissé lusta, és könnyen azonosítható és rögzíthető.
De amikor egy adatközpontra gondolsz, az teljesen más történet. Lehet, hogy hálózati probléma, a rossz lekérdezés zavarja a dolgokat, az alkalmazás teljesítménye vagy a hibás kábel akár problémákat is okozhat. És az ilyen komplexitású hibaelhárítás, tudod, a legjobban is nehéz. Ez az, amiről ma beszélnének. És miként mondtam, Eric Kavanagh ma elemzőként becsapódott. Megkaptuk Dez Blanchfield-t, adattudósunkat, és van egy Bill Ellis, az IDERA-ból, aki beszélni fog a vállalati megoldásáról, amely segít az alkalmazás teljesítményének kezelésében. És ezzel átadom a labdát Ericnek. Eric, a padló a tied.
Eric Kavanagh: Jól van, jól hangzik, emberek. És valójában ez egy nagyszerű analógia, mert beszélt a nehézségekről vagy azok könnyűségéről, amellyel a hibaelhárítást végre lehet hajtani, és így lesz. A teljesítménygel kapcsolatos problémák mindig a hálózat valamiféle problémájából adódnak. Úgy értem, lehet olyan egyszerű, mint például a régi hardver, de a lényeg minden olyan helyzet, amelyben hibaelhárításra van szükség. Amit arról fogok beszélni ma. És engedjük tovább, és ugorjunk át a diákra itt.
Ebből baj lesz. Hibaelhárítás - öröm az emberek számára, akik szeretik, ez a hűvös dolog. Ha talál valakit, aki szeretne hibaelhárítást végezni, tartsa magát ehhez a személyhez, szerezzen neki néhány eszközt a munka elvégzéséhez, mert nagyon jó dolog, ha talál valakit, aki valami mélyére tud jutni, és megteszi. A lényeg az, hogy a hibaelhárítás problematikus, és mindig is volt, és mindig is lesz, és ha elkezdesz beszélni a hibaelhárításról, akkor valójában a kiváltó oka van. Mi okozza a problémát?
Nos, ha csak hátradől, és egy pillanatra gondolkodik még a mainframe napjairól is, mindenféle probléma felmerülhet. És akkoriban olyan emberekkel kellett rendelkeznie, akik valóban tudták a cuccaikat, mert még jó eszközök sem voltak a hibaelhárításhoz, tehát tényleg tudnia kellett a parancssorból, és erről másodpercen belül jól beszélt. És valójában elfelejtettem beilleszteni az egyik kedvenc diámat, ezt a mai show-on kerestem, talán a Dezs-bemutató alatt. De bárkinek, aki még nem látta, meg akartam mutatni az egyik legviccesebb brit TV-show-t, az úgynevezett „IT tömeg”. És a hibaelhárítás szempontjából az ír ember, aki az egész IT két emberének egyike vállalat, mindig ugyanazt mondja, amikor bármilyen hívás megkezdődik: „Megpróbálta már ki- és bekapcsolni?” Tehát próbáld ki és újra ki- és bekapcsolni. Meg kell lepődnie, hogy ez az egyszerű dolog milyen gyakran képes megoldani néhány problémát.
Azok köztük, akik otthon végzett hibaelhárítással, talán a szüleikkel vagy barátaiddal, valószínűleg nem a gyerekeiddel, mert hajlamosak tudni, mit kell csinálni, ki- és bekapcsolni. De a hibaelhárítás nem könnyű, soha nem lesz könnyű, de ma néhány olyan dologról beszélnék, amelyeket megtehetsz az egyszerűsítés érdekében. Tehát, a parancssor - igen, valóban, már elég öreg vagyok, hogy emlékezzem a számítás kezdeti napjaira, amikor csak a parancssor adta meg a DIR, Enter parancsot. Amit láthatna, a fájlok könyvtára, és pozitívan érzi magát, hogy valójában valamilyen parancs végrehajtásra került, ugye? Dez, természetesen adattudósunk, tudja, hogyan kell használni a parancssort. És ha tudod használni a parancssort, ez nagyszerű dolog, mert a legtöbb halandósági ember valamilyen GUI-t, grafikus felhasználói felületet használ, de mindig van valami, mindig megszakad a GUI és az alatti parancssor között. És csak egy véletlenszerű példaként szolgál, ha szeretné tudni, hogy az ott működő alapprogramok mennyi kódját dokumentumokba sütik ezekbe a napokba, lépjen be a Microsoft Word legújabb verziójába, írja be a „hello world” elemet, majd végezze el a „save as HTML. ”Ezután nyissa meg az eredményül kapott dokumentumot egy szerkesztőben, és valószínűleg látni fogja az oldalakat és a címkék oldalait. A kód puffadásnak nevezik, és a kód puffadása nem igazán jó a hibaelhárításhoz, csak tompa lenni.
Természetesen az ügyfél-szerver is jött, és ez nagyon jó dolog. Bizonyos értelemben visszatértek ebbe az irányba, de gondolkozzunk csak a komplexitással, amely a helyzettel jött létre. Most hol van a probléma, az ügyfélre vonatkozik, a szerverre, a hálózatra? Hol van? Ezek a webhelyek, amelyek csak a vírusokra gondolnak, és ha egy vírus bekerülhet egy hálózatba, mi történhet? Bárhová eljuthat. Az adatok megsértése őrült manapság. Teljesítményproblémákat okoznak. Volt orosz hackereink, amelyeket az IP-cím alapján azonosíthatunk. Biztosak voltak abban, hogy oroszak, vagy nagyon közel állnak, vagy nagyon okosak ukránok, lengyelek vagy akár az amerikaiak is, proxyk segítségével. De hacsak hackerek jöttek be a régi régi webhelyünkbe, a Belső Elemzésbe, az évek során, és mindenféle problémát okoznak. A cuccok csak nem működnek, nem végezhet el dolgokat. A dolgok, amelyek régen működtek, nem működnek. Honnan tudod? Honnan tudod mi ez? Csakúgy, mint egy újabb példa erre, egy nagyon összetett környezet, nagyon nehéz bejutni a gyomra, és valóban megérteni, hogy a dolgok hogyan zajlanak és mûködnek nekünk, különösen ha egész csomó plug-int kapsz. A cucc elég gyorsan megrázhat. Olyan vagyok, mint magam.
Idementem, mindig vigyázz a frissítésre. A frissítések mindig megijesztenek tőlem a napfényeket. Természetesen operációs rendszerek. Emlékszem a napokra, amikor a Microsoft valójában azt sugallta, hogy igen, frissítheti operációs rendszerét erről a verzióról arra a verzióra. Nos, próbáltam néhányszor, és soha, soha, soha nem működött. Ne felejtsd el, hogy minél nagyobb, annál összetettebb a környezet, annál súlyosabb a helyzet. Aztán ott van a virtualizáció. Gondoljon arra, hogy a VMware mit tett az informatikában. Forradalmasította az IT-t, de létrehozta az absztrakciók e rétegét is. Ha van egy réteg absztrakció ezen az alapszinten, akkor egy teljesen új labdajáték, egy teljesen új viaszgolyó, és valóban újra kell értékelnie, amit csinálsz, és az összes régi eszközt meg kellett változtatni. És most természetesen a felhő, ugye? Az ügyfél számára a felhő nagyszerű, mivel nagyon egyszerű, a felhasználói felület nagyon egyszerű, de természetesen nem igazán sok ellenőrzést végez a felhő felett. A színfalak mögött álló embereknek azonban rengeteg olyan dolog van, amelyet manapság tudniuk kell és meg kell érteniük. A környezet sokkal, sokkal összetettebbé vált. És minden bizonnyal az e-kereskedelemmel kapcsolatban, és minden pénzre gondolsz, amely manapság kezét viseli. Ez az oka annak, hogy hamarosan nem talál engem a készpénz nélküli társadalom mellett. A lényeg az, hogy a helyzet napról napra problematikusabbá válik.
A teljesítmény optimális tartása mindig magában foglalja a hibaelhárítás bizonyos elemeit. Nem érdekel, amit bárki mond, nincs tökéletes eszköz, nem ezüst golyó, és soha nem lesz, mert - egy másik érdekes szempontból - még mindig tanultak szilikonról beszélni. Még mindig megtanultuk megérteni, hogy még a hálózatépítés is működik a csúnya szemcsés szinten. Ha megnézi a rendszerkezelő szoftvert, az manapság nagyon jó lesz. De mégis, a felfelé és lefelé haladó vonalakra, valamint a valóság ábrázolására figyel, és olyan személyt fog elvinni, aki tudja, mi történik, hogy illeszkedjen azokhoz a nyomokhoz, amelyeket optimális eszközökre bámulhat, hogy megértsék a dolgozó dolgokat és mi nem, és sok próba és hiba, csak tompa lenni. Ezzel átadom Dez Blanchfieldnek, majd hallom Bill Ellis-től az IDERA-tól, aki szégyentelni fog minket tudásával. Dez, vegye el.
Dez Blanchfield: Hé, köszönöm Eric-nek. Köszönöm. Szépen belekerült a kis szigámba. A „Performance Art” címet szerintem rendkívül alkalmasnak tartják a mai beszélgetés összefüggésében, mert sok szempontból, amikor az előadóművészetre gondolunk, a táncra, a zenére és más kreatív dolgokra gondolunk. És őszintén szólva többnyire, ha problémák megoldása és nagyon nagyméretű informatikai környezetben és üzleti rendszerekben valóban létezik egy művészeti elem és gyakran a fekete művészet, mert a tapasztalatom szerint körülbelül 25 plusz év alatt az a helyzet, hogy a modern alkalmazás A halmok rendkívül gyorsan növelik a bonyolultságot olyan sebességgel, amelyet még soha nem láttunk. És őszintén szólva küzdenek lépést tartani, és vannak olyan szervezetek, mint például az Uber, és bármi más, és a Pokémon Go fejlesztőcsapatának, úgy értem, hogy növekedésüket, komplexitásukat és komplexitásuk növekedését tapasztalják csak csillagászati sebességgel. Még könyveket sem írtak róla, mert nem gondoltuk volna fel ezt a növekedési szintet. Véleményem szerint az alkalmazáscsomag alapvető meghatározása exponenciálisan átalakult, és elmagyarázom, miért gondolom mi az az eset, majd vezetem a jelenlegi kihíváshoz, hogy az IDERA jó barátaimnak megoldást kell találniuk.
Röviden, mindannyian tudjuk ezeket, de csak azért, hogy összefoglaljuk őket, a kezdeti időkben volt az, amit én hívok, az alkalmazás architektúrája, az 1.0 verzió. Szerver számítógép volt, ebben az esetben a mainframe és egy csomó csatlakoztatott terminál, viszonylag könnyű volt a problémák diagnosztizálása, ha láttak dolgokat a terminálon - nyomon követheted a terminál és a kiszolgáló számítógép közötti kábelt, és vagy zéró kábel, vagy csatlakozó, vagy valamilyen probléma, ha nem kapcsolódott a terminálhoz, és ha dolgokat lát a képernyőn, elég könnyű kideríteni, hogy a problémákat okozó dolgok maga a gépben vannak. És lassan diagnosztizálhatja, hogy a veremben melyik volt a hardvertől egészen a szoftverrétegig és a felhasználói felületig. Az 1.1-es verziónak kissé összetettebbé tettük. Az eszközöket a közepére tesszük, hogy több terminált helyezhessünk a helyükre. És ezek valamiféle kommunikációs eszköz voltak, és gyakran muxik vagy multiplexerek voltak, vagy akár dedikált vonalon, vagy telefonos vonalon haladnának, és így távoli helyen voltál egy mainframe - lehet államközi vagy nemzetközi szinten - és valamilyen eszköz SMA kapcsolaton keresztül vagy valamilyen WAN kapcsolaton keresztül csatlakozik, és ezek a terminálok továbbra is ugyanúgy működnek. De kicsit bonyolultabb volt, mert ki kellett derítenie, hogy a probléma a terminálok és az comms eszköz, vagy az comms eszköz és a mainframe között van-e. De a verem viszonylag hasonló maradt a mainframe-ben.
Az 1.2-es verzió, egy kicsit bonyolultabb, mert most több eszközt adtunk hozzá, hozzáadtuk az ers-t és más dolgokat, és csoportosítottuk ezeket a dolgokat, és egy olyan front-end processzorra gondolok, amely helyben kezeli az eszközök összes kérdését, ers és terminálok, és így tovább, a távoli végű mainframe-rel. Kicsit bonyolultabb. De a mainframe következetes témája a helyileg futó alkalmazások voltak, tehát a problémamegoldás meglehetősen hasonló maradt az alkalmazáskötegben. És akkor olyan készségekkel küzdő emberek voltak, akik rendezték a kérdéseket a terminálokkal, az ERS-ekkel és a fürtvezérlőkkel. De aztán bonyolultak a dolgok és hálózatokat építettünk fel, és hirtelen ugyanolyan architektúra vezet be egy hálózati réteget. Hirtelen hálózati kapcsolónk volt, és a munkaállomások sokkal összetettebbek voltak. És az építészetnek ez a verziója gyakran volt a grafikus felhasználói felület alkalmazásai a munkaállomáson. Nemcsak volt egy kiszolgáló, amely az app-verem fut, hanem egy újabb helyileg futó alkalmazáscsomag is volt, és természetesen ugyanaz az alapvető eszköz, amely a kiszolgálóhoz kapcsolódik. Aztán kvantumig ugrottunk a 2.1-nek hívott újabb modellhez, ahol elvittük azt az alkalmazáscsomagot, és sokkal összetettebbé, sokkal nehezebben diagnosztizálhatóvá tettük. És még sok más eszközt mutattunk be az elülső oldalon, a webböngészőkben, a PC-ken és a mobil eszközökön, stb. És itt az alkalmazás verem majd egyre mélyebben belemerült az integrációba, mint az operációs rendszer és a hipervizor.
Ez a kép, a jobb oldalon, a jobb oldali első verembe helyezte a teljes köteget, beleértve a hálózati infrastruktúrát, a tárolókiszolgálókat, a virtuális gépeket, az operációs rendszert, majd a hagyományos három szintű adatbázis fémszerkezeti alkalmazást stb. Az alkalmazási és a teljesítményproblémák diagnosztizálása ebben a modellben egyszerűen csak nehezebbé vált. Olyan sok mozgó alkatrész van, és az a verembe történő átfúrási kísérlet, tudod, csak rémálommá vált, és ehhez további készségeket és szervezetet kellett bevonnia. Már nemcsak az alkalmazási csapat volt, hirtelen most már infrastruktúrájuk volt, adatbázis-szakemberek voltak, pusztán csak adatbázisokon dolgoztak, és semmi mást - szemben a rendszerprogramozóval, aki ismerte az adatbázisok körüli útját. Most van egy forgatókönyv, amikor az informatikai osztályoknak sokkal szélesebb összetettséggel kell foglalkozniuk a „szolgáltatásként”, és ebben az esetben a világ csak felrobbant és a problémamegoldó kihívásaink váltak, rémálommá vált olyan dolgokká, amelyek szinte elviselhetetlenek. bizonyos szempontból.
És ez úgy oldódott meg, hogy megpróbáltak szolgáltatásokat nyújtani a. A 3. verzió, amit az alkalmazásveremnek tekintek - ezt bevezette egy szolgáltatásmodellbe, ahol a bal oldali hagyományos modell, a vállalati IT-verem, ahol mindent a végén, mint fogyasztónak és a szolgáltatásokat - az alkalmazásbiztonsági adatbázisból, az operációs rendszerekből, a virtualizációs szolgáltatás tárolásából, az adatközpontok hálózatba szervezéséből - mindent meg kellett kezdenünk, de hozzá tudtunk férni mindazokhoz, és így kibővítettük képességeinket és műszaki készségeinket, és végigfúrhattunk azon a veremben, és találhattunk dolgokat. Mivel azonban az infrastruktúra-szolgáltatás és a platformszolgáltatás, valamint a szoftver-szolgáltatás modell együtt jött, hirtelen megszabadultak tőlünk a háttér-infrastruktúrához való hozzáférésünk, a platformokhoz való hozzáférésünk és az általunk szolgáltatott eszköz. Amikor elkezdtük fogyasztani az infrastrukturális szolgáltatást, valójában csak az operációs rendszer, az adatbázis, a biztonsági környezetvédelmi alkalmazás verem és a legfrissebb négy darab áll rendelkezésünkre. Az alatt minden fekete mágia volt. És még érdekesebbé válik, amikor a platformszolgáltatásra lép, mert csak az alkalmazásköteg kezelését is végzi.
Ha szoftvert keresünk szolgáltatásként, és annak hagyományos modellje a webmail vagy az internetes banki szolgáltatás, akkor csupán hozzáféréssel kell rendelkeznie egy webböngészőhöz, tehát megkísérelni diagnosztizálni a mögötte levő eseményeket, feltétlenül elfogadhatatlan. És ezt időzónákra, időrésekre vagy időterületekre bontva, ha úgy tetszik, vagy generációkat tekintve, balról jobbra a 2000-es évek előtti fajtáktól és a hagyományos halomtól mentünk, ahol hozzáférhetünk az egész környezethez és átfúrhatnánk rajta. De az idő múlásával egyre összetettebbé vált. A 2000-es évek elejétől 2000 közepéig, 2000 végéig a mai napig, ahol az infrastruktúra-szolgáltatástól, a platformszolgáltatástól és a szoftverszolgáltatástól elmentek, mostanáig alapvetően üzleti szolgáltatásra utaltak. És az összetettség drámai módon megnőtt. Olyan sok mozgó alkatrész van. De a készségek rendelkezésre állása egyre nehezebbé válik, és egyre nehezebb igénybe venni magunkat. A megfelelő képességekkel rendelkező emberek megkeresése a megfelelő eszközökhöz való megfelelő hozzáféréssel, hogy bekerülhessenek a verembe, és belemerülhessenek ebbe a verembe, és megtudhassák, hol van valami lassan. A laptopom vagy az asztalom, a telefonom vagy a táblagépem, a 3 vagy 4G-n keresztüli összeköttetésem, vagy az ADSL-mel vagy az ISDN-mel való külön kapcsolatom, bármi is lehet? Vagy akár telefonos telefonos, bár manapság ez egyre kevésbé jellemző. Vége van a webszervernek, valami a webszerver belsejében? Ez az alkalmazáskiszolgáló? Ez valami a CPU memóriájában és lemezében, valamint az alkalmazáskiszolgálón belüli hálózati teljesítményről szól? Az adatbázis ott fut?
És el tudod képzelni, hogy nagyon gyorsan rajzolja ezt a képet a komplexitásról, amely elkezdi kibontakozni, mint egy nagy bumm kép, ennek az egyre növekvő buboréknak, amely megpróbálta körülkerülni a karjainkat, és amelyek képesek voltak belemerülni a tudásba és a tudás és ahol boncolhatják és szétszedhetik. És nagyon sokan voltak a korszakban, amikor, tudod, az emberek nem tudnak megbirkózni a fizikai léptékkel, még akkor is, ha megvan a képessége, hogy az adatbázis-környezetet elválasztja, és az adatbázist elválasztja, és belemerüljön az adatbázisba.A most kezelt adatbázisok száma gyorsan növekszik. Mostantól mindent egy adatbázis működtet. Manapság nagyon kevés alkalmazás működik adatbázisban. És az adatbázisok típusai is gyorsan növekednek. Nemcsak a hagyományos SQL-adatbázisok, néha SQL, néha nem SQL, néha grafikon-adatbázis, néha dokumentum-adatbázis. És vannak ezek a különféle típusú funkciók, amelyek ezekkel a különféle típusú adatbázisokkal rendelkeznek, és ennek eredményeként mindegyikük eltérő teljesítmény-kihívásokkal és eltérő teljesítménykritériumokkal rendelkezik. A naplózási adatbázisok és a dokumentum-adatbázisok nagyon-nagyon eltérő módon teljesítenek, és különféle funkciókat hajtanak végre, mint a hagyományos ACID-kompatibilis, ANSI 92-kompatibilis SQL adatbázis. És milyen típusú dolgokat tároltunk ott.
Az a gondolatomban egy ponton volt, ahol - és azt hiszem, Eric erre utalt -, hogy az emberek küzdenek lépéssel tartani az épületek komplexitását és az építési sebességet, és most ott vannak, ahol a az infrastruktúra kezelésének egyetlen módja, és a felmerült problémák figyelemmel kísérése és az azokba való belemerülés egyetlen módja az eszközök és a megfelelő típusú eszközök. És akkor mindig a szerszámok helyes generációja. Eszközök, amelyek valóban megértik a háttér-infrastruktúrát. Már nem jó az, ha valamit eldob egy SQL figyelőt vagy egy SQL lekérdező eszközt, és elkezdi szétválasztani a lekérdezést, és megnézheti, mi működik rajta. Szükségünk van egy olyan eszközre, amely megérti a lekérdezések kialakulását és a lekérdezések megfelelő formáját, valamint a lekérdezések megfelelő módjait, hogy megbeszéljék az infrastruktúrát a hátsó oldalon, és hogy hogyan teljesítenek. És nézzük meg az interakciók időzítését és annak sorrendjét.
És ez egy sokkal összetettebb kihívás, és ez vezetett engem a kérdésem pontjához, vagyis az, hogy mivel az alkalmazáskötegek bonyolultsága tovább fejlődik, a teljesítmény-eszközöknek és az ezek kezelésére használt eszközöknek szükségszerűen válniuk kell egyre okosabb és sokkal képesebb több dolgot megnézni. Ugyanakkor sokkal okosabb az is, hogy belemerülnek a hátulról futó dolgokba, és mit tudnak felfedezni róla, és esetleg valamiféle elemzést is végeznek ezen keresztül, hogy megértsék, hogy az interakciók és a teljesítmény megvalósulnak, és miért teljesít lassabban vagy gyorsabban.
Aztán ezzel átadom az IDERA kedves barátjának, Bill Ellisnek, és megnézem, mit kell mondania ma arról, hogy hogyan oldják meg ezt a kérdést. Bill, neked.
Bill Ellis: Rendben. A nevem Bill Ellis és nagyon köszönöm. Beszélnék arról, hogy az alkalmazásom lassan fut, ideje pontosítani. Lássuk, mit tehet az IDERA termék, a Precise, és hogyan segíthet Önnek. Sokszor csak azt tapasztalja meg, hogy ezek teljesítményprobléma voltak, mert a végfelhasználó felhívott téged, és ez önmagában valóban nagy probléma. Az informatikai szakemberek közül senki sem tudta, amíg a telefon meg nem cseng. A következő nagy probléma az, hogy miként segítünk erre az egyénre, és ez valójában nem triviális probléma. Ebből egy elvitel van. Ez a csúszda fölött és túl, a többiek felett és túl. És azt szeretném, ha megnézné, meg tudja-e érteni, mi az. De amint már említettük, egy alkalmazás megköveteli, nagyon sok különböző technológiára támaszkodik, az alkalmazáscsomag magas és növekszik. És sokan böngészőn keresztül férnek hozzá az alkalmazásokhoz, és meglepő módon egyre több és több feldolgozás történik a böngészőben szkriptekkel stb., És természetesen megvan a hálózat, a webszerver, az üzleti logikai kód és az adatbázis. Azt szeretném, ha figyelembe veszi, hogy minden jelentős üzleti tranzakció kölcsönhatásba lép az adatbázissal, függetlenül attól, hogy az időkártya jelentése, a leltár lekérdezése, a megrendelés és az adatbázis frissítésre kerül-e. Tehát az adatbázis valóban a teljesítmény alapjává válik. És az adatbázis természetesen bekapcsolhat, vagy támaszkodhat a későbbi szakaszra a tárolás során. Ezen technológiák mindegyike szorosan kapcsolódik egymáshoz, és képes látni, mi történik. Tudnia kell, hogy mi történik, hogy képes legyen mérni, kritikus jelentőségű.
Egy dolog, amit találunk, az a tény, hogy sok vásárlónknak van egy szerszáma, és minden technológiához van eszközük, de mi nincs nekik, az a con. A con lényegében az a képesség, hogy a pontokat az alkalmazásköteg minden szintje között összekapcsoljuk, és ez valójában viszonylag egyszerű. Régebben tizenkét réteg korlátozása volt, de alapvetően megváltoztattuk, korlátlan rétegekkel rendelkezünk és vegyes környezetet támogatunk, így alapvetően rendkívül bonyolult lehet a Precise megoldással.
Ma magas szinten így oldjuk meg a problémát, és annak a tranzakcióra összpontosítva, azaz a végfelhasználói tranzakcióról kattintásról lemezen megmondja, melyik fut lassan, melyik forrást fogyaszt, de a kulcs ez - megengedjük, hogy felvegye és felhasználói azonosítóját a helyére, és ne csak a teljes tranzakció ideje, hanem az, hogy mennyi időt töltenek minden egyes lépésnél. Az idő a teljesítmény pénzneme, és azt is megmutatja, hol használják fel az erőforrásokat. Nem tudjuk előre, hogy hol lesz a probléma, tehát a mérőszinteknek és az elemzésnek mindegyik szinteken kell lennie, hogy diagnosztizálhassuk a problémát, hol lehet a probléma.
Most, a mai bemutatóban erre a területre fogok összpontosítani, azt szeretném, ha biztos vagy benne, hogy alapvetően azonos szintű láthatóságot biztosítunk az alkalmazásköteg minden szintjén, és a legfontosabb dolog, hogy elmondja nekünk, ki, mi, hol és akkor ez a rész, ez meg fogja mondani nekünk, miért. És valójában ezért van ez a döntő fontosságú a problémák megoldása szempontjából, nem csak a róluk való tudásról. A másik dolog, ami egyértelműen kiderült a bemutatóban, az volt, hogy lehetetlen megtenni. Automatizálásra van szüksége. Az automatizálás azt jelenti, hogy riasztással rendelkezik, és van valami, ami azt mondja neked, hogy - remélhetőleg a végfelhasználói közösség előtt -, hogy folyamatban van a trend, épített eltérést a trend riasztástól. És akkor egy sorot is kínálunk a homokban, valójában megsérti az SLA-t. Most sok különböző információt kínál - nem mindenkinek kell büfét fogyasztania, egyeseknek csak könnyű harapnivalót akarnak fogyasztani, ez saláta, és így azzal a portállal, amelybe információkat tölthetünk fel, csak egy adott felhasználóra van szüksége. vagy egy adott közösséggel kapcsolatos információkra van szükség a teljesítményről. Az alkalmazás lassan fut, ideje pontossá válni. Valójában négy dologra összpontosítottunk. Az egyik a hely, amely megadja a végfelhasználót. Még egyszer, ez a pont, amely összekapcsolja a pontokat, és a kutatás harmadik része azt mutatja, hogy csaknem 90 százalékkal az alkalmazásokkal kapcsolatos problémák vannak az adatbázisban, tehát ez valóban egyfajta törekvés, amelyet a teljesítménymegoldások többsége talán egy SQL-utasítás mond. De nem mondják el, hogy az SQL utasítás miért fut lassan.
Tehát, miért mindig döntő jelentőségű, és a Precise kiválóan megmutatja, hogy miért minden rétegre és különösen az adatbázisra, és csak egy kicsit megoszthatja veled a támogatási mátrixunkat, amelyeket az SQL Server, a Sybase, a DB2 támogat és / vagy ömlesztett. A megoldás külseje és megjelenése nagyon hasonló, tehát ha több alkalmazást vizsgál, de kissé eltérő architektúrákat. Az itt megosztott információk megjelenése és érzése, megközelítése megegyezik, függetlenül attól, hogy mi történik az alapjául szolgáló technológiákkal. Pontos a web. Bejövünk, hitelesítjük a Precise-t, és ezzel bemegyünk, és az első dolog, amit érdemes megnézni, a teljesítmény helyszínenként. Tehát itt valóban láthatja a különböző helyeket, ahol az emberek ténylegesen hozzáférnek kivégzésükhöz. Megtekintheti, hogy valaki elhagyott-e egy oldalt, mielőtt annak teljes megjelenítésére került sor, vagy vannak-e hibák.
Ezeknek az alkalmazásoknak az egyik része a hálózat vagy az alkalmazáskiszolgálótól való távolság. Nagyon könnyű itt látni, hogy van valamilyen szintű hálózat. Látom, amikor az emberek elfoglaltak, majd egy másik érdekes dologról beszéltünk arról, hogy a böngészőben miként dolgoznak fel, és valójában észreveszik, hogy a különféle böngészőtípusok jobb környezetet biztosítanak a gyors feldolgozáshoz. És így tudva, hogy az emberek hozzáférnek-e a Chrome vagy az IE segítségével, vagy bármi is történik, valójában nagyon gyakran észleli, hogy az egyik böngészőtípus-inverzió valóban jobb, mint a másik. Most, néha nyilvánosan szembesülve, nem kezeli a böngészőt, néha az alkalmazások belső oldallal vannak ellátva, ahol az emberek böngészőtípust ajánlhatnak a végfelhasználói közösséghez, és így ezek a mély merülés láthatóságának és elemzésének típusai, amelyek közül a Precise képes biztosítani. Most egy alkalmazást vizsgálunk.
Nem vagyok biztos benne, hogy srácok láthatják-e a mutatómat, de szerettem volna leírni neked a felső grafikont. Az y tengely az átlagos reakcióidőt mutatja. Az x tengely egy napi időtartam. És valójában egy halmozott oszlopdiagramon és a halmozott oszlopdiagramon, az összeg azt mutatja meg, hogy mi a teljesítmény, majd azt mutatja, hogy mennyi időt tölt az alkalmazás egyes lépésein vagy egyes rétegein. Az ügyféltől kezdve a webszerveren keresztül a zöld a Java, ez a hely Tuxedo-t használt, és le az adatbázisba. Most a képernyő alsó részén láthatóak azok a különféle internetes menük, amelyekhez hozzáférünk, és ezt követően egy kis zöld nyíl mutat le, amelyet lefelé mutatunk. Csökkenő sorrendben, és felfelé robbant, a webmenü megjelenni kezd. Valójában megmutatjuk az egyes technológiák végrehajtási idejét, reagálási idejét, majd az oszlopdiagramokat feltüntetjük mindegyik webmenühöz, és így kapjuk elképzelést arról, hogy mi folyik. Ne felejtsd el, hogy mindezt úgy rendeztük, hogy a végfelhasználó felhívná, de hogyan találok a végfelhasználót? Azért jöttem ide, kinyitom a menüt, amely lehetővé teszi, hogy kiszűrjek egy adott felhasználót, tehát Alex Net-re állítottam a felhasználót, rákattintok az OK gombra, majd csak az Alex Net tevékenységeire koncentráltam. Most pedig, hogy ez lehetővé teszi, hogy az informatika és az informatikai menedzsment közvetlenül reagáljon a végfelhasználóra, különös tekintettel arra, hogy olyan tartalomkezelést vizsgáltak, amely hat végrehajtást hajtott végre, alig több mint három másodperc válaszidővel. Nos, három másodperc elég jó, nem szörnyű, de talán lassabb.
Mit tehetek ezzel, az az, hogy különféle módon tudom feldarabolni és felrakni ezt az információt. Elmondhatom, hogy vajon ez a tranzakció mindenkinek lassú-e? Ma lassabb ma Alex számára, mint tegnap? Lassú-e egy adott helyen lévő összes felhasználó számára? Vagy pedig ez lehetővé teszi számomra szelet és kocka felfogását, és képet kapok arról, hogy mi történik, mennyire univerzális a probléma, és nagyon fontos a végfelhasználó azonosítása, mivel nemcsak a szoftverről van szó, az infrastruktúra, és arról is, hogy a végfelhasználók hogyan gyakorolják az alkalmazást. Időnként lehet, hogy van új alkalmazottja vagy valaki új feladat funkcióval, és nem ismeri bizonyos SAP képernyőket vagy egyes PeopleSoft paneleket, és szükségük van egy kis mutatóra, esetleg elhagyják a mezőket, vagy helyettesítő mezőket helyeznek el, és nagy eredményeket kényszerítenek rá. vissza az adatbázisból. De a felhasználói azonosítóval valójában felhívhatja őket, mielőtt felhívnának. A másik dolog, amit találunk, az, hogy amint a felhasználói közösség tudatában van annak, hogy az IT tudja, mit csinál, sokszor jobban viselkednek és sok probléma merül fel, sok olyan kérdés volt, ami csak problémát okozott, csak elpárolog, mivel az emberek viselkednek, csak egy kicsit alaposabban működjenek. Nagyobb gondossággal használják a rendszert.
A végfelhasználó azonosítása elengedhetetlen. Végül elengedhetetlen az informatika számára, hogy képes legyen egy adott végfelhasználóra segíteni. Most, amit itt csináltak, elmentünk a „Folytatás” fülre. Ezt láthatja a bal felső sarokban. És a webmenü egy adott elemére összpontosítottunk. A jobb oldalon pedig egy adott tranzakció elemzése található, így a tetején valójában a böngésző, majd a Nézet, csak hogy megismerkedjünk a grafikus felhasználói felületen található ikonok egy kicsit a webszerverrel, tehát láthatjuk az attribútum pontját. És akkor a "J" a Java, a "T" a Tuxedo, és természetesen a "Q" az SQL. Nos, hogy a készpénzérték alapvetően azonosítja az adott SQL utasítást. Fontolja meg, mit csinál ez. A felhasználót azonosítottuk egy tranzakcióval, az alapul szolgáló alkalmazáskóddal, beleértve az egyes SQL utasításokat. Most, amikor megnézem ezeket az egyedi SQL utasításokat, látom, hogy a teljes válaszidőből mindegyik felelős körülbelül hat százalékért, és amikor összeállítják a négy legjobb SQL utasítást, a tranzakció körülbelül egynegyedét vállalják. idő.
Most gyakran az adatbázis kezelése a legegyszerűbb. Általában a legkönnyebb olcsó, sokkal jobb teljesítményt elérni. Most egy kicsit mélyebbre kell mennem, hogy megtudjam, mi folyik, és mi, azt akarom, hogy a példa valóban az egyes SQL utasítások feltárása legyen, és tudod, hogy szinte garantálhatom neked csak a vonal minden egyes lövését. volt valamiféle adatbázis-eszköz, és amit az adatbázis-eszköz tesz, de csak egy technológiát önmagában tekintve, az az, hogy a technológia egészségi állapotára összpontosít. És sokszor az emberek az első tíz listát nézik meg. Most ez az SQL utasítás elég gyors, nem fog szerepelni a tíz legjobb listán, de az SQL utasításra támaszkodik ez a tranzakció. Tehát, amit vissza tudok csinálni ezzel a szavakkal, a con, most az lehet, hogy felhívom erre a mély figyelmet, de az egyes SQL utasítások összefüggésében.
Most az a személy megnyithatja a Precise-t az egyes SQL-utasítások során, és a Precise rögzíti az általa használt tényleges végrehajtási tervet. A végrehajtási idő, amely a DBA számára fontos, ténylegesen megmutatja, láthatja, hogy a az idő a tárolásra vár. Az idő ötven százalékát használják a CPU-ban, így elképzelései merülnek fel arról, hogy hol töltik az időt, hogyan tudnék ezen időt lecsúsztatni, és az ötlet az, hogy lehetőségeket biztosítsunk az embereknek, mivel a különböző válaszokhoz különböző költségek és kockázat kapcsolódik. . Ideális esetben egy alacsony kockázatú, olcsó megoldás után oldották meg a problémát. Most, hogy az SQL utasításokat hash-érték követi nyomon, és a képernyő bal oldali közepén ez a kis „Tune” gomb jelenik meg, és mit fog tenni, az elviszi egy SQL feladathoz. És ez az SQL feladat egyfajta előre elkészített munkapad, és mit tesz ez, az lehetővé teszi számomra, hogy ténylegesen elemezhessem az SQL-utasítást befolyásoló tényezőket, kezdve a végrehajtási tervvel. A végrehajtási tervet az optimalizáló választja ki, amikor az utasítás feldolgozása megtörténik. Az élelmiszer analógiához visszatérve a recept az SQL utasítás megoldásához követi.
És egyes receptek bonyolultabbok, mint mások, és így adunk eredményeket. És valójában itt megmutatja, hé, sok idő alatt sorozatos I / O műveleteket végez egy adott indexen. És lássuk, mikor tér vissza az oxigénhez, kövesse ezt az indexet. Ezt az indexet nemrégiben töredezettségmentesítették, mi az egészségi állapot? Milyen asztalterületen él? Az asztalterület szét van szétválasztva a hivatkozott táblából? Így kezd mindenféle ötletet adni a probléma megoldására. Most már nyilvánvalóan, tudod, egy indexet építettek. Sokkal alacsonyabb a kockázata, sokkal könnyebb, mintha egy indexet átmozgatnánk az egyik asztalterületről a másikra a táblaterületre, tehát azt akartuk, hogy egyfajta felépítési opciók legyenek, hogy a legolcsóbb, a legkisebb kockázatú megoldást telepítsük a probléma.
A precíz olyan tevékenységeket is végezhet, mint például az SQL utasításhoz leadott kötési változók rögzítése. Nyilvánvaló, hogy a leadott változók ellenőrzik az eredményhalmaz méretét. Ellenőrzi majd, hogy az SQL utasítás végrehajtásához mennyi ideig kell menni, és mennyi adatot kell továbbítania és feldolgoznia az alkalmazásnak a Java-on keresztül, a .NET-en keresztül, a leadott webszerverre és a hálózatra, amelyet végül a végfelhasználói böngészőben kell megjeleníteni. . Az, ami az adatbázisban történik, közvetlenül befolyásolja a böngésző idejét. Ezért döntő fontosságú az ilyen szintű láthatóság, hogy pontosan tudjuk, mi folyik, és a legtöbb lehetőséget adjuk a DBA-nak, hogy megválaszthassák, melyik a legmegfelelőbb, adott helyzetre tekintettel.
Most néhány ilyen idézet, és ezek valószínűleg egy PeopleSoft üzletből származnak, amely globálisan telepítve van. A Precise támogatja a PeopleSoft és az SAP, a Siebel, az Oracle, az E-Business Suite, a házi Java és a .NET alkalmazásokat. Támogatjuk, így ha webes szolgáltatáshívásokat kezdeményez több JVM-re, a Java-tól a .NET-ig a Java-ig, akkor mindezt nyomon követhetjük. Lehet, hogy előzetesen, a felhőben is lehet. A döntő dolog az, hogy a dolgokat műszerezni kell.
És így, csak néhány idézet az egyik ügyfelünktől: „A pontos meghatározás előtt a DBA-k használtak OEM-t.” - ez csak egy adatbázis eszköz, és alapvetően azt mondták: „Hé, a példányok jól néznek ki.” De ők segít megmondani vagy kezelni egy adott tranzakcióval kapcsolatos problémát. Pontos, ha látta ezt. Ezért kritikus fontosságú volt az SQL-utasításokkal kapcsolatos információ megszerzése a DBA-k számára, hogy teljes mértékben kiszorítsák a teljesítményt az adatbázisból. És tehát ez nagyon kedves volt. Olyan eszközökön túl, amelyeket megnézhet.
És akkor az informatikai menedzsment nagyon szerette azt a tényt, hogy a Precise képes volt összetett URL-t lefordítani panelenévé. És így, ha egy végfelhasználó felhív, és azt mondja: “Hé, nekem ezzel gond van”, elkülönítheti és megnézheti, ki ez a felhasználó, mit hajtanak végre, milyen teljesítményt nyújtanak, valójában megmérik a megjelenítést az idő a végfelhasználó böngészőjében. Ez a végfelhasználói élmény valódi mérőszáma. Tehát az is, hogy a felhasználói azonosító megléte elengedhetetlen ahhoz, hogy segítsen egy hívott személynek.
Hogyan csinálja pontosan ezt? És ezért szeretnénk megosztani építészetünket. A precíznek saját kiszolgálón kell élnie, és virtuális gépen kell lennie, felhőben is élhet. A kezelőfelületen a Precise webesen engedélyezve van, függetlenül attól, hogy műszerfalakat, riasztási felületet vagy a Expert GUI-t használ. Az adatgyűjtés oldalán ténylegesen meg tudjuk csinálni több különböző technológiát. Gyakran azonban szükségünk van egy ügynökre, és pluszok és mínuszok is vannak az ügynök rendelkezésére. Nagy plusz ez, hogy az összegyűjtött adatok előzetesen feldolgozhatók, mielőtt azokat a LAN-on keresztül továbbítják. Ez azt jelenti, hogy minimalizálhatjuk a megfigyelő megoldásnak a célkörnyezetre gyakorolt teljes hatását.
Most fontolóra vegye egy alternatívát, ha van „ügynökötlen”, akkor is van adatgyűjtő, csak az a kérdés, hogy hol lakik, és hívásokat kezdeményez, és nyers adatokat továbbít a cél alkalmazásról a LAN-on keresztül. És valójában nagyon drága. És tehát az előfeldolgozással minimalizálhatjuk a lábát. Ellenőrizheti mind a fizikai, mind a virtuális képeket.És egy dolog, amit el akartam mondani a virtuális technológiáról, az, hogy valóban a felhasználásra koncentrál. Amit a pontos pont az érvelésre összpontosítja. Mikor valósítja meg a VMware technológia a vendég virtuális gép forrásait? És így nagyon könnyűvé válik. Ha csak a vendég virtuális gépén belül nézi, akkor a képnek csak egy része van. Ez ténylegesen alapvető fontosságú a vita automatikus észlelése és riasztása során.
A Precise akár 500 példányt is megfigyelhet, tehát a nagyon nagy telepítéseknek alapvetően több Precise szerverük van. És egy globális telepítéshez általában precíz szerver lesz az egyes adatközpontokban. Mellesleg, a legelterjedtebb telepítéseknél ezeket valójában egyesítheti, így a vállalati szemlélettel nézheti meg a folyamatot, és jelentést tud nyújtani stb. Most, ahogy már említettem, rengeteg technikai elemzés van. Nem mindenkinek kell belépnie a szakértői grafikus felhasználói felületbe, ezért testreszabható műszerfalat kínálunk. És ezek a portletek vagy kütyük mindegyike választható. És lehet, hogy valaki csak el akarja menni: „Hé, hogyan lehet riasztást elérni a környezetünk bármelyik szintjén? Hogyan működnek a végfelhasználói csoportok teljesítmény szempontjából? ”Vagy kérdése lehet az infrastruktúrával kapcsolatban, talán még a Tuxedo előadásba is. Vagy akár a terheléselosztás. Ilyen érdekes itt ebben a terheléselosztási részben. A bal oldali közepén lévő portletre nézek. Láthatja, hogy a végrehajtások száma nagyon hasonló az egyes webszerverek között. De a válaszidő nagyon eltérő a tetején. Valójában fúrást végezhet, és pontosan megtudhatja, miért volt a webszerver válaszideje sokkal lassabb, mint a többi.
Egy dolog a terheléskiegyenlítésnél, ez nagyon fontos, és a terheléselosztási házirendek, tudod, nem minden terheléskiegyenlítési politika megfelelő minden alkalmazáshoz. Valójában nagyon hasznos a terheléselosztási politika érvényesítése. Egyes alkalmazásokkal, mint például az új PeopleSoft Fluid GUI, valójában látunk, ahol valójában néhány webszerver offline állapotba kerül. És tehát ez valami nagyon kritikus. Ha a PeopleSoft Fluid GUI-t telepíti, kérjük, vegye fel velünk a kapcsolatot. Nagyon sok betekintést és sok ismereteket tudunk biztosítani arról, hogy mások milyen ügyfelekkel szembesültek vele. Ezek a portletek mindegyike nagyon részletes lehet. Mint a jobb felső sarokban, a kék és a zöld valójában a kardhegy mintázatát mutatja, ez egyúttal azt is jelzi, hogy a WebLogic rétegben lévő hulladékgyűjtés úgy működik, ahogy elvárja. Ezeknek a portleteknek mindegyike nagy hangsúlyt fektethet vagy nagyon magas szintű is lehet. És az az oka, hogy ez fontos vagy fontos lehet, sokszor nem elég, ha csak ezt az információt IT-n belül tartja, néha ezt az információt meg kell osztania az alkalmazások tulajdonosaival, néha a felső vezetőséggel, hogy mi folyik itt .
Szerettem volna megosztani veled néhány történetet, a „Siker az adatközpontban” típusú történetet. És ezek adatbázis-központúak, és vannak más történetek, amelyek középtávúak. De ma nagyon szeretnék összpontosítani az adatbázis szintre. Vessen egy pillantást a képernyő lefagyására. Itt történt az, hogy ennek a boltnak volt üzleti SLA-ja, tehát ha a megrendelés délután 3 órakor érkezik meg, akkor a megrendelés aznap lesz. A raktár tehát rendkívül forgalmas ebben az időszakban. Aztán a képernyő lefagyása nagyon frusztráló volt. És így a felügyelő - ez egy kisebb társaság - a felügyelő valójában bement az IT-be, és természetesen felmegy a DBA-ra, és azt mondja: „Most mi folyik itt?” És tehát, amit tettünk, képesek voltunk pontosan megmutatni mi folyik itt Most ez a JD Edwards, egy többszintű alkalmazás, ez az értékesítési rendelési képernyő. Lehet kapni egy ötletet arról, hogy mi volt az üzlet, alapvetően egy időben leltárt, és így alapvetően a raktári alkalmazásokat vizsgálja. És most alapvetően számos különféle ügyféloldalra, üzletre szállít. És amit csináltunk, pontosan megnyitottuk.
Ebben az esetben, mielőtt az Oracle-re néztünk, itt az SQL Server-re gondolunk, és most a felső felület egy halmozott oszlopdiagramon mutat bennünket, ahol az SQL utasítások idejét töltik végrehajtás közben. Minden gyenge állapotot figyelembe kell venni az y tengelyen. Az x tengely természetesen az idő függvényében, és láthatja, hogy a halmozott oszlopdiagram az időszelettől függően változik, attól függően, hogy mi futtatja és hogyan használja a rendszert. Most ebben a konkrét esetben a harmadik SQL szekvenciára összpontosítottunk felülről. Ez a SZÁM KIVÁLASZTOTT PS_PROD-ból, és ebben az oszlopban láthatja, hogy rögzítettük a tényleges végrehajtási tervet. És láthatod a kivégzések számát. Az a tény, hogy az adott SQL utasítás felelős az erőforrás-felhasználás 9,77 százalékáért ebben az időszakban, amelyet megvizsgálunk - és ez egy fontos pont, az időkeret, a Precise gördülő előzményekkel rendelkezik - és így alapvetően be tudok tárcsázni és megtudhatja, mi történt egy adott időpontban vagy az idő múlásával. Képes vagyok megtekinteni a trendeket.
Most, ez az SQL utasítás, látja a halmozott oszlopdiagramot, sötétkék. Ez azt jelenti, hogy az összes CPU-t használjuk. Menjünk előre, és összpontosítsunk az adott SQL utasítás „TUNE” gombjára kattintással. Mit csinálunk, belevesszük azt a műhelybe, előre épített műhelybe, amelynek célja: "Nos, mit fog tudni a DBA erről az adott SQL utasításról?", És a jobb oldalon láthatod, hogy van egy fül, melynek neve: Előzmények ”. És azt szeretném, ha most megtenném, az egyfajta váltás a bal oldali oldalra, ahol a „Változások vs. időtartam átlaga” felirat áll, az átlagos időtartam. És mindegyik bár bárnapi eseményeket reprezentál.
Láthatjuk szerdán, csütörtökön, pénteken, hogy a kivitelezés ideje az volt, hogy a második pontra fordulok. Az y tengely négy másodperc pontot mutat, tehát a második pontot. Nagyon kevés a képernyő lefagy, a műveletek nagyszerűek, az SLA-ban. Sajnos február 27-énth megváltozott a végrehajtási terv, és ez azonnal megváltoztatta a végrehajtási időt. Hirtelen a végrehajtási idő növekszik: négy X, talán öt X, és a dolgok nagyon rosszul futnak. Most Precise, az adattárában valójában naplózza az összes változást, amely hatással lehet a viselkedésre. És itt láthatja, hogy valójában rögzítettük a tengely síkjának változásait. A középső részben a „Táblázat kötet megváltozott” felirat olvasható. És így a táblák növekednek, és pontosan a csúcstalálkozón vagyunk, amikor az SQL utasítást értelmezzük, az optimalizáló kiválaszt egy végrehajtási tervet vagy egy másik végrehajtási tervet.
Szerencsére ezen a héten itt, hétfőn flip-floppy, tehát jó időben volt. Sajnos ez ismét flip-flop, és tudod mit, a végfelhasználók elkezdenek előre látni a képernyő lefagyását, és elkezdenek újból beküldeni a képernyőt, és fel-és felfelé tolják a végrehajtás számát. Nagyon sok részletünk van, de ennek a problémanak a megoldására, majd a jövőbeni elkerülésére egy további információra van szükségünk. És ez megmutatta nekem a végrehajtási tervek összehasonlítása során. Március 5-énth amikor gyors és hatékony volt, a bal oldalon a végrehajtási terv látható. Amikor március 12-én lassú és nem volt hatékonyth, láthatja, hogy szűrőcsatlakozást hajt végre. A szűrőcsatlakozás sokkal több CPU-felhasználást eredményez, sokkal több munkát végez. Az eredmény azonos, csak sokkal több munkát végez. Olyan, mintha elmenne, és egyszerre csak egy összetevőt szerezzen be, ahelyett, hogy a kamrába megy, és egyszerre megszerezné az összes összetevőt. És tehát van egy ilyen hatékonyabb módszer erre. Most, hogy általában ezt tudta, a DBA képes volt a lekérdezési tervre, hogy elkerülje ezt a lassú végrehajtási tervet, és bekapcsolódjon a gyors, nagy teljesítménybe.
Most a következő típusú háborús történet a „Jelentések elkéstek” volt. Azt hiszem, sok ember képes azonosulni ezzel a forgatókönyvvel. Lehet, hogy ad hoc jelentést készít, használhat olyan eszközt, mint az NVISION, és lehet, hogy van egy harmadik féltől származó jelentési eszköz. És ami történik, az eszköz fejleszti az SQL-t. És az SQL-t gyakran nem igazán kódolják. Ez vonatkozhat egy olyan helyzetre is, amikor, tudod, van valamilyen harmadik féltől származó alkalmazás is, igaz, ahol az SQL nem házon belül van írva, és így DBA-ként: „Nem ellenőrzem az SQL-t, mi Mit fogok tenni vele? ”Nos, a Precise olyan valamit nyújt, amit nem ismerek más adatbázis-eszközről, és ez egy objektum nézet. Ajánlásokkal és modellezéssel kombinálva. És tehát amit tehetünk, az valójában a látótávolságot fordítja a fején. Ahelyett, hogy csak a tevékenységet nézzük meg, vizsgáljuk meg, mi az a tárgy, amely a legnehezebb a rendszeren? És a képernyő alsó részén az SQL sorrend és a „MS-SQL” oszlop látható. És a megrendelési sor táblája tízszer nagyobb, mint a rendszer többi táblája. Úgy gondolom, hogy amit a felső felében is észre fog venni, a helykiosztás egyre növekszik, és megnézheti a szerver specifikációit is, hogy melyik szoftver verziót futtatjuk. A pontos ellenőrzi az elsődleges beállítások nyomon követett változásait. Ismét az ok és a következmény.
Most, amikor a megrendelési sor táblájára koncentrálom, amit tudok tenni a részletes történelmi lerakatommal, valóban össze tudom korrelálni az SQL utasításokat, amelyek ellentétesek a megrendelési sor táblázatával. És elkezdheti vizsgálni az SQL utasítások hol található záradékát. És észreveszi, hogy ahol a záradék nagyon hasonló a különböző SQL utasítások között. És azt javaslom nektek, hogy a felvételi rendszerében ugyanaz található. Mivel az üzleti felhasználók, az üzleti elemzők elemzést akarnak végezni, mint például az összesített üzleti tevékenység az elmúlt napon, a múlt héten, az előző hónapban, az utolsó negyedévben, az előző évben. Látni fogja nagyon hasonlókat, ahol a záradékok rendezése, csoportosítás szerint történik, és ez azt jelenti, hogy lesznek bizonyos indexek, amelyeknek értelme van az SQL utasításoknak.
Tehát a Precise rendelkezik ajánlómotorral, láthatja a jobb felső sarokban, és mit tehetünk, az valójában ajánlások megszerzése. Mondja: „Hé, futok az összes SQL utasításon, milyen indexek kezelnék őket?” Az indexeket Önnek mutatják be, és valójában láthatja a DBL-t. Most a Precise csak olvasható, nem nyújt lehetőséget egy gombra kattintásra és az index létrehozására, de ezt elég könnyű megtenni a Precise-en kívül. De itt a döntő jelentőségű dolog, hogy a Pontos lehetővé teszi a változások kiértékelését és modellezését, tehát a képernyő bal alsó sarkában van ez az Értékelés gomb. És mit csinál ez, az megmutatja az SQL utasításokat az előtte és utána.
Nézzük meg ezeket az SQL utasításokat. Látja itt ezt az oszlopot, amelyben az „MS-SQL-ben” felirat van, és egy óra, négy perc? Ez a legfelsõbb SQL utasítás végrehajtja vagy kb. 64 percnyi erõforrást igényel. És a tervezett javulása 98 százalék. Ezek a változások órányi feldolgozási költségeket takarítanak meg. A következő SQL utasítás 27 perc, és alapvetően egyharmadot takarít meg. Ez körülbelül tíz percig tart. Összegezve, ténylegesen órákat és órákat takarít meg a feldolgozás során ezekkel a javasolt változtatásokkal. És így képes megismerni ezt az elejétől, modellezni. Használhatja a „mi lenne, ha” képességet is, ha azt akarjuk mondani: „Nos, nem akarom elkészíteni azt az indexet, vagy mi történik, ha megváltoztatom az oszlop sorrendjét?” És így tudom használni ezt a modellezési képességet hogy pontosan megtudja, mi folyik itt.
A másik döntő jelentőségű az, hogy a változtatás végrehajtásakor ténylegesen mérni tudok egy SQL-utasításra. Látta az SQL utasítások előzményeit az előző példában, és valóban meg tudom ellenőrizni, hogy elértem-e a megtakarításokat, amelyeket modelleztem. És így a visszajelzés, a visszacsatolási kör kitöltése elengedhetetlen.
Rendben, itt van a végső példa, amelyet neked fogok mutatni. Ez egy SAP üzlet, és tudod, nagy átalakításra indultak, valamilyen dolgot csináltak egyedi tranzakciókkal, és alapvetően a végfelhasználó volt elégedetlen a teljesítménnyel. És tehát az, amit tettünk, arra tudtunk összpontosítani, amit a végfelhasználó tapasztalt. És a lista tetején látható a „VÁLASZTÁS” felirat, és a válaszidő valamivel több mint 61 másodperc. Ennek a dolognak egy percet vesz igénybe a végrehajtás. Most láthatjuk, hogy van egy halmozott oszlopdiagram, amely az SAP-hoz irányul. A jobb oldalon az ügyfélidejét, a sorba állítási időt mutatja. A kék az alkalmazás ideje és egy SAP környezetben, azaz az ABAP-kód, majd az adatbázis. Tehát az adatbázis, tudod, lehet Oracle, lehet SQL, lehet HANA. Alapvetően képesek vagyunk ezt megmutatni.
Most, amit a Precise-vel csinálunk, arra összpontosítunk, hogy az adott tranzakció és a felhasználó számára milyen SQL utasítások jönnek elő. Még egyszer, hogy a pontok összekapcsolása érdekében. Most ez a felső SQL utasítás, láthatja, hogy körbe van állítva, két milliszekundumban fut. Valójában nem hibáztathatja az adatbázist, ha az ilyen gyorsan fut. A végrehajtások száma nagyon magas. Valójában visszatérhetünk az ABAP kódolóhoz, és azt mondhatjuk: „Hé, mi folyik itt?” Valójában azt találtuk, hogy az adatbázisban lévő kódot rossz helyre helyezték, rossz hurokba fészkelte a hurokban, készítettük a megváltozzunk, majd meg tudjuk mérni utána. Valójában láthatja, hogy mi az előadás. Nem csak az SQL utasítás szintjén, hanem az egyedi kód szintjén is. És így élhettek négy és fél másodperces végrehajtási idővel. Tehát ez csak néhány példa arra, hogy miként lehet a Precise tőkeáttételét felhasználni. Csakúgy, mint egy gyors áttekintés, a Precise a teljesítményt hely szerint, a végfelhasználói azonosítón keresztül mutatja meg, és az alkalmazásköteg segítségével biztosítja a megfelelőséget. Lehet fúrni a kiváltó okot. És azt hiszem, hogy az egyik nagy különbségtétel nemcsak az SQL utasítás, hanem az is, hogy miért lassan fut az SQL utasítás, ismerete, képesnek kell lennie arra, hogy azonosítsa a vitatást, és alapvetően további lehetőségeket kínáljon a problémák megoldására. Ez az, amit a Precise kínál, és tudod, hogy könnyű módon fogyaszthat bennünket, vagy ha nagyon mély, nagyon kihívásokkal küzdő problémái vannak, szeretjük ezeket is felvenni.
Eric Kavanagh: Rendben, azt kell mondanom, hogy ez fantasztikus részlet volt, Bill. Köszönjük, hogy megmutatta ezeket a képernyőképeket. És a nézőpontomból valóban teljesítette azt, amit az óra tetején magyaráztam, azaz az első számú, hogy megfelelő eszköznek kell lennie. Szüksége van egy eszközre, amely lehetővé teszi az egyenlet összes elemének azonosításához szükséges összegeket, amint valaki egy filmben mondta, ez valami vicces volt. De hadd menjek tovább, és adjam át Deznek, mert fogadom, hogy van néhány kérdése az ön számára, és szeretnék még egy ilyen csúsztatást beilleszteni, csak vizuális cukorka céljára. Valójában, tartsatok, hadd vigyem vissza. Dez, biztos vagyok benne, hogy van néhány kérdése, vedd el.
Dez Blanchfield: Igen, igen. Ez az eszköz hosszú utat tett meg, mivel eredetileg tudtam róla, és nem tudtam, hogy valójában olyan mélyre került a kötegbe. Ez nagyon elképesztő. Csak nagyon gyorsan, néhány dolog. A telepítési modell, nagyon gyorsan, egy-két perc alatt, felvázolja a hagyományos vagy tipikus telepítési modellt. Megemlítette, hogy virtuális gépként is elérhető. Futtatható a felhőben. Azt hiszem, az egyik feltehetően felmerülő kérdés, és azt hiszem, hogy volt néhány kérdés, amelyek felmerültek a Kérdések és válaszok részben. Csak azért, hogy röviden összefoglaljuk őket, tehát a szokásos telepítési modell és a szükséges tengely típusa van-e hagyományosan a helyszínen, házigazda vagy a felhőben? Milyen típusú telepítési modellek vannak, amelyeket általában lát? És milyen tengely szükséges ahhoz, hogy működjön? Meg kell változtatnunk a biztonság szintjén a hálózati hozzáférés körül, és így tovább? Vagy csak végfelhasználóként viselkedik?
Bill Ellis: Igen, tehát jelenleg a telepítések nagy része előzetesen készül. Egyre több ember helyezi az alkalmazás verem elemeit a felhőbe, és így is kezelhetjük ezt. A telepítéshez szükségünk van egy kiszolgálóra a futtatáshoz, amely megfelel bizonyos előírásoknak. A történelmi lerakat tárolásához adatbázisra van szükségünk, tehát az előfeltételek teljesítése az első lépés. A következő dolog az, hogy feltétlenül ismernünk kell magát az alkalmazást, és a telepítést varázsló vezérli, és alapvetően kitölteni a kitöltéseket. Mivel a kapott információk mélységét tudjuk, a webes folyamat szintjétől a végrehajtó kódig, bizonyos privilégiumokkal kell rendelkeznünk. Van egy biztonságos adatmodell vagy biztonsági modell, azt kell mondanom, mert az ügynökök olyan hitelesítő adatok alapján futnak, amelyek teljesen elkülönülnek az emberektől, akik a tranzakciók metaadatait használják stb.? A pontos TCP-n keresztül kommunikál IP-n keresztül, ezért bizonyos portok nyitva tartására van szükségünk. Gyors példa, mint például az alapértelmezett portunk a 2702. Ez a fajta részletes cucc valami, ha az emberek érdeklődnek, részletesebben bele tudunk kerülni. De általában nagyon gyors az értékbecslés. Ha valaki nagy problémával néz szembe, akkor gyakran telepíthetjük a dolgot, és órák alatt rávilágíthatunk egy helyzetre.
Dez Blanchfield: Igen, határozottan megértem ezt az értelmet. A telepítési modellben egy nagyon nagy léptékről és legfeljebb 500 példányról beszélt, és hogyan lehet ezt egyesíteni. A belépési szinten hogyan néz ki, ha valaki akar - mert tudom, hogy az IDERA nagyon nagy szerepet játszik az ingyenes próbaverziókban, ingyenes demókban, és emlékszem, hogy a honlapon szinte mindent meg lehet játszani. Az itt élő népek számára, és azt hiszem, korábban hiányoztam, de azt hiszem, felmerült egy kérdés, hogy hogyan néz ki egy tipikus oldal, és hogyan férnek hozzá az emberek ehhez, és elkezdenek játszani vele, és megszerezni ezt a típust a tapasztalatok alapján megtudhatja, hogy van-e módjuk a teljesítményproblémák megoldására? Letölthetik az ODS-t, és megpördíthetik a hipervizorukon, a Hyper-V-n vagy a laptopjukon, vagy szükségük van-e dedikált gépen a futtatásukhoz? Ön már körvonalazta az architektúrát, de nagyon röviden, egy-két perc alatt, hogyan néz ki a belépő szintű telepítés, ha például a koncepció igazolására van szükség?
Bill Ellis: Igen, szóval a modellünk kissé különbözik az IDERA eszközöktől. Mi jobban beleillünk az Embarcadero forgatókönyvébe, ahol kapcsolatba szeretnék lépni az egyik értékesítési képviselővel. Csak azt szeretnénk, hogy megvitassák veled a kihívásokat, és akkor tudjuk, hogy általában az egyik SE-t kiosztanák, és alapvetően a telepítésen keresztül működne valakivel. Általában nem futtatja a Precise szoftvert a laptopján. A gyűjtemények elvégzéséhez virtuális gépet vagy szervert szeretne az adatközpontban, ahol az alkalmazás él. De mi minden lépésben segítsünk. Ha valaki érdekli ennek folytatása, akkor feltétlenül vegye fel a kapcsolatot az IDERA-val.
Dez Blanchfield: Az egyik döbbenetes dolog az volt, hogy értem, hogy sok, amit ma lefedettünk, a teljesítményproblémákra való reagálás körül szól.De nekem úgy tűnt, hogy az élő környezetben, amikor az emberek használják őket, az első diavetítésként valaki felveszi a telefont, és azt mondja: „Az alkalmazás lassan fut, segítsen.” De engem megdöbbent, hogy az alkalmazások előzetes kiadásakor vagy frissítések vagy új javítások és javítások révén egy csomó kapacitástervezésen és stressztesztelésen ment keresztül, és pontosan megnézheti az egész környezetet, és ténylegesen megtalálhatja a problémákat, még mielőtt a végfelhasználókat környezetbe helyezi. Ez egy olyan használati eset, amelyet már látott, vagy az emberek is ezt teszik, vagy nem ez egy tipikus használati eset?
Bill Ellis: Teljesen azt szeretnénk, hogy a Precise-t az alkalmazás fejlesztési életciklusa vagy a frissítés életciklusa alatt is használjuk. A pontos skálázhatóságot nyújt, amely megmutatja a válaszidővel lefedő végrehajtások számát. Nyilvánvaló, hogy ha mind a végrehajtások száma, mind a válaszidő növekszik, akkor nem méretez, és meg kell tennie valamit. Az ilyen típusú dolgok óriási segítséget nyújtottak. Azt hiszem, ez egy kicsit kevésbé igaz, de amikor az emberek elkezdték a VMware-hez termelési alkalmazásokat helyezni, egy kicsit tétováztak, és mint tudnád, az első dolog, amilyenek lennének: „Ó, ezt át kell helyeznünk fizikai. ”És amit ténylegesen megtehetünk, az az, hogy megmutatjuk, mennyi az erőforrás-fogyasztás, így hatékonyságosabbá teheti az alkalmazást. Az alkalmazás életciklusának minden lépésénél feltétlenül használni akarja a Precise szoftvert. De azt kell mondanom, hogy a termelés valójában ott van, ahol a teljesítmény a legfontosabb, és a Precise a napi 24 órás gyártásfigyelésre irányul, és így valójában nem akarja a termelési alkalmazásokat láthatóság nélkül futtatni.
Dez Blanchfield: Teljesen. Egy másik gyors kérdés csak a specifikus teszt, a bevándorlás, az UAT és így tovább - értem, nagyszerű, ha van ez az eszköz, és azt gondolom, hogy az alkalmazásfejlesztők nagyon szeretnék, ha ehhez hozzáférést kapnak a fejlesztési életciklus életciklusain keresztül. . A most látott bonyolultabb architektúrákkal, így a dedikált szolgáltatásról a virtualizációkra és a virtualizációra költözöttünk, és most átállunk a kiszervezés felhőalapú hostingba történő átvételére, és tudjuk, hogy egy átállást is látunk. a konténerszállításig. Látta már, hogy sokan ezt alkalmazzák, és modellezik a régiók vagy zónák fajtáit, így lehet valaki - és Ausztráliában egy nagyon nagy kérdés van a magánélet körül, és tudom, hogy Európában ugyanaz, és azt hiszem, az Egyesült Államokban, ahol az adatoknak, amelyek személyesen azonosítani tudnak, biztonságosabb környezetben kell lenniük a tényleges alkalmazásréteg és a webes réteg között. És tehát most vannak ezek a telepítések, ahol az emberek tárolhatják adatbázisát és alkalmazásuk tartalmát belsőleg, de feltehetik webes rétegüket és szállítási végüket és alkalmazásukat, és így tovább egy felhő-szolgáltatónál, például az Azure vagy az Amazon Web Services és a szoftver . Hogyan működik ez a normál telepítésnél? Ez az eset, amikor éppen újabb gyűjtőkészletet kaptál a térségben, és csak néhányat gyűjtöttek össze? Hogyan néz ki ez a pontos világban a mai modernfajta bimodális megközelítésben, amikor a régi örökölt tárgyak informatikáját egy helyen üzemeltetik, és áruk néha a felhőben vannak?
Bill Ellis: Igen, tehát támogatjuk a vegyes környezetet. Egy szempont, amelyet figyelembe kell venni, hogy a felhő-szolgáltatókkal különböző szerződések vannak. Néhányuk nem engedi meg semmilyen ügynök vagy bármilyen külső megfigyelést a felhőben. A Precise telepítéséhez és figyelemmel kíséréséhez olyan típusú szerződésre van szüksége, amely lehetővé teszi az ilyen típusú hozzáférést. Határozottan vannak bizonyos korlátozások, amelyeket néha át kell dolgoznunk, tehát ezek fontos kritériumok, amelyeket figyelembe vesz, amikor azt hiszem, először aláírja ezeket a szerződéseket, majd / és / vagy ha ki kell telepítenie a Precise szoftvert.
Dez Blanchfield: Igen, számos példát láttam, amikor még a hagyományos adatbázis-környezettel is megvásárolom a szolgáltatás részeként, különös tekintettel az Azure-hoz, amikor a HDInsight vagy az SQL szereti a szolgáltatást, mint például egy platformon, a szokásos eszközeid csak annyira mélyre merülhetnek, mert nem igazán szívesen néznek meg a motorháztető alatt. És így végül egy bizonyos szintet vagy mélységet ér el, amelyet megfigyelhet, és olyan hirtelen, amit csak nem lát a varázsfüggöny mögött. Ez az önkiszolgálás? Ez hagyományosan valami olyan működik-e egy hálózati üzemeltetési központban, ahol csak a műszaki csapat, a CIO munkatársai férhetnek hozzá, vagy ez szintén olyan szintű hozzáférést biztosíthat a végfelhasználók számára? Lehet, hogy nem feltétlenül a recepció és a hagyományos HR és pénzügyekkel foglalkozó emberek, hanem az ügyesebb felhasználók, akik ezt csinálják, például az adattudósok, a biztosításmatematikusok, a statisztikusok és az emberek, akik igazán nagy munkaterhelést végeznek. Előfordulhat, hogy hozzáférhetnek valamilyen önkiszolgáló hozzáféréshez, hogy megnézhessék, mi történik, amikor ezeket a nehéz kérdéseket lefolytatják, és hol jelentkezik a fájdalom, így meg tudják hangolni, hogy hogyan terjednek munkaterhelésük?
Bill Ellis: A Precise szolgáltatásban nagyon jó a biztonság, így beállíthat különböző szintű hozzáféréssel rendelkező felhasználókat. A legalapvetőbb szinteken csak a műszerfalak biztosítják a felügyeletet. És akkor a részben, tudod, ha valaki be akarta venni a szakértői GUI-t, korlátozhatja azt, amit látnak és mit tudnak. És visszatérve az előző kérdésre, hogy tudod, hogy az egészségügyben megvan az összes HIPAA törvény, és ezért határozottan vannak bizonyos megfontolások, és valójában van néhány telepítési lehetőség, hogy mindkét környezetben együtt tudunk dolgozni. Az egyik dolog, amelyet figyelembe kell venni az ebben a bemutatóban látott adatokkal, az a teljes metaadat, nem a táblák tartalma, tudod, és valójában nem fog belemenni az ilyen típusú adatvédelmi aggályok.
Dez Blanchfield: Igen, én ezt tettem. Eureka pillanatom történt a képernyő negyedik vagy ötödik diájáról, és rájöttem, hogy csak a teljesítményt húzza, nemcsak, hanem a teljesítményadatokat is húzza, dolgokat húz, mint mondtad, a metaadatokat a verem különböző szintjein, valójában nem a tartalmat nézi. És azt hiszem, ez érdekes dolog, mert ez az egyik eszköz, ahol rövid távon telepítheti és megnézheti a környezetben zajló eseményeket, de nem kell hozzáférnie magának az adatnak. Azt is megnézheti, hogy miként futnak a személyzet. Az utolsó dolog, azt hiszem, nagyon gyorsan, és aztán visszaadom Ericnek, így ha kérdése van, akkor vigye Rebecca-t, hogy foglalja össze, korábban már említette, hogy a felső névleges, előfordulhat, hogy ez még a dolgok megfigyelési oldaláról is észrevehető fej fölött, és csak a háttér megfigyelésekor, vagy olyan elhanyagolható mennyiségű fölött van, hogy csak nem érdemes megfontolni?
Bill Ellis: Igen, úgy gondolom, hogy az adatbázis szintjén, tudod, az egyes technológiák kissé különböznek egymástól. Az adatbázis szintjén a Precise nagyon jól ismert, hogy legyőzi a legalacsonyabb fölött. A középső rétegben van, tudod, van egyfajta kiegyensúlyozó cselekedet, tudod, nemcsak precíz, hanem mindenkire vonatkozik, a láthatóság és a feje fölött. És tehát az egyik dolog, hogy számos kifinomult eszközt kínálunk annak ellenőrzésére, hogy mi a felesleges. Termelésre terveztük, és tudod, határozottan hasznos annyi problémát kipróbálni a fejlesztési és minőségbiztosítási rügyekben, de, tudod, nincs semmi olyan, mint tudni, hogy mi történik a termelésben.
Dez Blanchfield: Eric, neked is van valami utolsó kérdése?
Eric Kavanagh: Igen, csak azt mondom, hogy szerintem nagyszerű munkát végzett rámutatva, hogy a con valójában a legfontosabb, és ez majdnem olyan, mintha a tárgyak internetének korszaka felé haladnánk, mindent műszeresen akarsz. És azt hiszem, hogy a gyártásban most a szabvány az, hogy ezt tegyék, ami jó hír, ugye? Mert azt szeretné, hogy képes legyen információkat gyűjteni ebből a különféle környezetből, és összefűzni őket. És azt hiszem, csak átadom neked néhány nyomon követési megjegyzésért. Srácok, arra összpontosítanak, hogy egy vizuális felületet biztosítsanak, amelyen keresztül egy elemző, egy informatikai elemző alapvetően figyelemmel kísérheti és elemezheti a komplex környezetben zajló eseményeket, és kitalálhatja, hogy mit változtasson. Mert nem csak eszköz. Neked kell az eszköz, de szükséged van arra a személyre, aki bele fog mélyedni a részletekbe és megtalálni a válaszokat, igaz?
Bill Ellis: Igen, úgy látom, hogy felmelegszik, és fontossági sorrendbe állítja, hol van a legtöbb visszavásárlás, tudod? Ha kiderül, hogy más a helyzet, mert nem minden probléma van az adatbázisban. Ha az adatbázis, akkor tudod, a dolgok másodperces tizeddel hajtódnak végre, de az alkalmazás szintjén a dolgok három másodpercig tartanak, ez az, ahol a legtöbb visszavásárlás történik. És olyan fajta, hogy képes elszigetelni a probléma rétegét, és akkor mi történik a rétegben, hogy valóban arra összpontosítsunk, hogy hol van a visszavásárlás. Ez valóban felgyorsítja az alkalmazás felbontását és optimalizálását, és sokkal gyorsabb, sokkal jobb és sokkal szórakoztatóbb, mint amilyenek az emberek összegyűltek egy konferenciaterembe: "Nos, nem én vagyok, hanem valaki másnak kell lennie."
Eric Kavanagh: Úgy van. Másnap láttam egy nagyszerű mémét, amely valami olyasmit mondott: „Legyen tájékozott, nem csak véleményes.” Bemegyél egy találkozóra, megvan az információ, rámutathatsz az adatokra. Ez a kulcs és odaérünk, köszönöm a jóságnak. Oké, emberek megyünk előre, és összefoglaljuk, de ezeket az internetes adásokat archiváljuk későbbi megtekintés céljából. Nyugodtan nézd meg bármikor. Az összes webes sugárzást felsoroljuk, a Hot Tech sorozatot és a Briefing Room sorozatot a Techopedia.com webhelyen, szóval ugorj online, és ellenőrizd ezeket az embereket. Ezzel búcsút fogunk nyújtani Önnek. Köszönöm a mai idejét, Bill. Neked és minden kemény munkájának köszönhetően, Dez. És legközelebb beszélünk veled, emberek. Vigyázz magadra. Viszlát.