Per Techopedia Staff, 2 de novembre de 2016
Take away: L' amfitrió Eric Kavanagh discuteix el rendiment de les aplicacions i com millorar l'eficiència amb el doctor Robin Bloor, Dez Blanchfield i IDERA Bill Ellis.
Actualment no teniu la sessió iniciada. Inicieu la sessió o registreu-vos per veure el vídeo.
Eric Kavanagh: Senyores i senyors, hola i benvinguts de nou a Hot Technologies. Sí, de veritat! Em dic Eric Kavanagh, seré el vostre amfitrió per a una altra transmissió web avui en aquesta sèrie tan divertida i emocionant que tenim com a compliment de la nostra sèrie Briefing Room. El títol es titula "Aceleració de l'aplicació: rendiment més ràpid per als usuaris finals". Vine gent que no ho vol? Si sóc el noi que ajude la vostra aplicació a funcionar més de pressa, estic pensant que sóc el que em fa comprar cerveses al bar després de la feina. Ha de ser una cosa molt maca per entrar i agilitzar l’aplicació de qualsevol.
Hi ha una diapositiva sobre la vostra, realment, toca'm a Twitter @Eric_Kavanagh. Sempre intento fer un seguiment i sempre torno a tuitejar si m’esmentes, així que no dubteu en mencionar-me.
L’objectiu complet d’aquest espectacle és centrar-se en diferents aspectes de la tecnologia empresarial i ajudar realment a definir determinades disciplines o determinades cares, si ho voleu. Moltes vegades els venedors s’adoptaran en determinats termes de màrqueting i parlen de com fan això o això o alguna altra cosa. Aquest programa va ser realment dissenyat per ajudar el nostre públic a comprendre què ha de tenir una eina de programari per ser líder en el seu espai. Són dos analistes el format. Tots van primer, a diferència de la sala d’informació on surt el venedor primer. Cadascú pren el seu parer sobre el que creuen que és important que coneguis sobre un tipus particular de tecnologia.
Avui parlem d’acceleració d’aplicacions. Ens sentirem a parlar de Dez Blanchfield i també del doctor Robin Bloor, avui en tot el món, i llavors Bill Ellis marxa des de la zona de Virgínia més gran. Amb això, ho lliuraré al nostre primer presentador, el doctor Bloor. Hem tuitejat el hashtag de #podcast per cert, així que no dubteu a tuitejar. Emporta-t'ho.
Robin Bloor: Està bé, gràcies per aquesta introducció. Rendiment de l'aplicació i nivells de servei: es tracta d'un tipus d'àrea, al llarg dels anys he treballat molt en aquesta àrea, en el sentit que realment he treballat molt en controlar el rendiment i treballar en un sol. d’una manera o altra, com provar i calcular aquests nivells. Cal dir que fins ara, solíem tenir aquesta època, on la gent construïa sistemes en sitges. Bàsicament, la quantitat de treball que han de fer perquè un sistema funcioni raonablement bé si es trobava en una sitja no era massa difícil perquè hi ha una quantitat molt petita de variables que cal tenir en compte. Tan bon punt vam arribar a una xarxa adequada, l’orientació interactiva i de servei va entrar en l’equació. Va ser una mica difícil. El rendiment pot ser unidimensional. Si només penses en una aplicació que executa una ruta de codi en concret de forma repetida, fer-ho raonablement, de manera puntual, se sent com una cosa unidimensional. Tan bon punt comenceu a parlar de nivells de servei, en realitat heu de parlar de diverses coses que competeixen per als recursos informàtics. Es converteix en diverses dimensions molt ràpidament. Si comenceu a parlar de processos empresarials, els processos empresarials es poden enllaçar entre diverses aplicacions. Si parleu d’arquitectura orientada al servei, aleshores una aplicació determinada pot accedir a les capacitats de diverses aplicacions. Aleshores es converteix en una cosa molt complicada.
Vaig mirar: fa molt de temps, vaig dibuixar aquest diagrama. Aquest diagrama té almenys 20 anys. Bàsicament, l’anomeno Diagrama de Tot, perquè és una manera de mirar tot el que existeix en l’entorn informàtic. Realment només són quatre peces: usuaris, dades, programari i maquinari. Per descomptat, canvien amb el pas del temps, però en realitat t’adones que hi ha una explosió jeràrquica de cadascuna d’aquestes peces. Un maquinari sí, un maquinari pot ser un servidor, però un servidor consta de múltiples CPU possiblement, tecnologia de xarxa i memòria, i això és una mena de controladors, com passa. Si ens fixem en això, tot es descompon en trossos. Si realment penses en intentar orquestrar tot això, pel que fa a les dades que canvien, el rendiment del programari canvia, perquè el maquinari canvia, etcètera, en realitat, estàs buscant una situació multi-variable molt difícil. Aquesta és la corba de complexitat. Per descomptat, es tracta de la corba de complexitat de gairebé tot, però ho he vist dibuixat una i altra vegada quan parlem d’ordinadors. Bàsicament, si poseu nodes en un eix i les connexions importants a l’altre eix, acabareu amb una corba de complexitat. Gairebé no importa quins són els nodes i les connexions i això ho farà si voleu una representació del creixement del volum a la xarxa telefònica.
De fet, quan es parla de nodes de l’entorn de l’ordinador, es parla de coses individuals que s’importen l’una de l’altra. La complexitat, aparent, és una qüestió d’estructura de varietats i de les diverses limitacions que s’intenta obeir. També, els números. Quan els números pugen, es tornen bojos. Ahir vaig tenir un xat interessant, estava parlant amb algú, no puc esmentar qui era, però realment no importa, parlaven d'un lloc que tenia 40.000, és a dir, quatre-zero, 40.000, que hi ha casos de bases de dades. al lloc. Pensa en això: 40.000 bases de dades diferents. Per descomptat, l’únic que teníem, òbviament, tenien moltes, moltes milers d’aplicacions. Estem parlant d’una organització molt gran, però no puc donar nom. En realitat ho veieu i realment esteu intentant, d'una manera o altra, obtenir nivells de servei adequats per a diversos usuaris amb diverses expectatives, si voleu, diverses. És una situació complexa i, tot el que realment dic, és complexa. Els números sempre augmenten. Les limitacions es determinen segons els processos i els objectius empresarials. Haureu notat el canvi d’espectatives.
Recordo que tan aviat com van aparèixer Gmail, Yahoo mail i Hotmail, tots aquests sistemes de correu, les persones van començar a tenir una expectativa dels seus sistemes de correu interns dins de l’organització, mereixerien els nivells de servei d’aquestes operacions enormes amb granges de servidors fora. l’organització i va començar a ser pressionada perquè passés tot aquest tipus de coses. En realitat, els acords a nivell de servei són una cosa, però les expectatives són una altra cosa i es barallen entre elles dins d’una organització, cosa incòmoda. Aquí teniu només una perspectiva empresarial. En alguns sistemes, el temps de resposta òptim és una desena part del segon del temps de resposta humana. Una desena de segon és el moment que triga una cobra a mossegar-te. Si esteu davant d’un cobra i decidiu mossegar-vos, és massa tard, ja no serà possible perquè no pugueu respondre en una desena de segon. Una dècima de segon és aproximadament el temps que triga la pilota a deixar la mà del càntir per arribar al noi amb el ratpenat. Bàsicament, com veu la pilota llançada, ha de respondre exactament en aquest moment. Resposta humana, una cosa interessant. De programari a programari, òbviament pot tenir una expectativa més alta.
A continuació, s'obren en algunes situacions que crec que són aquelles situacions de mercat, on ser primer és on es troba el valor empresarial. Això és com si voleu vendre un estoc determinat a la borsa és probablement menor, per exemple, perquè penseu que baixarà i molta altra gent creu que baixarà, obtindreu el millor preu si arribeu al mercat primer. Hi ha moltes situacions, publicacions d’anuncis i coses així, situacions molt similars. Teniu aquest moviment pel que fa a expectatives de nivell de servei. Teniu una cosa que és una espècie de sostre de vidre per a la resposta humana. Una vegada que es tracta de programari a programari, si teniu aquesta situació de sostre, no hi ha cap millor nivell de servei. Més ràpid que tothom és el millor.
Està bé, crec, aquesta és la diapositiva final que estava fent, però això només serveix per fer-vos una gran imatge de la complexitat, un cop mireu els requisits de l'organització, el servei. Ja teniu a la banda esquerra aquí, teniu la gestió del sistema, que és un conjunt de programari que serveix per a la gestió de serveis, que intenta gestionar un nivell de servei. Per sobre de tot això, teniu la gestió del rendiment empresarial. A continuació, si mireu el fons aquí, l'àrea d'automatització de la gestió de serveis, teniu serveis fragmentats que evolucionen cap a serveis normalitzats, si realment us interessa invertir en aquest tipus de coses, que evolucionen cap a serveis integrats, que evolucionen cap a serveis optimitzats . Principalment el que han fet les persones és només a la part inferior esquerra d'aquesta. Potser una mica de gestió del servei. Gestió del rendiment empresarial, molt rara. Fragmentat, gairebé tot. Un món perfecte ompliria aquesta graella. Instrumentació: he esmentat un problema de sub-optimització. Podeu optimitzar parts d'un sistema i no serveix per a tot el sistema. Si feu que el cor sigui òptim, la sang podria circular massa ràpidament per la resta d’òrgans. Això és un problema amb grans organitzacions i nivells de servei. Evidentment no s’aconseguirà res sense eines sofisticades perquè les variables acaben d’aconseguir, i hi ha massa variables per provar i optimitzar.
Dit això, passaré a Dez que parlarà d’una altra cosa completament, amb l’esperança.
Dez Blanchfield: Gràcies, Robin. Igual que el doctor Robin Bloor, he estat massa anys pensant en el rendiment de sistemes molt complexos a gran escala. Probablement no és la mateixa escala que Robin, però el rendiment és un tema quotidià i forma part del nostre ADN desitjar rendiment, treure el màxim partit de tot. De fet, he utilitzat un gràfic d’una de les meves coses preferides del món, les curses d’automòbils de Fórmula I, on tot el planeta s’asseu una estona i observa que els cotxes es desplacen en cercles molt ràpidament. A tots els aspectes, no hi ha cap aspecte de la Fórmula I que no es refereixi específicament al rendiment. Molta gent cobra l’esport perquè pensen que és una pèrdua de diners. Resulta que el cotxe que conduïm cada dia per deixar els nens al futbol els caps de setmana a l'escola els altres dies, es deriva d'un desenvolupament i una investigació basats en el rendiment. És una mena de la vida de les curses de cotxes de Fórmula I. La tecnologia quotidiana, la ciència quotidiana, sovint prové d’alguna cosa que s’ha centrat exclusivament en l’alt rendiment.
La realitat, però, és que el nostre nou món "sempre en marxa", que exigeix un 100% de temps de funcionament, com ja va mencionar Robin, amb coses com la introducció del correu web i altres serveis que donem per descomptat a l'espai continu, i ara esperem que el nostre entorn empresarial i laboral. La realitat és que estar a dalt no sempre vol dir que compliu el vostre acord de nivell de servei. Crec que la necessitat de gestionar el rendiment de les aplicacions i els acords de nivell de servei de disponibilitat han experimentat un canvi fonamental en l'última dècada. Ja no volem preocupar-nos pel rendiment d'un sistema. Quan el món era una mica més senzill, podríem tenir una situació en què un sol servidor amb múltiples serveis es pot controlar en directe i era relativament senzill el suport. Podríem, i aquí és el meu poc, les coses que ens preocupava quan era administrador del sistema, per exemple, fa molts anys, que mirarem al nostre voltant? El servei sol respondre i respondre? Per exemple, puc iniciar sessió en un terminal? El sistema operatiu respon i puc escriure ordres? Les aplicacions estan en funcionament? Puc veure processos i memòria per fer coses i E / S a la xarxa i així successivament? Els dies del mainframe es podien escoltar cintes sortint amb cremallera i paper.
Les aplicacions responen i podem iniciar sessió i fer-ne coses? Els usuaris poden connectar-se a alguns d'aquests servidors? Continua. Són força fonamentals, ja ho sabeu. A continuació, algunes divertides: el servei d’assistència és verd? Perquè si no, llavors tot va bé, i qui va a treure els bunyols? La vida era realment senzilla en aquells dies. Fins i tot en aquells dies, i després parlo de fa 20-30 anys, la complexitat era encara realment alta. Podríem, de forma relativament senzilla, gestionar acords a nivell de servei i estar atents al rendiment. Ja no ho podem fer a mà, tal com feia al·lusió Robin. El repte és massa gran. El fet és el moment en què unes quantes bones aplicacions, administradors, xarxa de sistemes i base de dades, administradors poden supervisar i satisfer els SLA de rendiment. Els SLA estan tan desapareguts ara que vaig lluitar ahir a la nit quan vaig posar junts les meves notes finals per pensar fins i tot l'any en què vaig aconseguir buscar un sistema d'una pila molt complexa i comprendre'n fins i tot comprendre el que era passant sota la caputxa i vinc d'un fons profundament tècnic. No puc imaginar com és fer front ara a diari administrativament.
Què va passar? Bé, el 1996, les aplicacions basades en bases de dades es van transformar amb el boom d’internet. Molts de nosaltres hem passat per això. Tot i que no estiguéssiu al voltant del boom d’internet, podeu mirar-ho fàcilment i adonar-vos que, a la vida quotidiana, connectem tot a Internet ara. Crec que tenim una torradora que aparentment ve amb l’opció d’iniciar-se a la xarxa Wi-Fi, que és ridícula, perquè no necessito que el meu torrador estigui connectat a Internet. A la dècada dels 2000, sobretot a principis dels anys 2000, vam haver de fer front a aquest creixement massiu de la complexitat a l’hora d’oferir el rendiment del servei en un boom puntual. A continuació, una altra espurna ridícula a la web 2.0, on van aparèixer els telèfons intel·ligents i ara les aplicacions estaven a les nostres mans les 24 hores del dia i estaven sempre en mode permanent.
Ja és 2016, ens trobem davant d’un altre quagmire en forma de núvol i big data i mobilitat. Es tracta de sistemes tan grans que sovint són difícils d’entendre i de posar en anglès. Quan pensem en el fet que alguns dels grans unicorns de què parlem tenen desenes de centenars de petabytes de dades. Es tracta d’un pis complet d’emmagatzematge i emmagatzematge del disc només per contenir el vostre correu electrònic, les imatges i les xarxes socials. O en alguns casos, a la logística de transports i d’enviament, tot és a la banca, és on es troben els vostres diners, o on es troba la vostra publicació o la vostra, on es troba el que heu comprat a eBay. La propera gran onada que estem a punt d’afrontar és aquest repte molt pesat d’internet de les coses.
Si això no fos prou dolent, estem a punt de construir intel·ligència artificial i informàtica cognitiva en gairebé tot. En aquests dies parlem amb motors Siri i Google. Sé que Amazon en té un de propi. Baidu té un d’aquests dispositius si es pot parlar, el converteixen en un text que entra en un sistema normal, la base de dades fa una consulta i torna i inverteix el procés. Penseu en la complexitat que hi ha. La realitat és que la complexitat de la pila d'aplicacions estàndard d'avui està molt més enllà de les capacitats humanes. Quan penseu en tot el que passa quan premeu un botó al dispositiu del telèfon intel·ligent o a la tauleta, en parleu, el converteix en text, s'executa de manera completa fins a Internet a un sistema de fons, un recepció frontal rep. és a dir, la converteix en una consulta, executa la consulta a través d'una pila d'aplicacions, passa per una base de dades, arriba a un disc, torna a sortir, i al centre hi ha una xarxa de portadors, hi ha un centre d'estat de xarxa d'àrea local. La complexitat està boja.
Això ho afirmen efectivament com a escala superior. La complexitat i la velocitat de la gamma alta són només un reg ocular. Les aplicacions i les bases de dades s’han tornat tan grans i tan complexes, que gestionar el rendiment és en realitat una ciència en si mateixa. Molts s’hi refereixen com a coets. Tenim tecnologia al lloc, disposem de tecnologia fora de lloc, tenim diverses opcions del centre de dades; físic i virtual. Tenim servidors físics i virtuals, tenim núvols, tenim infraestructura com a servei i plataforma com a servei i programari com a servei és cosa que ara donem per descomptat. Aquest últim, el programari com a servei, es va fer por fa uns anys quan CFOs i parts de l’organització es van adonar que podrien recollir la seva targeta de crèdit i només comprar coses mateixes i fer una volta al CIO i efectivament vam anomenar aquesta “ombra. IT ”i els CIOs ara intenten recuperar aquesta opció i controlar la lluita.
A la infraestructura tenim una xarxa de virtualització definida per programari, la virtualització de la funció de xarxa, per sota de la que probablement hem acabat, ara tenim micro serveis i aplicacions de serveis actius. Quan feu clic a una URL, hi ha un munt de lògica de negoci que es troba al final d'aquesta URL que descriu el que necessita per lliurar-lo. No necessàriament té lògica preconstruïda esperant-la. Tenim bases de dades tradicionals per un costat, que són molt grans i molt grans. Tenim els gustos de la infraestructura i els ecosistemes de Hadoop a l'altre espectre que són tan grans que, com he dit, ja ho sabeu, ara la gent parla de centenars de petabytes de dades. Tenim una mobilitat complexa quant als dispositius que transporten, ordinadors portàtils i telèfons i tauletes.
Tenim BYOD en alguns entorns tancats i cada cop més, ja que la gent amb experiència gen gen porta els seus propis dispositius. Simplement els vam deixar parlar amb interfícies web. Ja sigui per internet o per Wi-Fi, tenim una connexió Wi-Fi gratuïta a la planta baixa, ja que prenen cafè. O la nostra connexió Wi-Fi interna. De màquina a màquina està sempre present. Això no forma part directament de la Internet de les coses, però també està relacionat. L’Internet de les coses és un joc completament nou, amb una complexitat que no deixa de pensar. La intel·ligència artificial i si creieu que el que estem jugant ara, amb tots els Siri i altres dispositius relacionats amb què parlem és complexa, espereu fins arribar a una situació en què es veu una cosa anomenada Olli que és un 3-D Un autobús imprès que té aproximadament sis persones i pot conduir-se per la ciutat i pot parlar-ne anglès i li parlarà. Si toca trànsit, decidirà girar a l’esquerra o a la dreta de la zona principal on hi ha trànsit. Quan gira i et preocupes per què es gira a l’esquerra o a la dreta de la carretera principal, et dirà: “No et preocupis, estic a punt de girar a l’esquerra. Hi ha trànsit per davant i vaig a donar una volta. "
Gestionar el rendiment de tots els sistemes que hi ha i tota la complexitat, fer un seguiment cap a on surten aquestes dades, tant si van a la base de dades, com a totes les interconnexions i tots els bits rellevants, és simplement un problema. La realitat és que gestionar el rendiment i els SLA a la velocitat i escala actuals requereix eines i sistemes i, per defecte, això ja no és una cosa que només pensés que seria bo tenir una eina, sinó que és un requisit previ; només és absolutament necessari. A continuació s’explica una mica d’exemple, una llista dels esquemes de disseny d’aplicacions d’alt nivell per al OpenStack, núvol definit per programari de codi obert. Això és només una part grossa. No es tracta només de servidors i bases de dades. Aquí és on cada petita bombeta blava representa cúmuls de coses. En alguns casos, arxius i servidors o centenars de bases de dades, o, per descomptat, no més de desenes de milers de petites peces de lògica d'aplicacions en funcionament. Aquesta és una versió petita. És veritablement una bogeria mental quan comenceu a pensar en la complexitat que es produeix en això. Avui, fins i tot a l’espai de grans dades, només posaré algunes captures de pantalla de només les marques. Quan pensem en totes les peces que hem de gestionar aquí, no parlem necessàriament d’una sola marca, es tracta de marques del gran panorama de dades i de la marca de referència, no només de petites o de codi obert. Sembla i penseu que és un gràfic sensible.
Mirem només un parell de verticals. Prenguem el màrqueting, per exemple. A continuació, es mostra un gràfic similar, però només es pot trobar a partir de les piles tecnològiques disponibles només per la tecnologia de màrqueting Aquest és el gràfic del 2011. Aquí teniu la versió 2016. Penseu-hi, aquest és el nombre de marques de productes que podeu fer servir per a la tecnologia pel que fa a la tecnologia de màrqueting. No és la complexitat dels sistemes que hi ha dins, ni les diferents aplicacions i web i desenvolupament i xarxa i la resta. Només la marca. Hi ha l’abans, fa cinc anys i aquí el d’avui. Només va a empitjorar. En aquest moment, on es troba la realitat, els humans simplement no podem assegurar tots els acords a nivell de servei. No podem capbussar-nos en detalls, prou ràpid i en la mida que necessitem. A continuació, es mostra un aspecte del que sembla una consola de monitorització. És com una vintena de pantalles rares que s’uneixen i pretenen ser una gran i projectada pantalla de gran seguiment de cada tros. Ara és interessant per aquí, no mencionaré la marca, però aquesta plataforma de control supervisa una sola aplicació en un entorn logístic i d’enviament. Només una aplicació. Si penseu de què parlava Robin on les organitzacions poden disposar de 40.000 bases de dades ara en entorns de producció. Simplement podeu visualitzar com podrien ser les 40.000 versions d’aquesta col·lecció de pantalles de control d’una aplicació? És un món molt valent en què vivim. Tal com va dir Robin i ho faré absolutament, el 100 per cent de ressò que, sense les eines adequades, sense el suport i la gent adequades a la taula utilitzant aquestes eines, el rendiment de les aplicacions és un joc perdut per als humans i ho ha de fer mitjançant eines i programari.
Amb això passaré als nostres amics a IDERA.
Eric Kavanagh: Està bé, Bill.
Bill Ellis: Gràcies. Compartint la pantalla aquí. Suposo que algú pot confirmar que pot veure la meva pantalla?
Robin Bloor: Sí.
Eric Kavanagh: Està bé.
Bill Ellis: Gràcies. L'única cosa a la qual es referia era que realment no puc esperar era l'automòbil. De l’única cosa de la qual no havia sentit parlar ningú és, què passa quan neva? Em pregunto si els enginyers de Califòrnia es van adonar que en altres parts del país neva bastant.
Dez Blanchfield: M'agrada, recordaré aquell.
Eric Kavanagh: Un típic d'una milla per hora.
Bill Ellis: estem aquí per parlar de la gestió del rendiment de les aplicacions en un entorn complex. Una cosa de la qual m’agrada parlar és que molta gent quan parla de rendiment és la naturalesa de la reacció: més servidors, més CPU, més memòria, etc. L’altra cara d’aquesta moneda és l’eficiència del processament. De fet, es tracta de dues cares a la mateixa moneda i anem a fer una ullada a totes dues. L’objectiu final és complir els acords a nivell de servei per a les transaccions comercials. En definitiva, tota aquesta tecnologia existeix per al negoci. Hem parlat de tenir una base de dades de gestió de rendiment de primera indústria. L’ideal d’això és encaixar en el motlle ideal de rendiment i gestionar-lo des del començament del cicle de vida de les aplicacions.
Els temes tracten de debò a quatre peces; un és el procés de gestió del rendiment. Hem parlat amb tothom i tothom té eines. Si no tenen eines, tenen scripts o ordres, però el que els falta és el context. El context és simplement connectar els punts entre les piles d'aplicacions. Aquestes aplicacions per a - estan basades en navegador. S’acoblen molt de nivell a nivell. La interacció dels nivells també és vital. Aleshores, estem parlant de la transacció comercial. Anem a proporcionar la visibilitat no només als tècnics, sinó també als propietaris d’aplicacions i als gestors d’operacions.
Tinc un parell d’estudis de casos per compartir amb tu com els clients ho han utilitzat. Aquesta és una part molt pràctica de la presentació aquí. Mirem què passa normalment. M'agrada esquematitzar, va ser com un collage increïble de tecnologies. El nombre de tecnologies del centre de dades acaba de créixer i créixer. Mentrestant, a un usuari final no li importa, i ho ignora. Només volen exercir la transacció, tenir-la disponible, tenir-la completa ràpidament. El que passa normalment és que els professionals de les TI no saben que els usuaris finals fins i tot van tenir algun problema fins que s’autoinformen. Això produeix un procés lent i lent i sovint frustrant. El que passa és que la gent obrirà les seves eines i mira un subconjunt de la seva aplicació. Amb aquest subconjunt es fa molt difícil respondre a la pregunta més senzilla. És habitual que tingueu el problema? Quina transacció es tracta? On es troba en la pila d'aplicacions el coll d'ampolla? En gastar tot aquest temps, buscant nivells per nivells i no capaços de respondre a aquestes preguntes, acabes gastant molt temps i energia, molta plantilla, fons i tipus d’energia.
Per solucionar-ho, per proporcionar una manera millor, el que Precise fa és realment fer la transacció de pista de l'usuari final, captar metadades al respecte, seguir la transacció a través de la xarxa, al servidor web, al nivell de lògica comercial i admetem .NET i ABAP i PeopleCode i E-Business Suite, en aplicacions multitier que en última instància totes les transaccions interagiran amb el sistema de registre. Tant si es tracta d’una cerca d’inventaris, un temps d’informació treballat, sempre interactuen amb la base de dades. La base de dades es converteix en el fonament del rendiment empresarial. La base de dades, al seu torn, es basa en l'emmagatzematge. Què responen les metadades sobre les transaccions, qui, quina transacció, on es troba en una aplicació i, a continuació, tenim una visibilitat profunda a nivell de codi per mostrar-vos què s’executa. Aquesta informació es capta de forma contínua, s’introdueix a la base de dades de gestió de rendiment, que es converteix en un sol full de música perquè tothom vegi què passa. Hi ha diferents persones i organitzacions que es preocupen pel que passa: els tècnics experts, els propietaris d’aplicacions, en definitiva, el negoci en si. Quan surti un problema, voldreu poder extreure informació sobre aquesta transacció.
Abans de veure la transacció d’inversió, vull mostrar-vos com es pot aparèixer a diferents persones de l’organització. En un nivell de gestió, potser voldreu tenir una visió general de diverses aplicacions. És possible que vulgueu conèixer la salut que es calcula segons la conformitat i la disponibilitat de SLA. Que la salut no vol dir que tot sigui 100% funcionant perfectament. En aquest cas, hi ha espai per veure que la transacció d'inversió està en estat d'avís. Ara, una mica més profund, potser en la línia de negoci, voleu tenir algun detall addicional sobre les transaccions individuals, quan incompleixen els SLA, els comptes de transaccions, etc. L’equip d’operacions voldrà ser notificat al respecte mitjançant una alerta d’alguns ordenar. Tenim integrades alertes de rendiment. En realitat es mesura el rendiment al navegador de l’usuari final. Tant si es tracta d’Internet Explorer, Chrome, Firefox, etc., podem detectar, i això respon a la primera pregunta: té un problema final l’usuari final?
Anem a submergir-nos i veure què més podem mostrar al respecte. Les persones interessades en el rendiment obririen l'objectiu Precise. Valoraran les transaccions. Mireu la columna SLA per identificar transaccions que no complien SLA. Podrien veure els usuaris finals que van tenir un impacte, així com el que va fer aquesta transacció quan passava per l’aplicació. La forma de desxifrar aquests jeroglífics és el navegador, l'URL, la U és per a URL, és el punt d'entrada a la JVM. Ara, aquest JVM particular fa una crida al servidor web a la segona JVM que després executa la instrucció SQL. Aquest és clarament un problema de base de dades, ja que aquesta declaració SQL era responsable del 72 per cent del temps de resposta. Estem centrats en el temps. El temps és la moneda de rendiment. És com experimenten els usuaris finals si les coses funcionen lentament o no, i és una mesura del consum de recursos. És molt útil; és una mena de mètrica que és més important per avaluar el rendiment. Quan aquest problema es lliura al DBA, no és només un problema de base de dades, és aquesta declaració SQL. Aquest és el context del qual parlava.
Ara amb aquesta informació, puc entrar i analitzar què ha passat. Primerament puc veure que l’eix Y és el temps durant tot el dia. Perdona, l’eix Y és el temps de resposta, l’eix x és el temps durant tot el dia. Puc veure que hi ha un problema de base de dades, hi ha dues ocurrències, tornar al flux, agafar aquesta instrucció SQL i entrar a la vista experta, on el Precise és capaç de mostrar-vos què passa, els seus controls, quant de temps triga aquest codi. executar Al nivell de base de dades, es troba el pla d’execució. Tindreu en compte que Precise va seleccionar el pla d’execució real que s’utilitzava en el moment d’execució, que es distingeix del pla estimat, que seria quan es donés el pla i no durant el temps d’execució. Pot reflectir o no la realització de la base de dades.
A continuació, aquí es mostra una anàlisi del temps de resposta per a la instrucció SQL. El 90% del temps dedicat a l'emmagatzematge; el deu per cent es va utilitzar a la CPU. Puc veure el text de la sentència SQL i l’informe de conclusions. El text de la instrucció SQL comença a revelar alguns problemes de codificació. És estrella selecta; que retorna totes les files: disculpeu-me, totes les columnes de les files que es van retornar. Estem recuperant les columnes addicionals que l'aplicació pot necessitar o no. Aquestes columnes consumeixen espai i recursos per processar-los. Si executeu SAP, un dels grans canvis, perquè la base de dades HANA és columnar, és que bàsicament reescriure SAP per no triar estrella selecta, de manera que poden reduir molt el consum de recursos. Bàsicament és una cosa que passa molt de temps també en aplicacions casolanes, ja siguin Java, .NET, etc.
A la pantalla, es mostra qui, què, quan, on i per què. Per què arriba, com la instrucció SQL i el pla d'execució, que us permet resoldre problemes. Com que Precise s'executa contínuament, realment podeu mesurar abans i després, a nivell d'instrucció SQL, a nivell de transacció, de manera que podeu mesurar tant per vosaltres com pels propietaris d'aplicacions i per a la gestió, que heu resolt el problema. . És molt útil aquesta documentació. Hi ha molta complexitat en aquesta pila d'aplicacions. De moltes aplicacions, de fet, tothom amb qui hem parlat, té com a mínim una part de la pila d'aplicacions sota VMware. En aquest cas, estan buscant l’aplicació d’atenció al client, busquen el temps de transacció i la correlacionen amb la desacceleració és un esdeveniment de virtualització. Fa un seguiment precís de tots els esdeveniments de virtualització. Tenim un connector a vCenter per recollir-lo.
També som capaços de detectar la contenció. La contenció és diferent de la que es fa servir. Es mostra realment quan potser un veí sorollós afecta el vostre VM de convidats, en el context de l'aplicació del servidor del client. Ara, sóc capaç de perfeccionar i obtenir informació i realment puc veure les dues màquines virtuals que es plantegen, en aquest cas, a recursos de CPU. Això em permet tenir visibilitat perquè puc mirar la programació. Puc posar una màquina virtual de màquina convidada en un servidor físic diferent. Tot aquest tipus de coses que podríeu respondre i, a més d'això, puc examinar l'eficiència del codi per tal que faci servir menys CPU. Crec que tinc un exemple molt bo en aquesta presentació de com algú va poder reduir el consum de CPU per ordres de magnitud.
Això era VMware. Anem al codi en si mateix, el codi de l’aplicació. Precisament us podreu mostrar què passa dins de Java, .NET, el codi ABAP, E-Business, PeopleCode, etc. Aquests són els punts d’entrada a, en aquest cas, a WebLogic. A continuació, hi ha un informe de troballes que em diu que són aquests EJBs que cal revisar i em diran que també teniu bloqueig en aquest sistema. Una vegada més, es realitza una exploració dins del nivell de lògica empresarial per mostrar el que passa. En aquest cas, estic estudiant casos concrets; També adono al clustering. Si teniu en funcionament nombroses JVM, podeu mirar el conjunt del clúster o bé veure els colls d'ampolla dins de la JVM individual.
A mesura que us endinseu en el bloqueig, puc obtenir excepcions. L’excepció és una mica diferent que un problema de rendiment. Normalment, les excepcions s’executen molt ràpidament. Com que hi ha un error de lògica i un cop heu tocat aquest error de lògica, aquest s’acaba. Vam poder capturar una traça de pila en una de les excepcions, això pot estalviar molt de temps, mentre s’està intentant esbrinar què passa, només hi ha la traça de la pila, allà mateix. També podem capturar filtracions de memòria. La solució també inclou el nivell de base de dades, puc entrar, puc avaluar la instància de la base de dades. Un cop més, l’eix y és on es va passar el temps, l’eix x és el temps durant tot el dia. Hi ha un informe de troballes que només explica automàticament què és el que passa al sistema i què puc mirar.
Una de les coses sobre l’informe de conclusions de Precise, no només es fixa en els registres o l’estat d’espera, sinó que té en compte tots els estats d’execució inclosa la CPU, a més de retornar informació de l’emmagatzematge. L’emmagatzematge és una part molt important de la pila d’aplicacions, sobretot amb l’arribada de l’estat sòlid. Tenir informació segons aquestes línies pot ser de gran ajuda. Per a determinades unitats d’emmagatzematge, realment podem explorar i mostrar el que passa a nivell de dispositiu individual. Aquest tipus d’informació, una vegada més, és una visibilitat profunda; té un ampli abast: us proporcionarà informació suficient per obtenir més avantatge per obtenir com a professional del rendiment de les aplicacions, de manera que pugueu optimitzar les vostres aplicacions de forma final a fi per satisfer aquestes transaccions comercials.
Tinc un parell d’estudis de casos que volia compartir amb vosaltres. Creuem força ràpidament; Espero que vagi a bon ritme. Parlant d’emmagatzematge, tot el món canvia de maquinari amb el pas del temps. Hi ha una garantia de maquinari. Realment va lliurar el que el venedor li va dir? Podeu valorar-ho amb Precis. Entres, i el que va passar aquí, bàsicament van introduir una nova unitat d’emmagatzematge, però quan els administradors d’emmagatzematge van mirar només el nivell d’unitat d’emmagatzematge, van veure molta contenció i van pensar que podria haver-hi un problema amb aquesta nova unitat d’emmagatzematge. . Mirar més des d'una perspectiva final a extrem, precisament per mostrar on passaria realment això. De fet, van passar d'un rendiment d'aproximadament 400 megabones per segon, on l'emmagatzematge era el responsable del 38 per cent del temps de resposta, per la qual cosa és bastant elevat. Amb la nova unitat d’emmagatzematge realment vam augmentar el rendiment fins a sis, set-cents meges per segon, per tant bàsicament el doble, i podem reduir la contribució del nivell d’emmagatzematge al temps de transacció a la meitat. Realment sóc capaç de gràficar que abans, aquest és el període de tall i després el següent.
Així, una vegada més, documentació per demostrar que la inversió en maquinari va valdre la pena i es van lliurar tal i com esperava aquest venedor. Hi ha tot, per la complexitat, pel nombre de coses, hi pot haver tot tipus de coses. En aquest cas, en realitat tenien una situació en què tothom culpava al DBA, el DBA era com "Bé, no tan ràpid". Aquí estem buscant una aplicació SAP, crec que aquest tipus d'escenaris és força habitual. . El que va passar va ser que estaven desenvolupant una transacció personalitzada per a un usuari. L’usuari és com: “Això és tan lent”. El codificador ABAP, que és el llenguatge de programació de SAP, va dir: “Es tracta d’un problema de base de dades”. Van acabar obrint precisos; van mesurar l'usuari final 60 segons, el que va anar bé durant un minut. Es van passar cinquanta-tres segons a la part posterior. Van perforar fins al fons i van poder revelar la sentència SQL presentada en ordre descendent.
Aquesta instrucció SQL que és responsable del 25% del consum de recursos, el seu temps d'execució mitjà és de dos mil·lisegons. Vostè no pot culpar la base de dades. Sabeu, no, tan ràpid, noi. La pregunta és, per què hi ha tantes execucions? Bé, el van tornar a rebotar a l’ABAP, va entrar, va mirar la nidificació del bucle, es va assabentar que trucaven la base de dades al lloc equivocat, bàsicament van fer el canvi, van provar el canvi i ara el nou temps de resposta és. cinc segons. Una mica lents, però podrien viure amb això. Molt millor que 60 segons. De vegades, només cal esborrar, és el codi de l'aplicació, és la base de dades, es tracta d'emmagatzematge? Són els àmbits en què Precise, en tenir el context de les transaccions de final a extrem, és aquí on entra en joc Precise. Bàsicament acabes amb aquestes coses.
Estic mirant el temps, sembla que encara tenim un temps per passar-ne un parell més. Estic reproduint aquests articles. Aquesta aplicació està en desenvolupament des de fa més d’un any. Quan van entrar a la QA, van veure que els servidors web tenien un màxim del 100 per cent i semblava que l'aplicació no es podia executar amb VMware. El primer que va dir tothom va ser: “Posa’t això físic; no pot funcionar amb VMware ". En realitat, els va oferir maneres addicionals de resoldre el problema. Vam mirar les transaccions, vam veure una trucada al servidor web, que apareix com a ASMX a IIS.NET. De fet, va revelar el codi subjacent. Ja veieu això on m’estic apuntant? Això és de 23 dies, 11 hores. Uf, com és possible? Doncs cada invocació triga 9, 4 segons i aquesta cosa s’invoca 215.000 vegades. Per a cada invocació, s’utilitzen 6 segons de CPU. Aquesta és la raó, aquest codi és la raó per la qual aquesta cosa no podria escalar-se mai. De fet, no es podia escalar en físic.
El que van fer és que van tornar als seus desenvolupadors i em van dir: “Algú pot fer un canvi?” Van tenir un concurs i van provar els diferents suggeriments i van fer un suggeriment que va poder executar molt. de manera més eficient. El nou va completar un punt, una mica menys de dos segons, amb dues centèsimes parts de segon en CPU. Ara, això podria escalar-se i podria funcionar a la granja de VMware. Bàsicament vam poder documentar això tant a nivell de codi com a nivell de transacció. Aquesta és una espècie d’abans i després de després. Ara que podeu veure aquí al gràfic de barres de pila que mostra web, .NET i base de dades, ara esteu interactuant amb la base de dades. Aquest és un perfil que hauríeu de veure per a una aplicació que funcionava amb més normalitat.
D’acord, estic escollint i escollint quant a coses addicionals que us puc mostrar. A molta gent li agrada perquè aquest llit es troba a moltes botigues. Si no podeu complir amb un SLA empresarial i tothom és com: “Ajudeu-nos a sortir”. Aquesta botiga tenia una situació en què la SLA empresarial es troba en comandes rebudes fins a les 15 hores, s’envia aquest dia. És realment vital que rebin les comandes i el magatzem estigui molt ocupat. Aquesta pantalla de comandes de vendes de JD Edwards, es congelava i es pot fer una idea molt bona que es tracta d’un sistema de gestió d’inventaris al detall just a temps. Les plataformes buides no són acceptables al detall. Vaig tenir la mercaderia allà per poder vendre-la. El que vam fer és que ens vam endinsar, en aquest cas, estem buscant la base de dades del servidor SQL. L'aspecte és el mateix, ja sigui SQL, Oracle, DB2 o Sybase.
Vam identificar la selecció de PS_PROD i podem capturar la durada, el fet que executen tant. El blau fosc va coincidir amb la clau que deia que no esperaven algun estat d’espera, algun registre o fins i tot emmagatzematge; aquesta cosa està relacionada amb la CPU. Hem fet un seguiment de la sentència SQL per 34301, així que cada vegada que s’executa, augmentem els nostres comptadors per fer-ne el seguiment. Això vol dir que tenim un historial detallat i que hi puc accedir fent clic al botó de sintonització. Aquí teniu la fitxa d’historial. Aquesta pantalla mostra la durada mitjana enfront dels canvis. Dimecres, dijous, divendres, la durada mitjana va ser d’unes dues dècimes de segon. Pocs pocs congelats de la pantalla són capaços de complir els SLA empresarials. Arribat el 27 de febrer, alguna cosa canvia i el temps d’execució sobtat, ja ha arribat, i en realitat és prou lent per provocar temps morts, que es tradueixen en la congelació de la pantalla. Precisament, mantenint un historial detallat, inclosos el pla d’execució i els canvis generals als índexs de la taula si s’utilitza aquest SQL. Vam poder recollir que el pla d'accés va canviar el 27 de febrer. Setmana dolenta de dilluns a divendres. El proper 5 de març, el pla d’accés va tornar a canviar. Aquesta és una bona setmana. Aquesta estrella rosa ens explica el volum actualitzat.
Podeu veure aquí el nombre de files de les taules subjacents que creix i això és típic per a una empresa. Voleu que les vostres taules creixin. La cosa és que les instruccions són analitzades, les instruccions SQL entren, l’optimitzador ha de decidir què fer i triar quan el pla d’execució és ràpid, triar un altre pla d’execució quan sigui lent, provocant la congelació de la pantalla. Sobre una base de tecnologia profunda, he de saber quin és el pla d’execució i la captura precisa per completar-la amb la data i l’hora de marca. Aquest és ràpid i eficaç, aquest és lent i ineficient. Aquesta unió de filtre utilitza simplement molta més CPU per conciliar, per fer aquesta instrucció SQL particular. Segueixen tenint el mateix efecte final, però bàsicament té una recepta més lenta i menys eficient per lliurar el conjunt de resultats. Així doncs, fem un pas. Ei, tenim temps per a un parell més?
Eric Kavanagh: Sí, passa per això.
Bill Ellis: D'acord, m'ho passaré. Una cosa vull que prengueu una nota, vam parlar de maquinari, vam parlar de SAP, vam parlar de .NET, vam parlar de JD Edwards i de l'entorn Java-SQL Server. Es tracta de SAP, aquí veiem PeopleSoft. La matriu de suport precisa és àmplia i profunda. Si teniu una aplicació, més que probable, la podem instrumentar per oferir aquest nivell de visibilitat. Un dels majors canvis que s’està produint ara mateix és la mobilitat. PeopleSoft va introduir la mobilitat amb la seva IU Fluida. L’UI fluida utilitza un sistema de manera molt diferent. Aquesta aplicació està evolucionant. La interfície d'usuari fluida: el que fa des d'una perspectiva de gestió és que permet als usuaris finals utilitzar el telèfon i augmenta considerablement la productivitat. Si teniu centenars o milers de treballadors o fins i tot més, si podeu augmentar la seva productivitat, l’1-2 per cent, podeu tenir un impacte enorme en la nòmina i en la resta. El que va passar va ser: aquesta botiga particular va desplegar la interfície d'usuari fluida PeopleSoft. Ara, parlant de complexitat, es tracta de la pila PeopleSoft. Una aplicació, un mínim de sis tecnologies, nombrosos usuaris finals. Com s’inicia?
Una vegada més, Precise podrà seguir aquestes transaccions. El que us mostrem aquí és un gràfic de barres apilat que mostra client, servidor web, Java, base de dades de Tuxedo, pila d'aplicacions PeopleSoft. Els mapes verds a J2EE, que és una manera fantàstica de dir WebLogic. Aquest és el tros. Els usuaris finals comencen a utilitzar la interfície d'usuari fluida i el temps de resposta va des de potser un minut i mig, dos segons, fins a uns nou, deu segons. El que no mostra aquesta pantalla és el nombre de persones que no han "respost." Mirem algunes de les visibilitats que Precise pot proporcionar a aquest client.
En primer lloc, quan miro les transaccions de PeopleSoft, poden veure bàsicament, hem vist aquest tipus de coses a tota la taula. Totes les transaccions es van veure afectades, així com totes les ubicacions. De fet, quan ens fixem en això, realment podeu veure ubicacions de tot el món. Des de l’Àsia Pacífic, fins a Europa i Amèrica del Nord. El problema de rendiment no es va localitzar en una transacció determinada, ni en una ubicació geogràfica concreta, ja que és general. És una manera de dir que el canvi o la manera en què la interfície d'usuari fluida tenia un impacte global. Podeu veure aquí des del punt de vista de l’escalabilitat que la gent està intentant fer el mateix tipus d’activitat, però el temps de resposta bàsicament només es degrada i es degrada. Es pot veure que les coses no estan escalant. Les coses van molt, molt malament. Aquí, quan veig el recompte d’eixos i les connexions concurrents, veieu una cosa molt interessant pel que fa al recompte d’accés i a les connexions. Aquí només estem reduint fins a prop de 5.000 i ens fixem en això, que arriba a 100 connexions concurrents. Això es fa després; això és abans. Llavors, el que la meva demanda real del sistema, si aquesta cosa pogués reduir-se, és de 300.000. Antigament, amb la interfície d'interès clàssica, esteu buscant 30 connexions concurrents.
Ara el que això us està dient és que la interfície d'usuari fluida utilitza almenys 10x connexions concurrents. Comencem a retirar el que passa a les portades de PeopleSoft perquè pugueu veure l'impacte en els servidors web, ja que els SLA comencen a incomplir-se. No va a entrar en tot, però el que acaba passant és que bàsicament es basen en la missatgeria. Bàsicament, l'exercici és WebLogic i causa cua a Tuxedo. De fet, hi va haver un problema de dependència multitier que es va presentar amb la interfície operativa fluida, però Precise va poder demostrar que mitjançant un munt de coses diferents, podem centrar-nos en el problema. Resulta que també hi va haver un problema a la pròpia base de dades. De fet, hi ha un fitxer de registre de missatgeria i, a causa de tots els usuaris concurrents, aquest fitxer de registre estava bloquejat. Bàsicament tenia coses per sintonitzar, en tots els nivells de la pila d'aplicacions. Parlem de complexitat, aquí teniu en compte el nivell de Tuxedo que us mostra la cua i també podreu veure el rendiment degradant en aquest nivell. Vaig poder veure els processos; Vaig poder veure els dominis i els servidors. A Tuxedo, perquè la gent pugui utilitzar-ho, normalment el que feu és obrir cues, dominis i servidors addicionals, tal com al supermercat per alleujar la congestió, per minimitzar el temps de cua. Última i última opció, Precise mostra molta informació.
Com ja havia comentat anteriorment, totes les transaccions importants interaccionen amb el sistema de registres. La visibilitat a la base de dades és primordial. Es mostra exactament el que passa dins de la base de dades, dins de WebLogic, dins Java, .NET, dins del navegador, però el lloc que realment excel·lent Precise es troba al nivell de bases de dades. Això és la debilitat dels nostres competidors. Permeteu-me que us mostri una de les maneres en què Precise us pot ajudar a passar per això. No vaig a dedicar temps al triangle de l’optimització de bases de dades, però bàsicament estem estudiant canvis de tipus de baix cost, de risc ampli, d’ampli abast, d’alt risc i d’alt cost. En realitat, enviaré aquesta diapositiva després si la gent vol provar-la. Crec que és una gran guia per a problemes d’afinació. A continuació, es mostra la visualització d’experts Precise for Oracle. Al capdamunt de l’informe de conclusions, el 60 per cent d’impacte és aquesta declaració SQL particular. Si obre aquesta pantalla d’activitat, la mostra aquí. Puc mirar aquesta instrucció selecta: hi ha un pla d’execució. Cada execució té un segon: 48.000 execucions. Això suma 48.000 hores més d’execucions.
El blau fosc, una vegada més, és CPU. Aquesta cosa està relacionada amb la CPU, no és un estat d’espera ni un registre. Remarco que, ja que alguns dels nostres competidors només miren els estats d’espera i els esdeveniments de registre, però en general, la CPU és l’estat d’execució més ocupat i ofereix la major recompra. Entrant en aquesta visió experta -i vaig molt ràpidament-, el que vaig fer és mirar la taula, 100.000 files, 37.000 blocs. Estem fent una taula completa, però tenim sis índexs sobre aquest tema. Que està passant aquí? Bé, quan miro la clàusula on, què fa aquesta clàusula, és que realment es converteix una columna en majúscules i diu on és igual a majúscula. El que passa és cada vegada que s’executa aquesta cosa, Oracle ha de convertir aquesta columna en majúscules. En lloc de fer-ho gairebé cinquanta mil vegades, és molt més eficient crear aquest índex en majúscules d'un índex basat en funcions i està disponible no només a la divisió de l'empresa Oracle, sinó també a la divisió estàndard. Quan ho feu, el que podeu fer és verificar el pla d'execució emetent aquest majúscul permís per a l'usuari de l'índex, que només era el meu tema.
Aleshores, des d’una mesura abans i després, esteu buscant un temps d’execució d’un segon, que agregen fins a 9 hores 54 minuts, amb la mateixa instrucció SQL exacta, però tenint aquest índex construït en majúscules per a 58.000 execucions, la resposta el temps baixa fins a sub-milisegons, que s’agregen junts, arriba fins a set segons. Bàsicament vaig estalviar deu hores de CPU al meu servidor. Això és enorme. Perquè si no em correspon per una actualització del servidor, puc viure d'aquest servidor. De fet, baixo l'ús del servidor en un 20 per cent i realment podreu veure el abans i el després. Aquest és el tipus de visibilitat que pot proporcionar Precise. També podem considerar alguns aspectes addicionals, per què teniu tots aquests índexs si no s’utilitzen? Poden fer-ne el seguiment. Hi ha arquitectura i jo l'embarco, ja que arribem al capdamunt de l'hora. Sóc un veritable creient en aquesta solució i volem que siguis un veritable creient. A IDERA creiem que un assaig realitza un client, de manera que, si esteu interessats, podem fer avaluacions al vostre lloc.
Amb això, passaré la balisa enrere.
Eric Kavanagh: Sí, aquest ha estat el detall enorme que heu mostrat aquí. És realment fascinant. Crec que potser t'havia esmentat anteriorment que, i en alguns dels altres transmissions web que hem fet amb IDERA, ja ho he mencionat, realment he realitzat un seguiment precís des de l'IDERA, tot el camí que es va tornar al 2008, crec, o al 2009. Em fascinava. Tinc curiositat per saber la quantitat de treball que suposa mantenir-se al capdavant de les novetats d’aplicacions. Heu dit que SAP HANA, que crec que va ser força impressionant que, realment, podeu excavar a l'arquitectura HANA i fer alguns problemes per solucionar-los. Quanta gent tens? Quin esforç voleu fer de la vostra part i què es pot fer una mica dinàmicament, és a dir, quan es desplega l'eina, comenceu a arrossegar i veure coses diferents? Quant a això es pot dinàmicament, comprovar-ho amb l'eina, de manera que pugueu ajudar la gent a solucionar entorns complexos?
Bill Ellis: Hi heu fet moltes preguntes.
Eric Kavanagh: Ho sé, ho sento.
Bill Ellis: Vaig proporcionar molts detalls perquè, per a aquestes aplicacions, mirant el codi, el diable és detallat. Heu de tenir aquest nivell de detall per tal de poder tenir una cosa que sigui actuable. Sense mètriques actuables, només coneixeu els símptomes. En realitat no esteu resolent problemes. IDERA tracta de resoldre problemes. Estar al capdavant de les novetats i novetats és un gran repte. La pregunta de què cal fer-ho, realment és per a la gestió de productes. No tinc molta visibilitat en l'equip que bàsicament ens manté al dia sobre les coses. Pel que fa a HANA, realment és una nova incorporació a la línia de productes IDERA; és molt emocionant. Una de les coses amb HANA és: deixeu-me parlar sobre la tasca durant un segon. En la tasca, els comerços SAP farien és que repetissin la base de dades amb finalitats d'informes. Aleshores, haureu de fer que la gent es reconcilia amb el que hi ha actualment. Teniu aquestes bases de dades diferents i estarien sincronitzades per diferents nivells. Hi ha molt temps i esforç, a més del maquinari, el programari i la gent per mantenir-ho.
La idea de HANA de tenir una base de dades de memòria altament paral·lela, per evitar bàsicament la necessitat de bases de dades duplicades. Tenim una base de dades, una font de veritat, sempre està actualitzada, i així evitareu el necessari per fer tota la reconciliació. La importància del rendiment de la base de dades HANA augmenta; vaig a dir 10 vegades o, almenys, més valuosa que la suma de totes aquelles altres bases de dades, hardware, recursos que es poden comprar. Al ser capaç de gestionar HANA, ara aquest component es troba en fase de prova beta ara mateix, és una cosa que passarà aviat a GA. Així doncs, és molt emocionant per a IDERA i per a nosaltres per donar suport bàsicament a la plataforma SAP. No estic segur de quines altres parts de la vostra pregunta he sortit de canvis breus, però …
Eric Kavanagh: No hi ha totes coses bones. Vaig llançar un munt de vostès a la vegada, tan greu per això. Estic fascinat, realment, vull dir que no es tracta d’una aplicació molt senzilla, oi? Estàs aprofundint en aquestes eines i entenent com interaccionen els uns amb els altres i fins al vostre punt, heu d’amassar una història al cap. Heu de combinar trossos d’informació per comprendre el que passa realment i el que us causa el problema, de manera que podreu entrar-hi i resoldre aquests problemes.
Un assistent es pregunta, quina dificultat té la implementació de Precise? Una altra persona va preguntar: quines són les persones, òbviament, els DBA, però quins són alguns altres rols de l'organització que utilitzarien aquesta eina?
Bill Ellis: La precisió és una mica més complicat de desplegar. Heu de tenir cert coneixement de l’entorn de l’aplicació, en relació amb, ja ho sabeu, que aquesta aplicació s’executa en aquesta base de dades, necessita o els servidors web de nivell mitjà, etc. Crec que donada la complexitat d’algunes d’aquestes aplicacions, en realitat és relativament fàcil. Si puc fer servir el servidor web a la vostra base de dades, puc fer aquest punt de final. Es nota que no he dit res sobre l’instrumentació d’un client d’usuari final i això és perquè el que fem és que realment inclouem dinàmicament, de manera que no cal canviar el codi ni res més. Un JavaScript entra al marc de la pàgina de l'aplicació. No importa on estigui l’usuari al món, quan accedeix a l’URL de la vostra aplicació i en baixi aquesta pàgina, s’instrumenta amb Precisa. Això ens permet triar l'ID d'usuari, la seva adreça IP, i també el primer temps de renderització de byte de cadascun dels components de la pàgina d'execució de scripts del navegador final.
Pel que fa a les transaccions, no heu de fer un mapa de les transaccions perquè estan fortament acoblades. Aquest URL es converteix en un punt d’entrada a JVM i després invoca aquest missatge, donant lloc a un JVC capturat de la base de dades. Bàsicament podem capturar aquells punts de connexió naturals i després presentar-los a la pantalla de transacció que us vaig mostrar on també calculem quant temps o el percentatge de temps que es va passar en cada pas. Tot això es fa automàticament. En general, destinem 90 minuts a fer - bàsicament per instal·lar el nucli Precise i llavors comencem a implementar l'aplicació. Depenent del coneixement de l'aplicació, pot trigar-nos a fer algunes sessions addicionals per obtenir tota l'aplicació instrumentada. Moltes persones utilitzen només el component de la base de dades de Precise. Està bé. Bàsicament, podeu dividir-lo en els components que creieu que necessita el vostre lloc. Creiem definitivament que el context d’instrumentar tota la pila d’aplicacions de manera que pugueu veure que la dependència de nivell a nivell augmenta el valor de controlar un nivell individual. Si algú vol explorar més enllà el seu instrument d'aplicacions, vés al nostre lloc web, suposo que és la forma més senzilla de sol·licitar informació addicional i ho discutirem una mica més.
Eric Kavanagh: Permetin-me llançar una o dues preguntes ràpides. Suposo que aneu recopilant i creant un dipòsit, tant per a clients individuals com per a una entitat corporativa, d’interaccions entre diverses aplicacions i diverses bases de dades. És a dir, suposo que el model d’escenari és el que al·ludeixo. És així? De fet, es manté una mena de dipòsit d'escenaris comuns per tal de fer suggeriments als usuaris finals quan entren en joc algunes coses? Com aquesta versió d'E-Business Suite, aquesta versió d'aquesta base de dades, etc.
Bill Ellis: Bé, aquest tipus d’informació s’incorpora a l’informe de conclusions. L’informe de conclusions diu quins són els colls d’ampolla de rendiment i es basa en el temps d’execució. Una part d’aquest informe de troballes és obtenir més informació i què feu després. La informació o l'experiència dels clients, etcètera, s'incorpora bàsicament a la biblioteca de recomanacions.
Eric Kavanagh: Està bé, això sona bé. Doncs gent, presentació fantàstica avui. Bill, em va encantar el detall que tenies. Simplement vaig pensar que aquesta era una informació fantàstica, grana i granular, que mostra com es fa tot això. En un moment determinat gairebé és com la màgia negra, però realment no ho és. És una tecnologia molt específica que ajuntes per comprendre entorns molt complexos i fer feliços a la gent perquè ningú no li agrada quan les aplicacions funcionen lentament.
Doncs bé, arxivarem aquest webcast. Podeu saltar en línia a Techopedia o a interioranalysis.com i wow, gràcies pel vostre temps, us farem arribar al proper moment. Cuida't, adéu.
