Di Techopedia Staff, 2 novembre 2016
Takeaway: l' host Eric Kavanagh discute le prestazioni delle applicazioni e come migliorare l'efficienza con il Dr. Robin Bloor, Dez Blanchfield e Bill Ellis di IDERA.
Al momento non sei collegato. Accedi o registrati per vedere il video.
Eric Kavanagh: signore e signori, ciao e bentornati di nuovo a Hot Technologies. Si Certamente! Mi chiamo Eric Kavanagh, sarò il tuo ospite per un altro webcast oggi in questa serie davvero divertente ed eccitante che abbiamo come complimento per la nostra serie Briefing Room. Il titolo è "Accelerazione delle applicazioni: prestazioni più veloci per gli utenti finali". Forza gente, chi non lo vuole? Se sono il ragazzo là fuori che aiuta la tua applicazione a correre più veloce, penso di essere il ragazzo che mi compra le birre al bar dopo il lavoro. Deve essere una cosa piuttosto interessante entrare e accelerare l'applicazione di chiunque.
C'è davvero una diapositiva sulla tua, colpiscimi su Twitter @Eric_Kavanagh. Cerco sempre di seguirmi e ripeto sempre in tweet se mi menzioni, quindi sentiti libero di menzionarmi.
Lo scopo di questo spettacolo è quello di concentrarsi su diversi aspetti della tecnologia aziendale e aiutare davvero a definire determinate discipline o determinati volti, se vuoi. Molte volte i venditori risponderanno a determinati termini di marketing e parleranno di come fanno questo o quello o qualcos'altro. Questo spettacolo è stato davvero progettato per aiutare il nostro pubblico a capire cosa deve avere uno strumento software per essere un leader nel suo spazio. Il formato di questo essere due analisti. Ognuno va per primo, a differenza della Briefing Room in cui il venditore inizia per primo. Ognuno dà la propria opinione su ciò che pensano sia importante per te conoscere un particolare tipo di tecnologia.
Oggi stiamo parlando dell'accelerazione delle applicazioni. Avremo notizie di Dez Blanchfield e anche del dottor Robin Bloor - oggi siamo in tutto il mondo - e poi Bill Ellis si connetterà dalla grande area della Virginia. Detto questo, lo consegnerò al nostro primo presentatore, il dottor Bloor. A proposito, abbiamo twittato l'hashtag di #podcast, quindi sentiti libero di twittare. Portalo via.
Dr. Robin Bloor: Okay, grazie per questa presentazione. Prestazioni delle applicazioni e livelli di servizio: questa è una specie di area, ho lavorato molto in quest'area nel corso degli anni, nel senso che in realtà ho fatto moltissimo lavoro nel monitorare le prestazioni e lavorare in una in un modo o nell'altro, come provare a calcolare quei livelli. Va detto che fino a quando - un tempo fa, questa era, poco fa, in cui le persone costruivano sistemi in silos. Fondamentalmente, la quantità di lavoro che devono effettivamente fare per far funzionare un sistema ragionevolmente bene se fosse in un silo non era in realtà troppo difficile perché ci sono pochissime, piccolissime quantità di variabili da prendere in considerazione. Non appena siamo stati adeguatamente collegati in rete, l'orientamento interattivo e di servizio è entrato nell'equazione. È diventato un po 'difficile. Le prestazioni possono essere monodimensionali. Se pensi solo a un'applicazione che esegue ripetutamente un determinato percorso di codice, farlo ragionevolmente, in modo tempestivo, sembra una cosa unidimensionale. Non appena inizi a parlare dei livelli di servizio, in realtà stai parlando di più cose in competizione per le risorse del computer. Diventa multidimensionale molto rapidamente. Se si inizia a parlare di processi aziendali, i processi aziendali possono essere collegati tra loro da più applicazioni. Se stai parlando di un'architettura orientata ai servizi, una determinata applicazione può effettivamente accedere alle funzionalità di più applicazioni. Quindi diventa una cosa molto complicata.
Ho guardato - molto tempo fa, ho disegnato questo diagramma. Questo diagramma ha almeno 20 anni. Fondamentalmente, lo chiamo il diagramma di tutto perché è un modo per guardare tutto ciò che esiste nell'ambiente IT. Sono in realtà solo quattro pezzi: utenti, dati, software e hardware. Naturalmente cambiano nel tempo, ma in realtà ti rendi conto quando guardi a questo che c'è un'esplosione gerarchica di ognuno di questi pezzi. Un hardware sì, un hardware può essere un server ma un server è composto da più CPU, tecnologia di rete e memoria, e questo, come un sacco di controller, come succede. Se lo guardi davvero, tutto si scompone. Se in realtà stai pensando di provare a orchestrare tutto ciò, per quanto riguarda i dati che cambiano, le prestazioni del software cambiano, perché l'hardware cambia e così via e così via, stai effettivamente guardando una situazione multi-variata incredibilmente difficile. Questa è la curva della complessità. Ovviamente è una curva di complessità per quasi tutto, ma l'ho visto disegnare più volte quando si parla di computer. Fondamentalmente, se si posizionano nodi su un asse e le connessioni importanti sull'altro asse, si finisce con una curva di complessità. Quasi non importa quali siano i nodi e le connessioni e che farà se si desidera una rappresentazione della crescita del volume nella rete telefonica.
In realtà, quando si parla di nodi nell'ambiente informatico, si parla di cose individuali che si preoccupano l'una dell'altra. Complessità, risulta essere, una questione di struttura della varietà e dei vari vincoli a cui stai cercando di obbedire. Inoltre, i numeri. Quando i numeri aumentano, diventano pazzi. Ieri ho fatto una chiacchierata interessante, stavo parlando con qualcuno - non posso menzionare chi fosse, ma non importa davvero - stavano parlando di un sito che aveva 40.000 - cioè quattro zero, 40.000 - istanze di database nel sito. Basti pensare a questo: 40.000 database diversi. Ovviamente l'unica cosa che avevamo: ovviamente avevano molte, molte migliaia di applicazioni. Stiamo parlando di un'organizzazione molto grande, ma non posso nominarla. In realtà lo guardi e stai effettivamente cercando, in un modo o nell'altro, di ottenere livelli di servizio che saranno adeguati su tutta la linea per alcuni utenti multipli, con più aspettative diverse, se preferisci. È una situazione complessa e tutto ciò che sto davvero dicendo è che questa roba è complessa. I numeri aumentano sempre. I vincoli sono determinati dai processi aziendali e dagli obiettivi aziendali. Avrai notato che le aspettative cambiano.
Ricordo non appena Gmail, Yahoo mail e Hotmail, tutti quei sistemi di posta elettronica sono arrivati, le persone hanno iniziato ad aspettarsi che i loro sistemi di posta interna all'interno dell'organizzazione meritassero i livelli di servizio di queste enormi operazioni con vaste server farm all'esterno l'organizzazione e ha iniziato a subire pressioni per far accadere tutto quel genere di cose. In realtà, gli accordi sul livello di servizio sono una cosa, ma le aspettative sono un'altra cosa e si combattono all'interno di un'organizzazione, una cosa scomoda. Ecco solo una prospettiva commerciale. In alcuni sistemi, il tempo di risposta ottimale è un decimo di secondo del tempo di risposta umano. Un decimo di secondo è il tempo impiegato da un cobra per morderti. Se ti trovi di fronte a un cobra e decide di morderti, è troppo tardi, lo farà perché non puoi rispondere in un decimo di secondo. Un decimo di secondo è circa il tempo impiegato dalla palla per lasciare la mano del lanciatore per raggiungere il ragazzo con la mazza. Fondamentalmente, quando vede la palla lanciata, deve rispondere esattamente in quel momento. Risposta umana, una specie di cosa interessante. Da software a software, ovviamente, possono avere aspettative più elevate.
Quindi ti imbatti in alcune situazioni che penso siano quelle del mercato, in cui il primo è il valore aziendale. È come se volessi vendere un determinato titolo nel mercato azionario sia probabilmente inferiore, ad esempio perché pensi che stia diminuendo e molte altre persone pensano che stia diminuendo, ottieni il prezzo migliore se arrivi sul mercato prima. Ci sono molte situazioni, la pubblicazione di annunci e cose del genere, una situazione molto simile. Hai questo movimento in termini di aspettative a livello di servizio. Hai una cosa che è una specie di soffitto di vetro per la risposta umana. Una volta che è un software per software, se hai questa situazione massima, non esiste un livello di servizio migliore. Più veloce di tutti gli altri è il migliore.
Ok, questa è, credo, la diapositiva finale che stavo facendo, ma questo è solo per darti un quadro generale della complessità, una volta che hai effettivamente esaminato i requisiti di un'organizzazione, il servizio. Salendo sul lato sinistro qui, hai la gestione del sistema, che è un insieme di software che serve alla gestione del servizio, che sta cercando di gestire un livello di servizio. Inoltre, hai una gestione delle prestazioni aziendali. Quindi se guardi in basso qui, l'area dell'automazione della gestione dei servizi, hai servizi frammentati che si evolvono in servizi standardizzati, se in realtà ti interessa investire in questo genere di cose, che si evolvono in servizi integrati, che si evolvono in servizi ottimizzati . Principalmente ciò che la gente ha fatto è, solo nell'angolo in basso a sinistra di questo. Forse un po 'di gestione del servizio. Gestione delle prestazioni aziendali, molto rara. Frammentato, quasi tutto. Un mondo perfetto riempirebbe quella griglia. Strumentazione - Ho menzionato un problema di subottimizzazione. È possibile ottimizzare parti di un sistema e non va bene per l'intero sistema. Se rendi il cuore ottimale, il tuo sangue potrebbe circolare troppo velocemente per il resto dei tuoi organi. Questo è un problema con grandi organizzazioni e livelli di servizio. Chiaramente non si otterrà nulla senza strumenti sofisticati perché le variabili sono appena state ottenute - beh, ci sono troppe variabili da provare e ottimizzare.
Detto questo, passerò a Dez che parlerà di qualcos'altro interamente, si spera.
Dez Blanchfield: Grazie, Robin. Come il dottor Robin Bloor, ho passato troppi anni a pensare alle prestazioni di sistemi molto complessi su larga scala. Probabilmente non ha le stesse dimensioni di Robin, ma le prestazioni sono un argomento quotidiano ed è parte del nostro DNA desiderare prestazioni, per ottenere il meglio da tutto. In effetti, ho usato un grafico di una delle mie cose preferite al mondo, le corse automobilistiche di Formula I, in cui l'intero pianeta è fermo per un po 'e guarda le macchine girare rapidamente in tondo. Ogni singolo aspetto, non c'è nessun aspetto della Formula I che non riguardi specificamente le prestazioni. Molte persone fanno la cacca per questo sport perché pensano che sia uno spreco di denaro. Si scopre che l'auto che guidiamo ogni giorno per far cadere i bambini a calcio nei fine settimana e a scuola gli altri giorni, è derivata dallo sviluppo e dalla ricerca basati sulle prestazioni. È un po 'la vita delle corse automobilistiche di Formula I. La tecnologia di tutti i giorni, la scienza di tutti i giorni, spesso viene da artisti del calibro di qualcosa che è stato focalizzato esclusivamente su alte prestazioni.
La realtà, tuttavia, è che il nostro nuovo mondo "sempre attivo", che richiede il 100% di uptime - come ha detto Robin in precedenza - con cose come l'introduzione della webmail e di altri servizi che diamo per scontati in uno spazio continuo, e ora ci aspettiamo che in la nostra impresa e ambiente di lavoro. La realtà è che alzarsi non significa sempre che stai rispettando il tuo contratto di servizio. Ho questa opinione sulla necessità di gestire le prestazioni delle applicazioni e la disponibilità degli accordi a livello di servizio ha subito un cambiamento fondamentale nell'ultimo decennio. Non stiamo più solo provando a preoccuparci delle prestazioni di un sistema. Quando il mondo fosse un po 'più semplice, potremmo avere una situazione in cui un singolo server che esegue più servizi può essere monitorato dal vivo ed è relativamente semplice da supportare. Potremmo - ed ecco il mio piccolo, le cose di cui ci preoccupavamo, ad esempio, quando ero un amministratore di sistema, molti anni fa - ci guardavamo intorno, il servizio è in genere attivo e risponde? Posso accedere ad un terminale per esempio? Il sistema operativo risponde e posso digitare i comandi? Le applicazioni sono attive e in esecuzione? Posso vedere processi e memoria nel fare cose e I / O attraverso la rete e così via? Nei giorni del mainframe si potevano sentire nastri che scorrevano con la cerniera lampo e la carta che ne cadevano.
Le app stanno rispondendo e possiamo accedere e fare qualcosa su di esse? Gli utenti sono in grado di connettersi ad alcuni di quei server? Si va avanti. Sono abbastanza fondamentali, lo sai. Poi alcuni divertenti - l'help desk è verde? Perché se no, allora tutto funziona bene e chi prenderà le ciambelle? La vita era davvero semplice a quei tempi. Anche a quei tempi, e poi parlo con 20-30 anni fa, la complessità era ancora molto alta. Potremmo, in modo relativamente semplice, gestire accordi a livello di servizio e tenere d'occhio le prestazioni. Non possiamo più farlo a mano, come alludeva Robin. La sfida è troppo grande. Il fatto è il momento in cui alcune buone app, amministratori, rete di sistema e database, gli amministratori possono monitorare e soddisfare gli SLA delle prestazioni. Gli SLA sono così lontani ora che ho lottato ieri sera quando stavo mettendo insieme le mie note finali per pensare persino all'anno in cui sono riuscito a guardare un sistema di uno stack molto complesso, a dargli un senso e persino a capire cosa fosse succedendo sotto il cofano, e vengo da un background profondamente tecnico. Non riesco a immaginare come sia affrontarlo quotidianamente ora in modo amministrativo.
Quello che è successo? Bene, nel 1996, le app basate su database sono state trasformate con il boom di Internet. Molti di noi ci hanno passato. Anche se non eri in giro per il boom di Internet, puoi semplicemente guardarti attorno e rendertene conto nella vita di tutti i giorni, che ora colleghiamo tutto a Internet. Credo che abbiamo un tostapane che a quanto pare ha la possibilità di accedere al Wi-Fi, il che è ridicolo, perché non ho bisogno del mio tostapane collegato a Internet. Negli anni 2000, in particolare nei primi anni 2000, abbiamo dovuto far fronte a questa enorme crescita della complessità fornendo prestazioni di servizio nel boom delle dot-com. Poi un'altra ridicola imbarazzante scintilla nel web 2.0, in cui sono nati gli smartphone e ora le applicazioni erano nelle nostre mani 24/7 e erano sempre attive.
È il 2016 adesso, ci troviamo di fronte a un altro pantano sotto forma di cloud, big data e mobilità. Questi sistemi sono così grandi che spesso sono difficili da comprendere e mettere in parole povere. Quando pensiamo al fatto che alcuni dei grandi unicorni di cui parliamo hanno decine di centinaia di petabyte di dati. Questo è l'intero spazio su disco e spazio di archiviazione solo per contenere e-mail, immagini e social media. O in alcuni casi, nella logistica dei trasporti e delle spedizioni, è tutto nel settore bancario, è dove sono i tuoi soldi, o dove si trova il tuo post o il tuo, dove si trova l'oggetto che hai acquistato su eBay. La prossima grande ondata che stiamo per affrontare è questa sfida molto pesante di internet delle cose.
Se ciò non fosse abbastanza grave, stiamo per costruire l'intelligenza artificiale e il calcolo cognitivo in quasi tutto. Oggi parliamo con Siri e i motori di Google. So che Amazon ne ha uno suo. Baidu ha uno di questi dispositivi con cui puoi parlare, lo convertono in testo che va in un sistema normale, il database fa una query e ritorna e inverte il processo. Pensa alla complessità che ne deriva. La realtà è che la complessità dell'attuale stack di applicazioni standard è molto al di là delle capacità umane. Quando pensi a tutto ciò che accade quando premi un pulsante sul tuo dispositivo smartphone o sul tuo tablet, ci parli, lo converti in testo, lo esegui fino a Internet in un sistema back-end, un front-end riceve che, lo converte in una query, esegue la query attraverso uno stack di applicazioni, passa attraverso un database, colpisce il disco, esce, e nel mezzo c'è una rete di carrier, c'è un centro di stato della rete locale. La complessità è pazza.
Lo affermiamo efficacemente come iperscale. La complessità e la velocità dell'iperscale sono solo lacrime per gli occhi. Le applicazioni e i database sono diventati così grandi e così complessi che la gestione delle prestazioni è in realtà una scienza in sé. Molti lo chiamano scienza missilistica. Abbiamo la tecnologia in loco, abbiamo la tecnologia in loco, abbiamo una gamma di opzioni di data center; fisico e virtuale. Abbiamo server fisici e virtuali, abbiamo cloud, abbiamo l'infrastruttura come servizio e la piattaforma come servizio e il software come servizio è una cosa che diamo per scontato. Quest'ultimo, il software come servizio, è diventato spaventoso qualche tempo fa, quando i CFO e parti dell'organizzazione hanno capito che potevano ritirare la loro carta di credito e semplicemente acquistare cose da soli e andare in giro per il CIO ed efficacemente abbiamo chiamato questo "ombra" IT ”e i CIO ora provano a liquidare questo controllo e a riprendere il controllo.
Nell'infrastruttura abbiamo una rete definita dal software, la virtualizzazione delle funzioni di rete, al di sotto della quale, probabilmente, finita, ora abbiamo micro servizi e app di servizi attivi. Quando fai clic su un URL, c'è un mucchio di logica aziendale che si trova alla fine di quell'URL che descrive ciò che deve effettivamente consegnarlo. Non ha necessariamente una logica precompilata che lo aspetta. Abbiamo database tradizionali da un lato che stanno scalando molto, molto grandi. Abbiamo altri tipi di infrastrutture ed ecosistemi di Hadoop nell'altro spettro che sono così grandi che, come ho detto, sai, le persone stanno parlando di centinaia di petabyte di dati ora. Abbiamo una mobilità complessa per quanto riguarda i dispositivi che portano in giro, laptop, telefoni e tablet.
Abbiamo BYOD in alcuni ambienti chiusi e sempre più ora, dal momento che le persone esperte di Gen Y stanno portando i propri dispositivi. Li lasciamo solo parlare con loro delle interfacce web. O su Internet o tramite Wi-Fi, abbiamo una connessione Wi-Fi gratuita nella caffetteria al piano di sotto mentre stanno prendendo il caffè. O il nostro Wi-Fi interno. La macchina-macchina è sempre presente. Non è direttamente parte di Internet delle cose, ma è anche correlato. L'Internet of Things è un gioco completamente nuovo di complessità che fa impazzire la mente. Intelligenza artificiale, e se pensi che ciò con cui stiamo giocando ora, con tutti i Siri e altri dispositivi correlati con cui parliamo sia complesso, aspetta di arrivare a una situazione in cui vedi qualcosa chiamato Olli che è un 3-D autobus stampato che impiega circa sei persone e può guidare da solo in città e puoi parlargli un inglese semplice e ti risponderà. Se colpisce il traffico, deciderà di svoltare a sinistra o a destra nell'area principale dove c'è traffico. Mentre gira e ti preoccupi del perché ha girato a sinistra o a destra sulla strada principale, ti dirà: “Non preoccuparti, sto per girare a sinistra. C'è traffico in arrivo e ci proverò. ”
Gestire le prestazioni di tutti i sistemi presenti e tutta la complessità, tracciare dove vanno i dati, se vanno nel database, tutte le interconnessioni e tutti i bit rilevanti è semplicemente sbalorditivo. La realtà è che la gestione delle prestazioni e degli SLA alla velocità e alla scala odierne richiede strumenti e sistemi, e per impostazione predefinita questo non è più qualcosa in cui penseresti che sarebbe bello avere uno strumento: è un prerequisito; è assolutamente necessario. Ecco qualcosa come un piccolo esempio, un elenco dei diagrammi di progettazione di applicazioni di alto livello per il cloud OpenStack, definito dal software open source. Questo è solo un grosso pezzo. Questo non è solo server e database. Questo è dove ogni piccola chiazza blu rappresenta gruppi di cose. In alcuni casi file e server o centinaia di database o ovviamente non più di decine di migliaia di piccoli pezzi di logica applicativa in esecuzione. Questa è una versione ridotta. È davvero sbalorditivo quando inizi a pensare alla complessità che si manifesta in questo. Oggi, anche solo nello spazio dei big data, inserirò solo alcuni screenshot dei soli marchi. Quando pensi a tutti i pezzi che dobbiamo gestire qui, non stiamo parlando solo di un marchio necessariamente, ma sono tutti marchi nel panorama dei big data e del marchio principale, non solo di quelli piccoli o open source. Sembri e pensi che sia una carta da capogiro.
Diamo un'occhiata a un paio di verticali. Prendiamo il marketing, per esempio. Ecco un grafico simile ma dalle pile tecnologiche disponibili solo nella tecnologia di marketing. Questo è il grafico 2011. Ecco la versione 2016. Basti pensare, questo è solo il numero di marchi di prodotti che è possibile eseguire per la tecnologia per quanto riguarda la tecnologia di marketing. Non la complessità dei sistemi al suo interno, non le diverse app e il web e lo sviluppo e la rete e tutti gli altri. Solo il marchio. C'è il prima, cinque anni fa ed ecco oggi. Andrà solo peggio. Siamo a questo punto in cui la realtà è, gli umani semplicemente non possono garantire tutti gli accordi sul livello di servizio. Non possiamo immergerci nei dettagli, abbastanza velocemente e nella scala di cui abbiamo bisogno. Ecco un esempio di come appare una console di monitoraggio ora. È come se quasi venti schermi dispari incollati insieme fingendo di essere uno schermo grande e proiettato che monitora ogni piccolo pezzo. Ora è interessante qui, non menzionerò il marchio, ma questa piattaforma di monitoraggio sta monitorando una singola applicazione in un ambiente logistico e di spedizione. Solo un'app. Se pensate a ciò di cui parlava Robin, dove le organizzazioni possono ora avere 40.000 database negli ambienti di produzione. Puoi semplicemente visualizzare come potrebbero essere 40.000 versioni di questa raccolta di schermi che monitorano un'applicazione? È un mondo molto coraggioso in cui viviamo. Come diceva Robin e lo farò assolutamente, al 100% echeggiamo che, senza gli strumenti giusti, senza il giusto supporto e gente sul tavolo usando quegli strumenti, le prestazioni delle applicazioni sono un gioco perduto per gli umani e deve essere fatto con strumenti e software.
Con ciò passerò ai nostri amici in IDERA.
Eric Kavanagh: Va bene, Bill.
Bill Ellis: Grazie. Condividere il mio schermo qui. Suppongo che qualcuno possa confermare che puoi vedere il mio schermo?
Dr. Robin Bloor: Sì.
Eric Kavanagh: Sembra tutto a posto.
Bill Ellis: Grazie. L'unica cosa a cui si riferiva era che non vedo l'ora che fosse l'auto a guida autonoma. L'unica cosa di cui non avevo sentito parlare è che cosa succede quando nevica? Mi chiedo se gli ingegneri in California abbiano capito che in altre parti del paese nevica un po '.
Dez Blanchfield: Mi piace, lo ricorderò.
Eric Kavanagh: un tipico miglio all'ora.
Bill Ellis: Siamo qui per parlare della gestione delle prestazioni delle applicazioni in un ambiente complesso. Una cosa di cui mi piace parlare è, molte persone, quando parlano di prestazioni, la natura della reazione è, ehi più server, più CPU, più memoria, ecc. L'altro lato di quella medaglia è l'efficienza di elaborazione. Davvero, sono due facce della stessa medaglia e daremo un'occhiata a entrambe. L'obiettivo finale è quello di rispettare gli accordi sul livello di servizio per le transazioni commerciali. In definitiva, tutta questa tecnologia esiste per l'azienda. Abbiamo parlato di avere un database di gestione delle prestazioni primo nel settore. L'ideale è adattarsi allo stampo ideale delle prestazioni e gestirlo dall'inizio del ciclo di vita delle applicazioni.
Gli argomenti si riducono davvero a quattro pezzi; uno è il processo di gestione delle prestazioni. Abbiamo parlato con tutti e tutti hanno gli strumenti. Se non hanno strumenti, hanno script o comandi, ma ciò che manca è il contesto. Il contesto consiste semplicemente nel collegare i punti tra le pile di applicazioni. Queste applicazioni per - sono basate su browser. Sono molto strettamente accoppiati da un livello all'altro. Anche il modo in cui i livelli interagiscono è vitale. Quindi, stiamo parlando della transazione commerciale. Forniremo la visibilità non solo ai tecnici, ma anche ai proprietari delle applicazioni e ai responsabili delle operazioni.
Ho un paio di case study per condividere con te in che modo i clienti li hanno utilizzati. Questa è una parte molto pratica della presentazione qui. Diamo un'occhiata a ciò che accade in genere. Mi piace diagramma - era proprio come un incredibile collage di tecnologie. Il numero di tecnologie nel data center è appena cresciuto, cresciuto e cresciuto. Nel frattempo, un utente finale non se ne preoccupa ed è ignaro. Vogliono solo esercitare la transazione, renderla disponibile, completarla rapidamente. Ciò che accade in genere è che i professionisti IT non sono consapevoli del fatto che gli utenti finali abbiano avuto un problema, fino a quando non si auto-segnalano. Questo dà il via a un processo che richiede tempo, lento e spesso frustrante. Quello che succede è che le persone apriranno i loro strumenti e guarderanno un sottoinsieme del loro stack di applicazioni. Con quel sottoinsieme, diventa molto difficile rispondere alla domanda più semplice. È normale che tu abbia il problema? Di che transazione si tratta? Dov'è nello stack dell'applicazione il collo di bottiglia? Trascorrendo tutto questo tempo, cercando livello per livello, non in grado di rispondere a queste domande, si finisce per spendere un sacco di tempo ed energia, un sacco di personale, fondi ed energia per scoprirlo.
Per risolvere questo problema, al fine di fornire un modo migliore, ciò che Precise è effettivamente prendere la traccia della transazione dell'utente finale, acquisire i metadati su di essa, seguire la transazione attraverso la rete, nel web server, nel livello della logica aziendale e supportiamo .NET e ABAP e PeopleCode ed E-Business Suite, in applicazioni a più livelli che alla fine tutte le transazioni interagiranno con il sistema di registrazione. Indipendentemente dal fatto che si tratti di una ricerca di inventario, del tempo di reportistica lavorato, interagiscono sempre con il database. Il database diventa la base delle prestazioni aziendali. Il database, a sua volta, si basa sull'archiviazione. Cosa rispondono i metadati sulle transazioni, chi, quale transazione, dove nello stack dell'applicazione, e quindi abbiamo una profonda visibilità a livello di codice per mostrarti cosa sta eseguendo. Queste informazioni vengono acquisite continuamente, inserite nel database di gestione delle prestazioni - che diventa un unico spartito musicale per consentire a tutti di vedere cosa sta succedendo. Ci sono diverse persone e organizzazioni che si preoccupano di ciò che sta accadendo: gli esperti tecnici, i proprietari delle applicazioni, in definitiva l'azienda stessa. Quando si presenta un problema, si desidera essere in grado di estrarre informazioni su quella transazione.
Prima di esaminare la transazione di investimento, voglio mostrarti come ciò potrebbe apparire a persone diverse nell'organizzazione. A un livello di gestione, potresti voler avere una panoramica di più applicazioni. Potresti voler conoscere lo stato calcolato dalla conformità e dalla disponibilità degli SLA. Che la salute non significa che tutto funzioni perfettamente al 100%. In questo caso c'è spazio per vedere che la transazione di investimento è nello stato di avviso. Ora, un po 'più in profondità, forse nel settore di attività, desideri avere alcuni dettagli aggiuntivi sulle singole transazioni, quando violano gli SLA, i conteggi delle transazioni, ecc. Il team operativo vorrà essere informato di ciò attraverso un avviso di alcuni ordinare. Abbiamo avvisi di prestazioni integrati. In realtà misuriamo le prestazioni nel browser dell'utente finale. Che si tratti di Internet Explorer, Chrome, Firefox, ecc., Siamo in grado di rilevare, questo risponde alla prima domanda: un utente finale ha un problema?
Immergiamoci e vediamo cos'altro possiamo mostrare al riguardo. Le persone interessate alla performance apriranno Precise. Valuterebbero le transazioni. Esaminerebbero la colonna SLA per identificare le transazioni non conformi allo SLA. Sarebbero in grado di vedere gli utenti finali interessati e ciò che la transazione ha fatto mentre scorreva attraverso l'applicazione. Il modo in cui decifri questi geroglifici è, questo è il browser, l'URL, la U è per l'URL, questo è il punto di ingresso nella JVM. Ora questa particolare JVM fa chiamare un web server alla seconda JVM che quindi esegue l'istruzione SQL. Questo è chiaramente un problema di database perché questa istruzione SQL era responsabile del 72 percento dei tempi di risposta. Siamo concentrati sul tempo. Il tempo è la valuta della performance. È il modo in cui gli utenti finali sperimentano se le cose funzionano lentamente o meno, ed è una misura del consumo di risorse. È molto utile; è una specie di singola metrica che è molto importante per la valutazione delle prestazioni. Quando questo problema viene trasmesso al DBA, non è solo un problema di database, è questa istruzione SQL. Questo è il contesto di cui parlavo.
Ora armato di queste informazioni, sono in grado di entrare e analizzare cosa è successo. Posso vedere prima di tutto, l'asse y è il tempo attraverso il giorno. Mi scusi, l'asse y è il tempo di risposta, l'asse x è il tempo attraverso il giorno. Vedo che c'è un problema con il database, ci sono due ricorrenze, tornare a quel flusso, raccogliere quell'istruzione SQL e andare nella vista di esperti, dove Precise è in grado di mostrarti cosa sta succedendo, i suoi controlli, quanto tempo impiega quel codice eseguire. Nel livello del database, è il piano di esecuzione. Noterai che Precise ha selezionato il piano di esecuzione reale utilizzato al momento dell'esecuzione, che si distingue dal piano stimato, che sarebbe quando il piano è stato dato e non durante il tempo di esecuzione. Può o meno riflettere ciò che il database ha effettivamente fatto.
Ora quaggiù, è un'analisi del tempo di risposta per l'istruzione SQL. Il novanta percento del tempo trascorso in deposito; il dieci percento è stato utilizzato nella CPU. Vedo il testo dell'istruzione SQL e il rapporto sui risultati. Il testo dell'istruzione SQL inizia effettivamente a rivelare alcuni problemi di codifica. È una stella selezionata; che restituisce tutte le righe - mi scusi, tutte le colonne delle righe che sono state restituite. Stiamo tornando indietro di colonne aggiuntive che l'applicazione potrebbe non essere necessaria. Quelle colonne consumano spazio e risorse per l'elaborazione. Se si esegue SAP, uno dei grandi cambiamenti, poiché il database HANA è colonnare, è sostanzialmente quello di riscrivere SAP per non scegliere la stella selezionata in modo che possano ridurre notevolmente il consumo di risorse. Questo è fondamentalmente qualcosa che accade molto tempo anche in applicazioni locali, Java, .NET, ecc.
Quella schermata ti mostra chi, cosa, quando, dove e perché. Il perché arriva, come l'istruzione SQL e il piano di esecuzione che consente di risolvere i problemi. Poiché Precise viene eseguito continuamente, in realtà è possibile misurare prima e dopo, a livello di istruzione SQL, a livello di transazione, in modo che sia possibile misurare da soli, sia attraverso i proprietari dell'applicazione che la gestione, che si è risolto il problema . Questa documentazione è davvero utile. C'è molta complessità in questo stack di applicazioni. Di molte applicazioni, infatti, tutti quelli con cui abbiamo parlato, eseguono almeno una parte dello stack di applicazioni in VMware. In questo caso, stanno esaminando l'applicazione del servizio clienti, stanno osservando il tempo di transazione e correlandolo con il rallentamento è un evento di virtualizzazione. Traccia precisa di tutti gli eventi di virtualizzazione. Abbiamo un plug-in per vCenter per raccoglierlo.
Siamo anche in grado di rilevare la contesa. La contesa è diversa dall'utilizzo. In realtà mostra quando forse un vicino rumoroso sta avendo un impatto sulla VM ospite, nel contesto dell'applicazione del server del cliente. Ora sono in grado di eseguire il drill-in e ottenere informazioni e posso effettivamente vedere le due macchine virtuali che contendono, in questo caso, le risorse della CPU. Questo mi permette di avere visibilità in modo da poter guardare alla pianificazione. Posso mettere una VM guest su un altro server fisico. Tutti questi tipi di cose a cui potresti rispondere e quindi, in aggiunta a ciò, posso effettivamente guardare l'efficienza del codice per avere forse meno CPU. Penso di avere un buon esempio in questa presentazione di come qualcuno è stato in grado di ridurre il consumo di CPU per ordini di grandezza.
Quello era VMware. Andiamo nel codice stesso, il codice dell'applicazione. Precise sarà in grado di mostrarti cosa sta succedendo in Java, .NET, il codice ABAP, E-Business, PeopleCode, ecc. Questi sono i punti di ingresso, in questo caso, in WebLogic. Quaggiù, c'è un rapporto sui risultati che mi dice che sono questi EJB che devi guardare, e mi dirà che hai anche il blocco in corso su questo sistema. Ancora una volta, il drill down all'interno del livello della logica aziendale, per mostrare cosa sta succedendo. In questo caso, sto guardando casi particolari; Supporta anche il clustering. Se sono in esecuzione numerose JVM, è possibile esaminare il cluster nel suo insieme o i colli di bottiglia all'interno della singola JVM.
Quando inizi a bloccare, posso entrare in eccezioni. L'eccezione è leggermente diversa rispetto a un problema di prestazioni. In genere, le eccezioni vengono eseguite molto velocemente. Perché c'è un errore logico e una volta colpito quell'errore logico, finisce. Siamo stati in grado di catturare una traccia dello stack all'inizio di un'eccezione, questo potrebbe risparmiare un sacco di tempo mentre sta cercando di capire cosa sta succedendo, hai solo la traccia dello stack, proprio lì. Siamo anche in grado di catturare anche perdite di memoria. La soluzione include anche il livello del database, posso entrare, posso valutare l'istanza del database. Ancora una volta, l'asse y è il tempo trascorso, l'asse x è il tempo nel corso della giornata. C'è un rapporto sui risultati che mi dice automaticamente cosa sta succedendo nel sistema e cosa potrei guardare.
Uno degli aspetti del rapporto sui risultati di Precise, non si limita a esaminare i registri o attendere lo stato, ma esamina tutti gli stati di esecuzione, compresa la CPU, nonché la restituzione delle informazioni dalla memoria. Lo storage è una parte molto importante dello stack dell'applicazione, in particolare con l'avvento dello stato solido. Avere informazioni in tal senso può essere molto utile. Per alcune unità di archiviazione, possiamo effettivamente analizzare in dettaglio e mostrare cosa sta succedendo a livello di singolo dispositivo. Quel tipo di informazione - ancora una volta, è una visibilità profonda; è di ampia portata: fornirti le informazioni sufficienti per avere una maggiore leva da utilizzare come professionista delle prestazioni delle applicazioni, in modo che tu possa ottimizzare le tue applicazioni end-to-end per soddisfare tali transazioni commerciali.
Ho un paio di case study che volevo condividere con te. Percorriamo abbastanza velocemente; Spero di andare a un buon ritmo. Parlando di archiviazione, tutti nel tempo cambiano hardware. C'è una garanzia hardware. Ha davvero fornito ciò che il venditore ti ha detto? Puoi valutarlo con Precise. Si entra, e quello che è successo qui, hanno praticamente inserito una nuova unità di archiviazione, ma quando gli amministratori dello storage hanno osservato solo il livello dell'unità di archiviazione, hanno visto molte controversie e hanno pensato che potesse esserci un problema con questa nuova unità di archiviazione . Guardare di più da una prospettiva end-to-end, proprio per mostrare dove ciò sarebbe effettivamente accaduto. In realtà sono passati da un throughput di circa 400 meg al secondo, dove lo spazio di archiviazione era responsabile del 38 percento dei tempi di risposta, quindi è piuttosto elevato. Con la nuova unità di archiviazione abbiamo effettivamente aumentato il throughput a sei, settecento mega al secondo, quindi sostanzialmente il doppio, e siamo in grado di dimezzare il contributo del livello di archiviazione al tempo di transazione. Sono in grado di rappresentare graficamente prima, questo è il periodo di ritaglio, e poi il dopo.
Quindi, ancora una volta, la documentazione per dimostrare che valeva la pena investire nell'hardware e consegnata come previsto da quel particolare fornitore. C'è tutto, a causa della complessità, del numero di cose, ci sono tutti i tipi di cose che possono accadere. In questo caso, in realtà hanno avuto una situazione in cui tutti stavano biasimando il DBA, il DBA era come "Beh, non così in fretta." Qui stiamo effettivamente guardando un'applicazione SAP, penso che questo tipo di scenario sia abbastanza comune . Quello che è successo è che stavano sviluppando una transazione personalizzata per un utente. L'utente dice "Questo è così lento". Il codificatore ABAP - questo è il linguaggio di programmazione in SAP - ha detto: "Questo è un problema di database". Hanno finito per aprire Precise; hanno misurato quell'utente finale 60 secondi, quindi ben oltre un minuto. Trascorsero cinquantatre secondi nel back-end. Hanno eseguito il drill-back nel back-end e sono stati effettivamente in grado di rivelare l'istruzione SQL presentata in ordine decrescente.
Questa affermazione SQL top che è responsabile del 25 percento del consumo di risorse, il suo tempo medio di esecuzione è di due millisecondi. Non puoi incolpare il database. Sai, ehi, non così in fretta, ragazzo. La domanda è: perché ci sono così tante esecuzioni? Bene, lo hanno rimandato all'ABAP, è entrato, ha esaminato l'annidamento del loop, ha scoperto che stavano chiamando il database nel posto sbagliato, hanno sostanzialmente effettuato la modifica, testato la modifica e ora il nuovo tempo di risposta è cinque secondi. Un po 'lento, ma potevano conviverci. Molto meglio di 60 secondi. A volte, basta scappare, è il codice dell'applicazione, è il database, è l'archiviazione? Queste sono le aree in cui Precise, avendo il contesto delle transazioni end-to-end, è qui che entra in gioco Precise. Praticamente finisci quelle cose.
Sto guardando l'ora, sembra che abbiamo ancora un po 'di tempo per passare un altro paio di questi. Sto trasmettendo questi. Questa applicazione era in fase di sviluppo da oltre un anno. Quando sono entrati nel QA, vedevano che i server Web erano al massimo del 100 percento e sembrava che l'applicazione non potesse essere eseguita con VMware. La prima cosa che tutti dicevano era: “Metti questo sul fisico; non può essere eseguito con VMware. ”Precise in realtà offriva loro altri modi per risolvere il problema. Abbiamo esaminato le transazioni, abbiamo visto una chiamata al web server, che arriva come ASMX in IIS.NET. In realtà ha rivelato il codice sottostante. Vedi questo dove sto indicando? Sono 23 giorni, 11 ore. Wow, come è possibile? Bene, ogni invocazione richiede 9, 4 secondi e questa cosa viene invocata 215.000 volte. Per ogni chiamata, utilizza 6 secondi di CPU. Questa è la ragione, questo codice è la ragione per cui questa cosa non potrebbe mai ridimensionarsi. In effetti, non poteva ridimensionarsi in termini fisici.
Quello che hanno fatto, sono tornati dai loro sviluppatori e hanno detto: "Qualcuno può fare un cambiamento?" In un certo senso hanno partecipato a un contest, hanno testato i diversi suggerimenti e hanno trovato un suggerimento che è stato in grado di eseguire molto Più efficiente. Il nuovo ha completato un punto, poco meno di due secondi, con due centesimi di secondo in CPU. Ora questo potrebbe ridimensionarsi e potrebbe essere eseguito nella farm VMware. In pratica siamo stati in grado di documentarlo sia a livello di codice che a livello di transazione. Questo è un po 'il prima e poi il dopo. Ora che puoi vedere qui nel grafico a barre dello stack che mostra web, .NET e database, ora stai interagendo con il database. Questo è un profilo che ti aspetteresti di vedere per un'applicazione che era in esecuzione più normalmente.
Va bene, sto scegliendo e scegliendo in termini di cose aggiuntive che posso mostrarti. A molte persone piace questo perché questo abbaglia molti negozi. Se non sei in grado di rispettare uno SLA aziendale e tutti dicono "Aiutaci". Questo negozio ha avuto una situazione in cui lo SLA aziendale è in ordini ricevuti entro le 15:00, viene spedito quel giorno. È davvero fondamentale che eseguano gli ordini e il magazzino è molto occupato. La schermata di questo ordine di vendita di JD Edwards si stava congelando e puoi avere un'ottima idea che si tratti di un sistema di gestione dell'inventario al dettaglio just-in-time. I ripiani vuoti sono inaccettabili nella vendita al dettaglio. Devo avere la merce lì per venderla. Quello che abbiamo fatto è che ci siamo immersi, in questo caso, stiamo guardando il database del server SQL. L'aspetto è lo stesso sia che si tratti di SQL, Oracle, DB2 o Sybase.
Abbiamo identificato la selezione da PS_PROD e siamo in grado di catturare la durata, il fatto che eseguono così tanto. Il blu scuro corrispondeva alla chiave che diceva che non stavano aspettando un certo stato di attesa o un po 'di registrazione o persino di archiviazione: questa cosa è vincolata dalla CPU. Abbiamo tracciato l'istruzione SQL di 34301, quindi ogni volta che viene eseguita, incrementiamo i nostri contatori per tenerne traccia. Ciò significa che abbiamo una cronologia dettagliata e posso accedervi facendo clic sul pulsante di ottimizzazione. Ecco la scheda della cronologia. Questa schermata mostra la durata media rispetto alle modifiche. Mercoledì, giovedì, venerdì, la durata media è stata di circa i due decimi di secondo. Pochissimi blocchi dello schermo sono in grado di soddisfare lo SLA aziendale. Vieni il 27 febbraio, qualcosa cambia e all'improvviso, il tempo di esecuzione è qui, ed è effettivamente abbastanza lento da causare timeout, che si traduce in blocchi dello schermo. Preciso, mantenendo una cronologia dettagliata, incluso il piano di esecuzione e le modifiche generali agli indici della tabella se tale SQL è in uso. Siamo riusciti a capire che il piano di accesso è cambiato il 27 febbraio. Lunedi a Venerdì settimana cattiva. Vieni il 5 marzo, il piano di accesso è cambiato di nuovo. Questa è una buona settimana Questa stella rosa ci dice che il volume è stato aggiornato.
Puoi vedere qui il numero di righe nelle tabelle sottostanti sta crescendo e questo è tipico per un'azienda. Vuoi che i tuoi tavoli crescano. Il fatto è che le istruzioni sono analizzate, arrivano le istruzioni SQL, l'ottimizzatore deve decidere cosa fare e scegliere quando il piano di esecuzione è veloce, scegliere un altro piano di esecuzione quando è lento, causando il blocco dello schermo. Su una base tecnologica profonda, devo sapere qual è il piano di esecuzione e Precise lo acquisisce completo di data e ora. Questo è quello che è stato veloce ed efficiente, questo è stato lento e inefficiente. Questo join del filtro utilizza semplicemente molta più CPU per riconciliare, per fare questa particolare istruzione SQL. Hanno ancora lo stesso effetto finale, ma questo ha fondamentalmente una ricetta più lenta e meno efficiente per fornire il set di risultati. Quindi, facciamo un passo avanti. Ehi, abbiamo tempo per un altro paio?
Eric Kavanagh: Sì, provaci.
Bill Ellis: Ok, salterò avanti. Una cosa di cui voglio prendere nota, abbiamo parlato di hardware, di SAP, di .NET, di JD Edwards e dell'ambiente Java-SQL Server. Questo è SAP, qui guardiamo PeopleSoft. La matrice di supporto di Precise è ampia e profonda. Se hai un'applicazione, molto probabilmente, siamo in grado di fornirla per fornire questo livello di visibilità. Uno dei maggiori cambiamenti che stanno accadendo in questo momento è la mobilità. PeopleSoft ha introdotto la mobilità con la sua UI fluida. L'interfaccia utente fluida utilizza un sistema in modo molto diverso. Questa applicazione si sta evolvendo. L'interfaccia utente fluida: ciò che fa dal punto di vista della gestione è che consente agli utenti finali di utilizzare il proprio telefono e aumenta notevolmente la produttività. Se hai centinaia o migliaia o anche più dipendenti, se puoi aumentare la loro produttività, 1-2%, puoi avere un impatto enorme sul libro paga e su tutto il resto. Quello che è successo è stato che questo particolare negozio ha implementato l'interfaccia utente fluida di PeopleSoft. Ora, parlando di complessità, questo è lo stack PeopleSoft. Un'applicazione, un minimo di sei tecnologie, numerosi utenti finali. Come si avvia?
Ancora una volta Precise sarà in grado di seguire queste transazioni. Quello che ti stiamo mostrando qui è un grafico a barre in pila che mostra client, server web, Java, database Tuxedo, stack di applicazioni PeopleSoft. Il green è mappato su J2EE, che è una specie di modo fantasioso per dire WebLogic. Questo è il ritaglio. Gli utenti finali iniziano a utilizzare l'interfaccia utente fluida e il tempo di risposta può variare da forse un anno e mezzo, due secondi, fino a circa nove, dieci secondi. Ciò che questa schermata non mostra è il numero di persone che hanno ottenuto "non rispondono". In realtà hanno ottenuto blocchi dello schermo nell'applicazione. Diamo un'occhiata ad alcune delle visibilità che Precise è in grado di fornire a questo cliente.
Prima di tutto, quando guardo le transazioni di PeopleSoft, possono vedere fondamentalmente che abbiamo visto questo tipo di cose su tutta la linea. Tutte le transazioni sono state influenzate, così come tutte le posizioni. Per inciso, quando lo guardi, puoi effettivamente vedere posizioni in tutto il mondo. Dall'Asia del Pacifico, all'Europa e al Nord America. Il problema delle prestazioni non si trovava in una particolare transazione, o in una particolare posizione geografica, è a livello di sistema. È una specie di modo per dire che il cambiamento o il modo in cui l'interfaccia utente fluida ha avuto un impatto globale. Puoi vedere qui dal punto di vista della scalabilità, le persone stanno cercando di fare lo stesso tipo di attività, ma i tempi di risposta sono semplicemente peggiorati. Puoi vedere che le cose non stanno ridimensionando. Le cose stanno andando molto, molto male. Qui, quando guardo il conteggio degli assi e le connessioni simultanee, vedi qualcosa di molto interessante in termini di conteggio degli accessi e connessioni. Qui stiamo scalando solo fino a circa 5.000 e stai guardando circa, questo supera 100 connessioni simultanee. Questo viene fatto dopo; questo è prima. Quindi ciò che la mia vera richiesta al sistema, se questa cosa potesse ridimensionare, è nella gamma di 300.000. Ai vecchi tempi, con la classica interfaccia utente, stai guardando 30 connessioni simultanee.
Ora, ciò che ti sta dicendo è che l'interfaccia utente fluida utilizza almeno 10 volte il numero di connessioni simultanee. Iniziamo a ritirare ciò che sta accadendo sotto le coperte con PeopleSoft in modo da poter iniziare a vedere l'impatto sui server Web, il fatto che gli SLA stanno iniziando a violare. Non entrerà in tutto, ma alla fine succede che fondamentalmente si basano sulla messaggistica. Fondamentalmente si esercitano in WebLogic e causano code all'interno di Tuxedo. In realtà si è verificato un problema di dipendenza a più livelli che si è manifestato con l'interfaccia utente fluida, ma Precise è stato in grado di dimostrare che con un sacco di cose diverse, possiamo concentrarci su quale fosse il problema. Si scopre che c'era anche un problema nel database stesso. In realtà c'è un file di registro di messaggistica e, a causa di tutti gli utenti simultanei, quel file di registro era bloccato. Fondamentalmente aveva cose da mettere a punto, in ogni singolo livello all'interno dello stack dell'applicazione. Parliamo di complessità, ecco in realtà il livello di smoking che ti mostra la coda e puoi vedere le prestazioni degradare anche all'interno di questo livello. Ho potuto vedere i processi; Ho potuto vedere i domini e i server. In smoking, per le persone che lo usano, in genere quello che fai è aprire code, domini e server aggiuntivi, proprio come al supermercato per alleviare la congestione, per ridurre al minimo i tempi di attesa. Ultima e ultima opzione, Precise mostra molte informazioni.
Come ho accennato in precedenza, ogni transazione significativa interagisce con il sistema di record. La visibilità nel database è fondamentale. Precise mostra cosa sta succedendo nel database, in WebLogic, in Java, .NET, nel browser, ma la posizione che Precise eccelle davvero è nel livello del database. Questo sembra essere il punto debole dei nostri concorrenti. Lascia che ti mostri uno dei modi in cui Precise potrebbe aiutarti a farlo. Non ho intenzione di passare del tempo sul triangolo dell'ottimizzazione del database, ma sostanzialmente stiamo esaminando modifiche di tipo a basso costo, a basso rischio, ad ampio raggio, ad alto rischio e ad alto costo. In realtà inserirò su Twitter questa diapositiva in seguito, se le persone vogliono provare a darle un'occhiata. È una guida abbastanza grande, credo, per i problemi di ottimizzazione. Ecco la vista esperta di Precise for Oracle. In cima al rapporto sui risultati, l'impatto del 60 percento è questa particolare istruzione SQL. Se apri questa schermata di attività, la mostra lì. Posso guardare questa affermazione selezionata, c'è un piano di esecuzione. Ogni esecuzione richiede una seconda - 48.000 esecuzioni. Ciò aggiunge fino a 48.000 ore in più di esecuzioni.
Il blu scuro, ancora una volta, è CPU. Questa cosa è legata alla CPU, non uno stato di attesa, non un registro. Sottolineo che, poiché alcuni dei nostri concorrenti guardano solo agli stati di attesa e agli eventi di registrazione, ma in generale, la CPU è lo stato di esecuzione più occupato e offre il maggior riacquisto. Entrando in questa visione di esperti - e vado molto rapidamente - quello che ho fatto è stato guardare il tavolo, 100.000 righe, 37.000 blocchi. Stiamo facendo un tavolo completo, ma abbiamo sei indici su questa cosa. Cosa sta succedendo qui? Bene, quando guardo la clausola where, ciò che sta facendo questa clausola è in realtà sta convertendo una colonna in maiuscolo e sta dicendo dove è uguale a maiuscolo, trova variabile. Ciò che accade è ogni volta che questa cosa viene eseguita, Oracle deve convertire questa colonna in maiuscolo. Piuttosto che farlo quasi cinquantamila volte, è molto più efficiente costruire quell'indice in maiuscolo di un indice basato su funzioni ed è disponibile non solo nella divisione aziendale Oracle, anche divisione standard. Quando lo fai, ciò che puoi fare è verificare il piano di esecuzione che emette il nuovo utente indice maiuscolo, che era solo una cosa mia.
Quindi, da una misurazione prima e dopo, stai guardando un tempo di esecuzione di un secondo, aggrega fino a 9 ore 54 minuti, con la stessa esatta istruzione SQL, ma avendo quell'indice incorporato in maiuscolo per 58.000 esecuzioni, la risposta il tempo scende a meno di millisecondi, si aggregano insieme, arriva fino a sette secondi. Fondamentalmente ho salvato dieci ore di CPU sul mio server. Questo è enorme. Perché se non sono in attesa di un aggiornamento del server, sono in grado di vivere su quel server. In realtà abbasso l'utilizzo del server del 20 percento e puoi effettivamente vedere il prima e il dopo. Questo è il tipo di visibilità che Precise può fornire. Ci sono anche alcune cose aggiuntive che potremmo considerare, perché hai tutti questi indici se non vengono utilizzati? Possono farcela. C'è l'architettura e la avvolgerò, poiché stiamo raggiungendo la cima dell'ora. Sono un vero credente in questa soluzione e vogliamo che tu sia un vero credente. Noi di IDERA crediamo che una prova faccia un cliente, quindi se sei interessato, siamo in grado di fare valutazioni sul tuo sito.
Detto ciò, restituirò il faro.
Eric Kavanagh: Sì, questo è stato un dettaglio straordinario che hai mostrato lì. È davvero molto affascinante. Penso di averti detto in passato che - e so che in alcuni degli altri webcast che abbiamo fatto con IDERA, ho detto che - ho effettivamente monitorato Precise da prima che fosse acquisito da IDERA, fino al 2008, penso, o al 2009. Ne ero affascinato allora. Sono curioso di sapere quanto lavoro ci vuole per rimanere al passo con le nuove versioni delle applicazioni. Hai detto che SAP HANA, che a mio avviso è stato abbastanza impressionante, che puoi effettivamente scavare nell'architettura HANA e fare qualche risoluzione dei problemi lì. Quante persone hai? Quanto sforzo è da parte tua e quanto può essere fatto in modo un po 'dinamico, ovvero quando lo strumento viene distribuito, inizi a strisciare e vedere cose diverse? Quanto di questo può essere dinamicamente, in qualche modo, verificato dallo strumento, in modo da poter aiutare le persone a risolvere ambienti complessi?
Bill Ellis: Hai fatto molte domande lì.
Eric Kavanagh: lo so, scusa.
Bill Ellis: Ho fornito molti dettagli perché per queste applicazioni, guardando il codice, il diavolo è nei dettagli. Devi avere quel livello di dettaglio per essere davvero in grado di avere qualcosa che è utilizzabile. Senza metriche attuabili, conosci solo i sintomi. In realtà non stai risolvendo problemi. IDERA riguarda la risoluzione dei problemi. Rimanere in cima alle nuove uscite e roba è una grande sfida. La domanda su cosa serve per farlo, è davvero per la gestione dei prodotti. Non ho molta visibilità nel team che sostanzialmente ci tiene aggiornati sulle cose. In termini di HANA, questa è in realtà una nuova aggiunta alla linea di prodotti IDERA; è molto eccitante. Una delle cose di HANA è: lasciatemi parlare del compito per un secondo. Nell'attività, i negozi SAP farebbero se replicassero il database a scopo di reportistica. Quindi dovresti far riconciliare le persone con ciò che è realmente attuale. Avresti questi diversi database e non sarebbero sincronizzati da livelli diversi. C'è solo un sacco di tempo e fatica, oltre all'hardware, al software e alle persone per mantenere tutto ciò.
L'idea di HANA di avere un database in memoria altamente parallelo, per evitare sostanzialmente la necessità di database duplicati. Abbiamo un database, una fonte di verità, è sempre aggiornato, in questo modo eviti il necessario per fare tutta quella riconciliazione. L'importanza delle prestazioni del database HANA aumenta: sto per dire 10 volte o almeno più prezioso della somma di tutti gli altri database, hardware e risorse che possono essere acquistati. Essere in grado di gestire HANA, ora quel componente è attualmente in fase di beta test, è qualcosa che presto diventerà GA. Quindi è abbastanza eccitante per IDERA e per noi sostanzialmente supportare la piattaforma SAP. Non sono sicuro di quali altre parti della tua domanda ho cambiato tipo ma -
Eric Kavanagh: No, sono tutte cose buone lì dentro. Ti ho lanciato un sacco di pezzi contemporaneamente, quindi mi dispiace per quello. Sono solo affascinato, davvero, voglio dire, questa non è un'applicazione molto semplice, giusto? Stai scavando a fondo in questi strumenti e capendo come interagiscono tra loro e al tuo punto, devi in qualche modo mettere insieme la storia nella tua testa. Devi combinare un po 'di informazioni per capire cosa sta realmente accadendo e cosa ti sta causando il problema, quindi puoi andare lì e risolvere quei problemi.
Un partecipante chiede, quanto è difficile implementare Precise? Un'altra persona ha chiesto, chi sono le persone - ovviamente DBA - ma chi sono alcuni altri ruoli nell'organizzazione che userebbero questi strumenti?
Bill Ellis: Precise è un po 'più complicato da implementare. Devi avere una certa conoscenza dell'ambiente applicativo, in termini di, sai, questa applicazione gira su questo database, ha bisogno o - i server web di livello intermedio, ecc. Penso che data la complessità di alcune di queste applicazioni, in realtà è relativamente facile. Se riesco a strumentare il web server fino al tuo database, posso farlo end-to-end. Notate che non ho detto nulla sulla strumentazione di un client per l'utente finale e questo perché ciò che facciamo è, in realtà includiamo in modo dinamico, quindi non è necessario modificare il codice o nient'altro. Un JavaScript entra nel frame della pagina dell'applicazione. Indipendentemente da dove si trovi l'utente nel mondo, quando accedono all'URL dalla tua applicazione e portano giù quella pagina, viene fornito con Precise. Ciò ci consente di selezionare l'ID utente, il loro indirizzo IP, anche il tempo di rendering del primo byte di ciascuno dei tempi di esecuzione dello script dei componenti della pagina nel browser dell'utente finale.
In termini di transazioni, non è necessario mappare le transazioni perché sono strettamente accoppiate. Questo URL diventa un punto di ingresso a JVM e quindi richiama questo messaggio, risultando in una JVC catturata dal database. Siamo in grado di catturare fondamentalmente quei punti di connessione naturali e poi presentarli a te in quella schermata di transazione che ti ho mostrato dove abbiamo anche calcolato quanto tempo o la percentuale di tempo trascorso in ogni singolo passaggio. Tutto ciò viene fatto automaticamente. In linea generale, assegniamo 90 minuti da fare - per installare fondamentalmente il core Precise e quindi iniziamo a implementare l'applicazione. A seconda della conoscenza dell'applicazione, potrebbero essere necessarie alcune sessioni aggiuntive per ottenere la strumentazione dell'intera applicazione. Molte persone usano solo il componente di database di Precise. Va bene. Puoi praticamente rompere questo, suddividerlo nei componenti che ritieni necessari per il tuo sito. Riteniamo sicuramente che il contesto della strumentazione dell'intero stack dell'applicazione in modo da poter vedere che la dipendenza da livello a livello ingrandisce effettivamente il valore del monitoraggio di un singolo livello. Se qualcuno vuole esplorare ulteriormente la strumentazione del proprio stack di applicazioni, si prega di visitare il nostro sito Web - Immagino sia il modo più semplice per richiedere informazioni aggiuntive e ne discuteremo un po 'più avanti.
Eric Kavanagh: Lascia che ti faccia una o due domande veloci. Immagino che tu stia raccogliendo e costruendo un repository nel tempo, sia per i singoli clienti sia come entità aziendale nel suo complesso, delle interazioni tra varie applicazioni e vari database. In altre parole, immagino che la modellazione di scenari sia ciò a cui alludo. È così? Effettivamente gestisci una sorta di repository di scenari comuni in modo tale da poter dare suggerimenti agli utenti finali quando alcune cose entrano in gioco? Come questa versione di E-Business Suite, questa versione di questo database, ecc., Fai molto?
Bill Ellis: Beh, quel tipo di informazioni è integrato nel rapporto sui risultati. Il rapporto sui risultati indica quali sono i colli di bottiglia delle prestazioni e si basa sui tempi di esecuzione. Parte di quel rapporto sui risultati è saperne di più e cosa fai dopo. Le informazioni o l'esperienza dei clienti e così via sono sostanzialmente incorporate in quella libreria di raccomandazioni.
Eric Kavanagh: Okay, suona bene. Bene gente, presentazione fantastica oggi. Bill, ho adorato quanti dettagli avevi lì dentro. Ho solo pensato che fosse un'informazione davvero fantastica, grintosa e granulare, che mostra come sono fatte tutte queste cose. Ad un certo punto è quasi come la magia nera, ma in realtà non lo è. È una tecnologia molto specifica che voi ragazzi mettete insieme per capire ambienti molto, molto complessi e rendere felici le persone perché a nessuno piace quando le applicazioni funzionano lentamente.
Bene gente, archiveremo questo webcast. Puoi andare online su Techopedia o insideanalysis.com e wow, grazie per il tuo tempo, ti raggiungeremo la prossima volta. Abbi cura di te, ciao.
