Por el personal de Techopedia, 2 de noviembre de 2016
Para llevar: El presentador Eric Kavanagh habla sobre el rendimiento de la aplicación y cómo mejorar la eficiencia con el Dr. Robin Bloor, Dez Blanchfield y Bill Ellis de IDERA.
Actualmente no has iniciado sesión. Inicia sesión o regístrate para ver el video.
Eric Kavanagh: Damas y caballeros, hola y bienvenidos nuevamente a Hot Technologies. Si de hecho! Mi nombre es Eric Kavanagh, seré su anfitrión para otra transmisión por Internet hoy en esta serie realmente divertida y emocionante que tenemos como complemento de nuestra serie Briefing Room. El título es "Aceleración de aplicaciones: rendimiento más rápido para usuarios finales". Vamos amigos, ¿quién no quiere eso? Si soy el tipo que está ayudando a que su aplicación se ejecute más rápido, creo que soy el tipo que me compran cervezas en el bar después del trabajo. Tiene que ser algo genial entrar y acelerar la aplicación de cualquier persona.
Hay una diapositiva sobre la tuya, contáctame en Twitter @Eric_Kavanagh. Siempre trato de seguir y siempre vuelvo a tuitear si me mencionas, así que siéntete libre de mencionarme.
Todo el propósito de este programa es enfocarse en diferentes aspectos de la tecnología empresarial y realmente ayudar a definir ciertas disciplinas o ciertos rostros, si lo desea. Muchas veces los vendedores se dan cuenta de ciertos términos de marketing y hablan sobre cómo hacen esto o aquello o alguna otra cosa. Este espectáculo fue realmente diseñado para ayudar a nuestra audiencia a comprender lo que una herramienta de software necesita tener para ser un líder en su espacio. El formato de esto es dos analistas. Cada uno va primero, a diferencia de la Sala de información donde el vendedor va primero. Cada uno da su opinión sobre lo que ellos piensan que es importante que usted sepa sobre un tipo particular de tecnología.
Hoy estamos hablando de la aceleración de aplicaciones. Vamos a escuchar a Dez Blanchfield y también al Doctor Robin Bloor, hoy estamos en todo el mundo, y luego Bill Ellis está llamando desde el área metropolitana de Virginia. Con eso, se lo entregaré a nuestro primer presentador, el Dr. Bloor. Por cierto, tuiteamos el hashtag de #podcast, así que no dudes en tuitear. Llevatelo.
Dr. Robin Bloor: Bien, bien, gracias por esa presentación. Rendimiento de la aplicación y niveles de servicio: este es un tipo de área, he trabajado mucho en esta área a lo largo de los años, en el sentido de que realmente he hecho un montón de trabajo en el monitoreo del desempeño y en el trabajo en uno de una forma u otra, cómo tratar de calcular esos niveles. Hay que decir que hasta que solíamos tener esta era, hace un tiempo, donde la gente construía sistemas en silos. Básicamente, la cantidad de trabajo que realmente tienen que hacer para que un sistema funcione razonablemente bien si estaba en un silo no era realmente demasiado difícil porque hay muy poca cantidad de variables que hay que tener en cuenta. Tan pronto como nos conectamos correctamente, la ecuación interactiva y de servicio entró en la ecuación. Se puso un poco difícil. El rendimiento puede ser unidimensional. Si solo piensa en una aplicación que ejecuta una ruta de código particular repetidamente, hacerlo razonablemente, de manera oportuna, se siente como una cosa unidimensional. Tan pronto como comienzas a hablar sobre los niveles de servicio, en realidad estás hablando de varias cosas que compiten por los recursos informáticos. Se vuelve multidimensional muy rápidamente. Si comienza a hablar sobre procesos empresariales, los procesos empresariales pueden unirse entre sí desde múltiples aplicaciones. Si habla de arquitectura orientada a servicios, una aplicación determinada puede acceder a las capacidades de múltiples aplicaciones. Entonces se convierte en algo muy complicado.
Miré, hace mucho tiempo, dibujé este diagrama. Este diagrama tiene al menos 20 años. Básicamente, lo llamo el Diagrama de todo porque es una forma de ver todo lo que existe en el entorno de TI. En realidad son solo cuatro piezas: usuarios, datos, software y hardware. Por supuesto, cambian con el tiempo, pero en realidad te das cuenta cuando miras esto que hay una explosión jerárquica de cada una de estas piezas. Un hardware sí, un hardware puede ser un servidor, pero un servidor consta de posiblemente múltiples CPU, tecnología de red y memoria, y esto, una gran cantidad de controladores, como sucede. Si realmente miras esto, todo se descompone en pedazos. Si realmente piensa en tratar de orquestar todo eso, con respecto a los datos que cambian, el rendimiento del software cambia, porque el hardware cambia, y así sucesivamente, en realidad está viendo una situación de múltiples variantes increíblemente difícil. Esta es la curva de complejidad. Por supuesto, es una curva de complejidad para casi todo, pero lo he visto dibujar una y otra vez cuando hablamos de computadoras. Básicamente, si coloca nodos en un eje y las conexiones importantes en el otro eje, termina con una curva de complejidad. Casi no importa cuáles son los nodos y las conexiones, y eso será suficiente si desea una representación del crecimiento del volumen en la red telefónica.
De hecho, cuando se habla de nodos en el entorno informático, se habla de cosas individuales que se preocupan entre sí. Resulta que la complejidad es una cuestión de estructura de variedad y las diversas restricciones que estás tratando de obedecer. Además, los números. Cuando los números suben, se vuelven locos. Ayer tuve una conversación interesante, estaba hablando con alguien, no puedo mencionar quién era, pero en realidad no importa, estaban hablando de un sitio que tenía 40, 000, es decir, cuatro cero, 40, 000 instancias de bases de datos. en el sitio. Solo piense en eso: 40, 000 bases de datos diferentes. Por supuesto, lo único que teníamos, obviamente tenían muchas, miles de aplicaciones. Estamos hablando de una organización muy grande, pero no puedo nombrarla. Realmente lo miras y estás intentando, de una forma u otra, obtener niveles de servicio que sean adecuados en todos los ámbitos para algunos usuarios múltiples, con múltiples expectativas diferentes, si lo deseas. Es una situación compleja, y todo lo que realmente digo es que esto es complejo. Los números siempre aumentan. Las restricciones están determinadas por los procesos comerciales y los objetivos comerciales. Habrás notado que las expectativas cambian.
Recuerdo que tan pronto como aparecieron Gmail, Yahoo Mail y Hotmail, todos esos sistemas de correo, la gente comenzó a tener una expectativa de que sus sistemas de correo interno dentro de la organización merecerían los niveles de servicio de estas enormes operaciones con vastas granjas de servidores fuera la organización y comenzó a ser presionada para que todo ese tipo de cosas suceda. En realidad, los acuerdos de nivel de servicio son una cosa, pero la expectativa es otra y luchan entre sí dentro de una organización, algo incómodo. Aquí hay solo una perspectiva comercial. En algunos sistemas, el tiempo de respuesta óptimo es una décima de segundo del tiempo de respuesta humano. Una décima de segundo es el tiempo que le toma a una cobra morderte. Si estás parado frente a una cobra y decide morderte, es demasiado tarde, porque no podrás responder en una décima de segundo. Una décima de segundo es aproximadamente el tiempo que le toma a la pelota dejar la mano del lanzador para alcanzar al tipo con el bate. Básicamente, cuando ve la pelota lanzada, tiene que responder exactamente en ese momento. Respuesta humana, algo interesante. Software a software, obviamente, puede tener una expectativa más alta.
Luego entras en algunas situaciones que creo que son esas situaciones de mercado, donde ser el primero es donde está el valor del negocio. Esto es como si desea vender una acción en particular en el mercado de valores probablemente sea menor, por ejemplo, porque cree que está bajando y muchas otras personas piensan que está bajando, obtendrá el mejor precio si llega primero al mercado. Hay muchas situaciones, publicación de anuncios y cosas así, situación muy similar. Tienes este movimiento en términos de expectativa de nivel de servicio. Tienes una cosa que es una especie de techo de cristal para la respuesta humana. Una vez que se trata de software a software, si tiene esta situación límite, entonces no hay un mejor nivel de servicio. Más rápido que todos los demás es lo mejor.
Bien, esta es, creo, la última diapositiva que estaba haciendo, pero esto es solo para darle una idea general de la complejidad, una vez que realmente mira los requisitos de una organización, el servicio. Tienes, subiendo por el lado izquierdo aquí, tienes la administración del sistema, que es un conjunto de software que sirve en la administración del servicio, que está tratando de administrar un nivel de servicio. Por encima de eso, tienes la gestión del rendimiento empresarial. Entonces, si mira el fondo aquí, el área de automatización de gestión de servicios, tiene servicios fragmentados que evolucionan a servicios estandarizados, si realmente le importa invertir en este tipo de cosas, que evolucionan a servicios integrados, que evolucionan a servicios optimizados . Principalmente lo que la gente ha hecho es, solo en la esquina inferior izquierda de esto. Tal vez un poco de gestión de servicios. Gestión del rendimiento empresarial, muy rara. Fragmentado, casi todo. Un mundo perfecto llenaría esa cuadrícula. Instrumentación: mencioné un problema de suboptimización. Puede optimizar partes de un sistema y no es bueno para todo el sistema. Si hace que el corazón sea óptimo, su sangre podría circular demasiado rápido para el resto de sus órganos. Ese es un problema con grandes organizaciones y niveles de servicio. Claramente, nada se logrará sin herramientas sofisticadas porque las variables acaban de llegar, bueno, hay demasiadas variables para intentar optimizar.
Dicho esto, pasaré a Dez, quien hablará de algo completamente diferente, con suerte.
Dez Blanchfield: Gracias Robin. Al igual que el Dr. Robin Bloor, he pasado demasiados años pensando en el rendimiento de sistemas muy complejos a gran escala. Probablemente no sea la misma escala que Robin, pero el rendimiento es un tema diario y es parte de nuestro ADN querer rendimiento, para obtener lo mejor de todo. De hecho, he usado un gráfico de una de mis cosas favoritas en el mundo, las carreras de autos de Fórmula I, donde todo el planeta se queda quieto por un tiempo y observa cómo los autos giran en círculos muy rápidamente. En cada aspecto, no hay ningún aspecto de la Fórmula I que no se trate específicamente de obtener rendimiento. Mucha gente caca el deporte porque piensan que es una pérdida de dinero. Resulta que el automóvil que manejamos todos los días para dejar a los niños en el fútbol los fines de semana y la escuela los otros días, se deriva del desarrollo y la investigación basados en el rendimiento. Es como la vida de las carreras de coches de Fórmula I. La tecnología cotidiana, la ciencia cotidiana, a menudo proviene de cosas que se han centrado exclusivamente en el alto rendimiento.
Sin embargo, la realidad es que nuestro nuevo mundo "siempre activo", que exige un tiempo de actividad del 100 por ciento, como Robin mencionó anteriormente, con cosas como la introducción del correo web y otros servicios que damos por sentado en un espacio continuo, y ahora esperamos que en Nuestro entorno empresarial y de trabajo. La realidad es que estar despierto no siempre significa que cumple con su acuerdo de nivel de servicio. Considero que la necesidad de gestionar el rendimiento de la aplicación y la disponibilidad de los acuerdos de nivel de servicio ha experimentado un cambio fundamental en la última década. Ya no solo tratamos de preocuparnos por el rendimiento de un sistema. Cuando el mundo era un poco más simple, podríamos tener una situación en la que un solo servidor que ejecuta múltiples servicios se puede monitorear en vivo y era relativamente sencillo de soportar. Podríamos, y aquí está mi pequeña, las cosas de las que solíamos preocuparnos cuando era administrador del sistema, por ejemplo, hace muchos años, miraríamos a nuestro alrededor, ¿el servicio generalmente funciona y responde? ¿Puedo iniciar sesión en una terminal, por ejemplo? ¿El sistema operativo responde y puedo escribir comandos? ¿Están las aplicaciones en funcionamiento? ¿Puedo ver procesos y memoria al hacer cosas y E / S a través de la red, etc.? En los días de mainframe se podían escuchar cintas que se volvían zip-zip-zip y el papel se caía.
¿Las aplicaciones responden y podemos iniciar sesión y hacer cosas en ellas? ¿Los usuarios pueden conectarse a algunos de esos servidores? Continúa. Son bastante fundamentales, ya sabes. Luego, algunas divertidas: ¿es verde la mesa de ayuda? Porque si no, entonces todo está funcionando bien, ¿y quién recibirá las donas? La vida era realmente simple en esos días. Incluso en esos días, y luego estoy hablando hace 20-30 años, la complejidad todavía era realmente alta. Podríamos, de una manera relativamente sencilla, gestionar los acuerdos de nivel de servicio y vigilar el rendimiento. Ya no podemos hacerlo a mano, como Robin aludió. El desafío es demasiado grande. El hecho es el momento en que algunas buenas aplicaciones, administradores, red del sistema y base de datos, los administradores pueden monitorear y cumplir con los SLA de rendimiento. Los acuerdos de nivel de servicio han ido tan lejos ahora que luché anoche cuando estaba juntando mis notas finales para pensar en el año en que logré mirar un sistema de una pila muy compleja, darle sentido e incluso comprender lo que era pasando por debajo del capó, y vengo de un fondo profundamente técnico. No puedo imaginar cómo es enfrentar eso día a día ahora de manera administrativa.
¿Que pasó? Bueno, en 1996, las aplicaciones basadas en bases de datos se transformaron con el auge de Internet. Muchos de nosotros hemos pasado por eso. Incluso si no estuvieras cerca del auge de Internet, puedes mirar fácilmente y darte cuenta de que en la vida cotidiana, ahora conectamos todo a Internet. Creo que tenemos una tostadora que aparentemente viene con la opción de conectarse a Wi-Fi, lo cual es ridículo, porque no necesito mi tostadora conectada a Internet. En la década de 2000, particularmente a principios de la década de 2000, tuvimos que lidiar con este crecimiento masivo en la complejidad de la entrega de rendimiento del servicio en el auge de las puntocom. Luego, otra chispa ridícula e incómoda en la web 2.0, donde surgieron los teléfonos inteligentes y ahora las aplicaciones estaban en nuestras manos 24/7 y estaban siempre en modo encendido.
Ahora es 2016, nos enfrentamos a otro atolladero en forma de nube y big data y movilidad. Estos son sistemas que son tan grandes que a menudo son difíciles de comprender y poner en inglés simple. Cuando pensamos en el hecho de que algunos de los grandes unicornios de los que hablamos tienen decenas de cientos de petabytes de datos. Este es un piso completo de espacio en disco y almacenamiento solo para guardar su correo electrónico, imágenes y redes sociales. O, en algunos casos, en logística de transporte y envío, todo está en la banca, es donde está su dinero, o dónde está su publicación, o dónde está lo que compró en eBay. La próxima gran ola que estamos a punto de enfrentar es este gran desafío del internet de las cosas.
Si esto no fuera lo suficientemente malo, estamos a punto de construir inteligencia artificial y computación cognitiva en casi todo. Hablamos con los motores Siri y Google en estos días. Sé que Amazon tiene uno propio. Baidu tiene uno de estos dispositivos con los que puede hablar, lo convierten en texto que entra en un sistema normal, la base de datos realiza una consulta y regresa e invierte el proceso. Piensa en la complejidad que eso conlleva. La realidad es que la complejidad de la pila de aplicaciones estándar actual está mucho más allá de las capacidades humanas. Cuando piensa en todo lo que sucede cuando presiona un botón en el dispositivo de su teléfono inteligente o tableta, lo habla, lo convierte en texto, lo ejecuta todo el camino a Internet en un sistema de back-end, recibe un front-end eso, lo convierte en una consulta, ejecuta la consulta a través de una pila de aplicaciones, revisa una base de datos, golpea el disco, vuelve a salir, y en el medio hay una red de operadores, hay un centro de estado de la red de área local. La complejidad es una locura.
Efectivamente afirmamos que esto es hiperescala. La complejidad y la velocidad de la hiperescala es solo lagrimeo. Las aplicaciones y las bases de datos se han vuelto tan grandes y tan complejas que, de hecho, gestionar el rendimiento es una ciencia en sí misma. Muchos se refieren a ella como una ciencia espacial. Tenemos tecnología en el sitio, tenemos tecnología fuera del sitio, tenemos una gama de opciones de centro de datos; Físico y virtual. Tenemos servidores físicos y virtuales, tenemos nube, tenemos infraestructura como servicio y plataforma como servicio y software como servicio es algo que ahora damos por sentado. El último, el software como servicio, se volvió aterrador por un tiempo hace unos años cuando los directores financieros y partes de la organización se dieron cuenta de que podían recoger su tarjeta de crédito y simplemente comprar cosas ellos mismos y rodear al CIO y efectivamente llamamos a esto "sombra IT ”y los CIO ahora intentan revertir esto y luchar contra el control.
En infraestructura tenemos redes definidas por software, virtualización de funciones de red, debajo de las cuales tenemos, probablemente más, ahora tenemos micro servicios y aplicaciones de servicios activos. Cuando hace clic en una URL, hay un montón de lógica empresarial que se encuentra al final de esa URL que describe lo que realmente necesita para entregarla. No necesariamente tiene una lógica preconstruida esperándola. Tenemos bases de datos tradicionales en un lado que están escalando muy, muy grande. Tenemos los gustos de la infraestructura y los ecosistemas de Hadoop en el otro espectro que son tan grandes que, como dije, ya sabes, la gente está hablando de cientos de petabytes de datos ahora. Tenemos movilidad compleja en cuanto a dispositivos que llevan, computadoras portátiles, teléfonos y tabletas.
Tenemos BYOD en algunos entornos cerrados y cada vez más, ya que las personas con experiencia Gen Y están trayendo sus propios dispositivos. Simplemente les dejamos hablar con ellos sobre las interfaces web. Ya sea a través de Internet o por Wi-Fi, tenemos una conexión Wi-Fi gratuita en la cafetería de la planta baja, ya que están tomando café. O nuestro wifi interno. Máquina a máquina está siempre presente ahora. Eso no es directamente parte de Internet de las cosas, pero también está relacionado. Internet de las cosas es un juego completamente nuevo de una complejidad que es alucinante. Inteligencia artificial, y si crees que con lo que estamos jugando ahora, con todos los Siri y otros dispositivos relacionados con los que hablamos es complejo, espera hasta que llegues a una situación en la que veas algo llamado Olli, que es un 3-D autobús impreso que toma alrededor de seis personas y puede conducir por la ciudad y usted puede hablar inglés sin problemas, y le responderá. Si golpea el tráfico, decidirá girar a la izquierda o derecha del área principal donde hay tráfico. A medida que gira y te preocupa por qué gira a la izquierda o derecha de la carretera principal, te dirá: "No te preocupes, estoy a punto de girar a la izquierda. Hay tráfico por delante y voy a dar la vuelta ".
Administrar el rendimiento de todos los sistemas allí y toda la complejidad, rastrear dónde van esos datos, ya sea que vayan a la base de datos, a todas las interconexiones y a todos los bits relevantes es simplemente alucinante. La realidad es que administrar el rendimiento y los SLA a la velocidad y escala actuales requiere herramientas y sistemas, y por defecto esto ya no es algo en lo que uno pensaría que sería bueno tener una herramienta, es un requisito previo; Es absolutamente necesario. Aquí hay algo como un pequeño ejemplo, una lista de los diagramas de diseño de aplicaciones de alto nivel para OpenStack, la nube definida por software de código abierto. Esto es solo una gran parte. Esto no es solo servidores y bases de datos. Aquí es donde cada pequeña mancha azul representa grupos de cosas. En algunos casos, archivos y servidores o cientos de bases de datos o, por supuesto, no más de decenas de miles de pequeñas piezas de lógica de aplicaciones en ejecución. Esa es una versión pequeña. Realmente es bastante alucinante cuando comienzas a pensar en la complejidad que surge en esto. Hoy, incluso en el gran espacio de datos, pondré algunas capturas de pantalla solo de las marcas. Cuando piensas en todas las piezas que tenemos que gestionar aquí, no estamos hablando solo de una marca necesariamente, estas son todas las marcas en el panorama de big data y la marca superior, no solo todas las pequeñas o de código abierto. Te ves y piensas que es un cuadro bastante alucinante.
Echemos un vistazo a un par de verticales. Tomemos marketing, por ejemplo. Aquí hay un cuadro similar pero de las pilas de tecnología que están disponibles solo en tecnología de marketing. Este es el gráfico de 2011. Aquí está la versión 2016. Solo piense, esta es solo la cantidad de marcas de productos que puede utilizar para la tecnología con respecto a la tecnología de marketing. No es la complejidad de los sistemas que hay allí, ni las diferentes aplicaciones, sitios web, desarrollo y redes, y todo lo demás. Solo la marca. Existe el antes, hace cinco años y aquí está hoy. Solo va a empeorar. Estamos en este punto donde la realidad es que los humanos simplemente no pueden garantizar todos los acuerdos de nivel de servicio. No podemos sumergirnos en suficientes detalles, lo suficientemente rápido y a la escala que necesitamos. Aquí hay un ejemplo de cómo se ve una consola de monitoreo ahora. Esto es como casi veinte pantallas pegadas juntas fingiendo ser una gran pantalla proyectada que monitorea cada pequeña pieza. Ahora es interesante aquí, no mencionaré la marca, pero esta plataforma de monitoreo está monitoreando una sola aplicación en un entorno de logística y envío. Solo una aplicación. Si piensa en lo que Robin estaba hablando, donde las organizaciones pueden tener 40, 000 bases de datos ahora en entornos de producción. ¿Puede visualizar cómo podrían ser 40, 000 versiones de esta colección de pantallas que monitorean una aplicación? Es un mundo muy valiente en el que vivimos. Como Robin dijo y yo absolutamente, 100 por ciento se hará eco de que, sin las herramientas adecuadas, sin el apoyo adecuado y la gente en la mesa que usa esas herramientas, el rendimiento de la aplicación es un juego perdido para los humanos y Tiene que hacerse con herramientas y software.
Con eso pasaré a nuestros amigos en IDERA.
Eric Kavanagh: Muy bien, Bill.
Bill Ellis: gracias. Compartiendo mi pantalla aquí. Supongo que alguien puede confirmar que puedes ver mi pantalla?
Dr. Robin Bloor: Sí.
Eric Kavanagh: Se ve bien.
Bill Ellis: gracias. Lo único a lo que se refirió fue que realmente no puedo esperar fue el auto sin conductor. Lo único de lo que no había oído hablar a nadie es, ¿qué sucede cuando nieva? Me pregunto si los ingenieros de California se dieron cuenta de que en otras partes del país nieva bastante.
Dez Blanchfield: Me gusta eso, voy a recordar eso.
Eric Kavanagh: Una típica milla por hora.
Bill Ellis: Estamos aquí para hablar sobre la gestión del rendimiento de las aplicaciones en un entorno complejo. Una cosa de la que me gusta hablar es que mucha gente, cuando habla de rendimiento, la naturaleza de la reacción es, oye más servidores, más CPU, más memoria, etc. El otro lado de esa moneda es la eficiencia del procesamiento. Realmente, son dos caras de la misma moneda y vamos a echar un vistazo a ambas. El objetivo final es cumplir con los acuerdos de nivel de servicio para las transacciones comerciales. En definitiva, toda esta tecnología existe para el negocio. Hablamos de tener una primera base de datos de gestión del rendimiento de la industria. Lo ideal es encajar en el molde ideal de rendimiento y administrarlo desde el comienzo del ciclo de vida de las aplicaciones.
Los temas realmente se reducen a cuatro piezas; uno es el proceso de gestión del rendimiento. Hablamos con todos, y todos tienen herramientas. Si no tienen herramientas, tienen scripts o comandos, pero lo que les falta es el contexto. El contexto es simplemente conectar los puntos a través de las pilas de aplicaciones. Estas aplicaciones para - están basadas en el navegador. Están muy unidos de nivel en nivel. Cómo interactúan los niveles también es vital. Entonces, estamos hablando de la transacción comercial. Vamos a proporcionar visibilidad no solo a los técnicos, sino también a los propietarios de las aplicaciones y los gerentes de operaciones.
Tengo un par de casos de estudio para compartir con ustedes cómo los clientes los han puesto en práctica. Esta es una parte muy práctica de la presentación aquí. Echemos un vistazo a lo que suele suceder. Me gusta diagramar, fue como un increíble collage de tecnologías. La cantidad de tecnologías en el centro de datos acaba de crecer, crecer y crecer. Mientras tanto, a un usuario final no le importa y es ajeno a él. Solo quieren ejercer la transacción, tenerla disponible, completarla rápidamente. Lo que suele suceder es que los profesionales de TI no son conscientes de que los usuarios finales incluso tuvieron un problema, hasta que se autoinforman. Eso da inicio a un proceso lento, lento y, a menudo, frustrante. Lo que sucede es que las personas abrirán sus herramientas y mirarán un subconjunto de su pila de aplicaciones. Con ese subconjunto, se hace muy difícil responder la pregunta más simple. ¿Es habitual que tengas el problema? ¿Qué transacción es? ¿Dónde en la pila de aplicaciones está el cuello de botella? Al pasar todo este tiempo, mirando nivel por nivel, sin poder responder a estas preguntas, terminas gastando mucho tiempo y energía, mucho personal, fondos y energía para descubrirlo.
Para resolver esto, para proporcionar una mejor manera, lo que hace Precise es tomar la transacción de seguimiento del usuario final, captura metadatos al respecto, sigue la transacción a través de la red, en el servidor web, en el nivel de lógica de negocios y admitimos .NET y ABAP y PeopleCode y E-Business Suite, en aplicaciones de varios niveles que, en última instancia, todas las transacciones van a interactuar con el sistema de registro. Ya sea que se trate de una búsqueda de inventario, de informes de tiempo trabajado, siempre interactúan con la base de datos. La base de datos se convierte en la base del rendimiento empresarial. La base de datos, a su vez, depende del almacenamiento. Qué responden los metadatos sobre las transacciones, quién, qué transacción, en qué lugar de la pila de aplicaciones, y luego tenemos una visibilidad profunda a nivel de código para mostrarle lo que se está ejecutando. Esta información se captura de forma continua y se coloca en la base de datos de gestión del rendimiento, que se convierte en una sola partitura para que todos puedan ver lo que está sucediendo. Hay diferentes personas y organizaciones que se preocupan por lo que está sucediendo: los expertos técnicos, los propietarios de las aplicaciones, en última instancia, el negocio en sí. Cuando surge un problema, desea poder extraer información sobre esa transacción.
Antes de que veamos la transacción de inversión, quiero mostrarles cómo podría parecer eso a diferentes personas de la organización. En un nivel de administración, es posible que desee tener una visión general de múltiples aplicaciones. Es posible que desee saber sobre el estado que se calcula según el cumplimiento y la disponibilidad de SLA. Esa salud no significa que todo funcione al 100 por ciento a la perfección. Hay espacio en este caso, puede ver que la transacción de inversión se encuentra en el estado de advertencia. Ahora, un poco más profundo, tal vez en la línea de negocio, desea tener algunos detalles adicionales sobre las transacciones individuales, cuando violan los SLA, los recuentos de transacciones, etc. El equipo de operaciones querrá ser notificado al respecto a través de una alerta de algunos ordenar. Tenemos alertas de rendimiento integradas. De hecho, medimos el rendimiento en el navegador del usuario final. Ya sea que seamos capaces de detectar Internet Explorer, Chrome, Firefox, etc., esto responde a la primera pregunta: ¿tiene un problema un usuario final?
Vamos a sumergirnos y ver qué más podemos mostrar sobre eso. Las personas que están interesadas en el rendimiento abrirían Precise. Evaluarían las transacciones. Mirarían la columna SLA para identificar transacciones que no cumplían con SLA. Podrían ver a los usuarios finales que se vieron afectados, así como lo que hizo esa transacción a medida que fluía por la aplicación. La forma en que descifra estos jeroglíficos es, este es el navegador, la URL, la U es para URL, ese es el punto de entrada a la JVM. Ahora, esta JVM particular hace que un servidor web llame a la segunda JVM que luego ejecuta la instrucción SQL. Esto es claramente un problema de la base de datos porque esta declaración SQL fue responsable del 72 por ciento del tiempo de respuesta. Estamos enfocados en el tiempo. El tiempo es la moneda del rendimiento. Es cómo los usuarios finales experimentan si las cosas se ejecutan lentamente o no, y es una medida del consumo de recursos. Es muy útil; Es una especie de métrica única que es más importante para evaluar el rendimiento. Cuando este problema se transfiere al DBA, no es solo un problema de base de datos, es esta declaración SQL. Este es el contexto del que estaba hablando.
Ahora armado con esta información, puedo entrar y analizar lo que sucedió. En primer lugar, puedo ver que el eje y es la hora del día. Disculpe, el eje y es el tiempo de respuesta, el eje x es el tiempo durante todo el día. Puedo ver que hay un problema con la base de datos, hay dos ocurrencias, regrese a ese flujo, tome esa declaración SQL y vaya a la vista experta, donde Precise puede mostrarle lo que está sucediendo, sus controles, cuánto tiempo tarda ese código en ejecutar. En el nivel de la base de datos, es el plan de ejecución. Notará que Precise seleccionó el plan de ejecución real que se usó en el momento de la ejecución, que se distingue del plan estimado, que sería cuando se entregó el plan y no durante el tiempo de ejecución. Puede o no reflejar que la base de datos realmente lo hizo.
Ahora aquí abajo, hay un análisis de tiempo de respuesta para la instrucción SQL. El noventa por ciento del tiempo dedicado al almacenamiento; el diez por ciento se usó en la CPU. Puedo ver el texto de la declaración SQL, así como el informe de resultados. El texto de la declaración SQL en realidad comienza a revelar algunos problemas de codificación. Es estrella selecta; eso devuelve todas las filas: disculpe, todas las columnas de las filas que se devolvieron. Retornamos columnas adicionales que la aplicación puede o no necesitar. Esas columnas consumen espacio y recursos para procesar. Si ejecuta SAP, uno de los grandes cambios, debido a que la base de datos de HANA es columnar, es que básicamente reescribe SAP para no elegir la estrella seleccionada para que puedan reducir en gran medida el consumo de recursos. Esto es básicamente algo que sucede mucho tiempo también en aplicaciones de cosecha propia, ya sea Java, .NET, etc.
Esa pantalla, te muestra quién, qué, cuándo, dónde y por qué. El por qué llega, como la declaración SQL y el plan de ejecución que le permite resolver problemas. Debido a que Precise se ejecuta continuamente, en realidad puede medir antes y después, a nivel de instrucción SQL, a nivel de transacción, de modo que puede medirlo usted mismo, así como a través de los propietarios de la aplicación y para la administración, que ha resuelto el problema . Esa documentación es realmente útil. Hay mucha complejidad en esta pila de aplicaciones. De muchas aplicaciones, de hecho, todas las personas con las que hemos hablado ejecutan al menos una parte de la pila de aplicaciones en VMware. En este caso, están mirando la aplicación de servicio al cliente, están mirando el tiempo de transacción y correlacionarlo con la desaceleración es un evento de virtualización. Rastrea con precisión todos los eventos de virtualización. Tenemos un complemento para vCenter para recoger eso.
También podemos detectar contenciones. La contención es diferente a la utilización. En realidad, muestra cuándo quizás un vecino ruidoso está afectando su máquina virtual invitada, en el contexto de la aplicación del servidor del cliente. Ahora, puedo profundizar y obtener información y puedo ver las dos máquinas virtuales que compiten, en este caso, por los recursos de la CPU. Esto me permite tener visibilidad para poder ver la programación. Puedo poner una máquina virtual invitada en un servidor físico diferente. Todos estos tipos de cosas que podría responder y luego, además de eso, realmente puedo ver la eficiencia del código para que tal vez use menos CPU. Creo que tengo un buen ejemplo en esta presentación de cómo alguien pudo reducir el consumo de CPU en órdenes de magnitud.
Eso fue VMware. Vamos al código mismo, el código de la aplicación. Precise podrá mostrarle lo que sucede en Java, .NET, el código ABAP, E-Business, PeopleCode, etc. Estos son los puntos de entrada, en este caso, a WebLogic. Aquí abajo, hay un informe de hallazgos que me dice que son estos EJB los que debe observar, y me dirá que también está ocurriendo el bloqueo en este sistema. Una vez más, profundice en el nivel de lógica de negocios para mostrar lo que está sucediendo. En este caso, estoy viendo casos particulares; También apoyo el agrupamiento. Si tiene numerosas JVM en ejecución, puede mirar el clúster en su conjunto o mirar los cuellos de botella dentro de la JVM individual.
A medida que entras en el bloqueo, puedo entrar en excepciones. La excepción es un poco diferente a un problema de rendimiento. Por lo general, las excepciones se ejecutan muy rápido. Debido a que hay un error lógico y una vez que aciertas ese error lógico, termina. Pudimos capturar un seguimiento de la pila en el mejor momento de una excepción, esto podría ahorrar mucho tiempo, ya que se está tratando de descubrir qué está pasando, solo tienes el seguimiento de la pila, allí mismo. También podemos capturar pérdidas de memoria también. La solución también incluye el nivel de la base de datos, puedo ingresar, puedo evaluar la instancia de la base de datos. Una vez más, el eje y es donde se pasó el tiempo, el eje x es el tiempo durante todo el día. Hay un informe de hallazgos que automáticamente me dice lo que está sucediendo en el sistema y lo que podría mirar.
Una de las cosas sobre el informe de hallazgos de Precise, no solo mira los registros o el estado de espera, sino también todos los estados de ejecución, incluida la CPU, así como la devolución de información del almacenamiento. El almacenamiento es una parte muy importante de la pila de aplicaciones, especialmente con la llegada del estado sólido. Tener información en ese sentido puede ser muy útil. Para ciertas unidades de almacenamiento, en realidad podemos profundizar y mostrar lo que está sucediendo a nivel de dispositivo individual. Ese tipo de información, una vez más, es una visibilidad profunda; es de amplio alcance: para brindarle la información suficiente para tener más influencia como profesional de rendimiento de aplicaciones, de modo que pueda optimizar sus aplicaciones de forma integral para satisfacer esas transacciones comerciales.
Tengo un par de casos de estudio que quería compartir con ustedes. Navegamos bastante rápido; Espero ir a un buen ritmo. Hablando de almacenamiento, todos con el tiempo cambian el hardware. Hay una garantía de hardware. ¿Realmente entregó lo que el vendedor le dijo? Puede evaluar eso con Precise. Entras, y lo que sucedió aquí, básicamente pusieron una nueva unidad de almacenamiento, pero cuando los administradores de almacenamiento miraron solo el nivel de la unidad de almacenamiento, vieron mucha contención y pensaron que podría haber un problema con esta nueva unidad de almacenamiento . Mirando más desde una perspectiva de extremo a extremo, precisamente para mostrar dónde sucedería eso realmente. En realidad, pasaron de un rendimiento de aproximadamente 400 meg por segundo, donde el almacenamiento fue responsable del 38 por ciento del tiempo de respuesta, por lo que es bastante alto. Con la nueva unidad de almacenamiento, aumentamos el rendimiento a seis, setecientos megas por segundo, básicamente el doble, y podemos reducir a la mitad la contribución del nivel de almacenamiento al tiempo de transacción. Realmente puedo graficar eso antes, este es el período de transición y luego el posterior.
Entonces, una vez más, documentación para probar que la inversión en hardware valió la pena y se entregaron como ese vendedor en particular había esperado. Hay todo, debido a la complejidad, la cantidad de cosas, hay todo tipo de cosas que pueden suceder. En este caso, en realidad tenían una situación en la que todos culpaban al DBA, el DBA era como "Bueno, no tan rápido". Aquí en realidad estamos viendo una aplicación SAP, creo que este tipo de escenario es bastante común . Lo que sucedió fue que estaban desarrollando una transacción personalizada para un usuario. El usuario dice: "Esto es muy lento". El codificador ABAP, que es el lenguaje de programación en SAP, dijo: "Este es un problema de base de datos". Terminaron abriendo Precise; midieron a ese usuario final 60 segundos, más de un minuto. Cincuenta y tres segundos se gastaron en la parte de atrás. Perforaron en el back-end y pudieron revelar la declaración SQL presentada en orden descendente.
Esta declaración SQL principal que es responsable del 25 por ciento del consumo de recursos, su tiempo de ejecución promedio es de dos milisegundos. No puedes culpar a la base de datos. Sabes, oye, no tan rápido, chico. La pregunta es, ¿por qué hay tantas ejecuciones? Bueno, lo devolvieron al ABAP, él entró, examinó el anidamiento del bucle, descubrió que estaban llamando a la base de datos en el lugar equivocado, básicamente hicieron el cambio, probaron el cambio y ahora el nuevo tiempo de respuesta es cinco segundos. Un poco lento, pero podrían vivir con eso. Mucho mejor que 60 segundos. A veces, simplemente descubriendo, ¿es el código de la aplicación, es la base de datos, es el almacenamiento? Esas son las áreas donde Precise, al tener el contexto de las transacciones de extremo a extremo, es donde entra en juego Precise. Básicamente terminas esas cosas.
Estoy mirando la hora, parece que todavía tenemos un poco de tiempo para revisar un par más de estos. Estoy transmitiendo a través de estos. Esta aplicación estuvo en desarrollo durante más de un año. Cuando entraron en el control de calidad, vieron que los servidores web estaban al 100 por ciento al máximo y parecía que la aplicación no podía ejecutarse con VMware. Lo primero que todo el mundo dijo fue: "Ponga esto en forma física; no puede ejecutarse con VMware ”. Precise en realidad les ofreció formas adicionales de resolver el problema. Observamos las transacciones, vimos una llamada al servidor web, viene como un ASMX en IIS.NET. En realidad, reveló el código subyacente. ¿Ves esto donde estoy señalando? Esto es 23 días, 11 horas. Wow, ¿cómo es eso posible? Bueno, cada invocación tarda 9, 4 segundos y esta cosa se invoca 215, 000 veces. Para cada invocación, utiliza 6 segundos de CPU. Esta es la razón, este código es la razón por la cual esto nunca podría escalar. De hecho, no podía escalar en físico.
Lo que hicieron fue volver a sus desarrolladores y les dijeron: "¿Alguien puede hacer un cambio?". Como que tuvieron un concurso, probaron las diferentes sugerencias y se les ocurrió una sugerencia que fue capaz de ejecutar mucho más eficientemente El nuevo completó un punto, un poco menos de dos segundos, con dos centésimas de segundo en la CPU. Ahora esto podría escalar y podría ejecutarse en la granja de VMware. Básicamente pudimos documentar eso tanto a nivel de código como a nivel de transacción. Este es el tipo de antes y luego el después. Ahora que puede ver aquí en el gráfico de barras de la pila que muestra web, .NET y la base de datos, ahora está interactuando con la base de datos. Este es un perfil que esperaría ver para una aplicación que se ejecuta más normalmente.
Muy bien, estoy escogiendo y eligiendo en términos de cosas adicionales que puedo mostrarte. A mucha gente le gusta esto porque deslumbra a muchas tiendas. Si no puede cumplir con un SLA comercial, y todo el mundo dice: “Ayúdenos”. Esta tienda tenía una situación en la que el SLA comercial estaba en pedidos recibidos antes de las 3 pm, se envió ese día. Es realmente vital que obtengan los pedidos, y el almacén está muy ocupado. Esta pantalla de pedido de ventas de JD Edwards se estaba congelando y puede tener una muy buena idea de que este es un sistema de administración de inventario minorista justo a tiempo. Los estantes vacíos son inaceptables en el comercio minorista. Tengo que tener la mercancía allí para venderla. Lo que hicimos fue sumergirnos, en este caso, estamos mirando la base de datos del servidor SQL. La apariencia es la misma, ya sea SQL, Oracle, DB2 o Sybase.
Identificamos la selección de PS_PROD y podemos capturar la duración, el hecho de que se ejecutan mucho. El azul oscuro coincidía con la clave que decía que no estaban esperando algún estado de espera o algún registro o incluso almacenamiento: esto está limitado por la CPU. Rastreamos la declaración SQL en 34301, por lo que cada vez que se ejecuta esto, incrementamos nuestros contadores para realizar un seguimiento. Eso significa que tenemos un historial detallado y puedo acceder a él haciendo clic en el botón de ajuste. Aquí está la pestaña de historial. Esta pantalla aquí muestra la duración promedio versus los cambios. Miércoles, jueves y viernes, la duración promedio fue de aproximadamente dos décimas de segundo. Muy pocas pantallas se congelan, son capaces de cumplir con el SLA de negocios. El 27 de febrero, algo cambia y, de repente, el tiempo de ejecución está aquí, y eso es lo suficientemente lento como para causar tiempos de espera, lo que resulta en congelaciones de pantalla. Preciso, manteniendo un historial detallado, incluido el plan de ejecución y los cambios generales en los índices de la tabla si ese SQL está en uso. Pudimos detectar que el plan de acceso cambió el 27 de febrero. De lunes a viernes mala semana. El 5 de marzo, el plan de acceso cambió nuevamente. Esta es una buena semana. Esta estrella rosa nos dice el volumen actualizado.
Puede ver aquí que el número de filas en las tablas subyacentes está creciendo y esto es típico de una empresa. Quieres que tus mesas crezcan. La cuestión es que las instrucciones son analizadas, las instrucciones SQL entran, el optimizador tiene que decidir qué hacer y elegir cuándo el plan de ejecución es rápido, elegir otro plan de ejecución cuando es lento, lo que hace que la pantalla se congele. Sobre una base de tecnología profunda, necesito saber cuál es el plan de ejecución y Precise lo captura para mí completo con la marca de fecha y hora. Este es el que fue rápido y eficiente, este es el que fue lento e ineficiente. Esta combinación de filtros simplemente usa mucha más CPU para conciliar, para hacer esta declaración SQL particular. Todavía tienen el mismo efecto final, pero este básicamente tiene una receta más lenta y menos eficiente para entregar el conjunto de resultados. Entonces, pasamos a través. Oye, ¿tenemos tiempo para un par más?
Eric Kavanagh: Sí, adelante.
Bill Ellis: De acuerdo, saltaré adelante. Una cosa que quiero que tome en cuenta es que hablamos sobre hardware, hablamos sobre SAP, hablamos sobre .NET, hablamos sobre JD Edwards y el entorno Java-SQL Server. Esto es SAP, aquí estamos viendo PeopleSoft. La matriz de soporte de Precise es amplia y profunda. Si tiene una aplicación, lo más probable es que podamos instrumentarla para proporcionar este nivel de visibilidad. Uno de los mayores cambios que está ocurriendo en este momento es la movilidad. PeopleSoft introdujo la movilidad con su interfaz de usuario fluida. Fluid UI usa un sistema muy diferente. Esta aplicación está evolucionando. La interfaz de usuario de Fluid: lo que hace desde una perspectiva de gestión es que permite a los usuarios finales usar su teléfono y aumenta enormemente la productividad. Si tiene cientos o miles o incluso más empleados, si puede aumentar su productividad, 1–2 por ciento, puede tener un gran impacto en la nómina y todo lo demás. Lo que sucedió fue que esta tienda en particular lanzó la interfaz de usuario de PeopleSoft Fluid. Ahora, hablando de complejidad, esta es la pila PeopleSoft. Una aplicación, un mínimo de seis tecnologías, numerosos usuarios finales. ¿Cómo lo comienzas?
Una vez más, Precise podrá seguir estas transacciones. Lo que le mostramos aquí es un gráfico de barras apiladas que muestra el cliente, el servidor web, Java, la base de datos Tuxedo, la pila de aplicaciones PeopleSoft. Los mapas verdes para J2EE, que es una forma elegante de decir WebLogic. Este es el corte. Los usuarios finales comienzan a usar la interfaz de usuario de Fluid y el tiempo de respuesta va desde quizás un año y medio, dos segundos, hasta alrededor de nueve, diez segundos. Lo que esta pantalla no muestra es la cantidad de personas que "no respondieron". En realidad, se congelaron la pantalla en la aplicación. Echemos un vistazo a la visibilidad que Precise puede proporcionar a este cliente.
En primer lugar, cuando miro las transacciones de PeopleSoft, pueden ver básicamente, vimos este tipo de cosas en todos los ámbitos. Todas las transacciones se vieron afectadas, así como todas las ubicaciones. Por cierto, cuando miras esto, puedes ver ubicaciones en todo el mundo. Desde Asia Pacífico, hasta Europa y Norteamérica. El problema de rendimiento no se localizó en una transacción particular, o en una ubicación geográfica particular, es todo el sistema. Es una forma de decir que el cambio o la forma en que la interfaz de usuario de Fluid tuvo un impacto global. Puede ver aquí desde el punto de vista de la escalabilidad, las personas están tratando de hacer el mismo tipo de cantidad de actividad, pero el tiempo de respuesta básicamente se degrada y degrada. Puedes ver que las cosas no están escalando. Las cosas van muy, muy mal. Aquí, cuando miro el recuento de ejes y las conexiones concurrentes, ves algo que es muy interesante en términos del recuento de acceso y las conexiones. Aquí solo estamos ampliando hasta aproximadamente 5, 000 y usted está viendo aproximadamente, esto supera las 100 conexiones simultáneas. Esto se hace después; Esto es antes. Entonces, mi demanda real del sistema, si esto pudiera escalar, está en el rango de 300, 000. En los viejos tiempos, con la interfaz de usuario clásica, estás viendo 30 conexiones simultáneas.
Ahora, lo que esto le dice es que la interfaz de usuario de Fluid usa al menos 10 veces más conexiones simultáneas. Comenzamos a retirar lo que está sucediendo debajo de las cubiertas con PeopleSoft para que pueda comenzar a ver el impacto en los servidores web, el hecho de que los SLA están comenzando a violarse. No va a entrar en todo, pero lo que termina sucediendo es que básicamente dependen de la mensajería. Básicamente, el ejercicio es WebLogic y hace cola en Tuxedo. En realidad, hubo un problema de dependencia de varios niveles que apareció con la interfaz de usuario de Fluid, pero Precise pudo demostrar que por un montón de cosas diferentes, podemos centrarnos en cuál era el problema. Resulta que también hubo un problema en la base de datos. En realidad, hay un archivo de registro de mensajes y, debido a todos los usuarios concurrentes, ese archivo de registro se estaba bloqueando. Básicamente tenía cosas que ajustar, en cada nivel dentro de la pila de aplicaciones. Hablemos de la complejidad, aquí está el nivel de Tuxedo que le muestra las colas y también puede ver que el rendimiento se degrada dentro de este nivel. Pude ver los procesos; Pude ver los dominios y los servidores. En Tuxedo, para que la gente use eso, normalmente lo que haces es abrir colas, dominios y servidores adicionales, al igual que en el supermercado para aliviar la congestión y minimizar el tiempo de espera. Última y última opción, Precise muestra mucha información.
Como mencioné anteriormente, cada transacción importante interactúa con el sistema de registros. La visibilidad en la base de datos es primordial. Precise muestra lo que sucede dentro de la base de datos, dentro de WebLogic, dentro de Java, .NET, dentro del navegador, pero el lugar en el que Precise realmente sobresale es en el nivel de la base de datos. Esto pasa a ser la debilidad de nuestros competidores. Permíteme mostrarte una de las formas en que Precise podría ayudarte a pasar por esto. No voy a pasar tiempo en el triángulo de la optimización de la base de datos, pero básicamente estamos buscando cambios de tipo de bajo costo, bajo riesgo, amplio alcance, alto riesgo y alto costo. De hecho, tuitearé esta diapositiva después si la gente quiere probar y echarle un vistazo. Es una guía bastante grande, creo, para problemas de ajuste. Aquí está la vista experta de Precise for Oracle. Arriba en el informe de hallazgos, el impacto del 60 por ciento es esta declaración SQL particular. Si abre esta pantalla de actividad, la muestra allí. Puedo ver esta declaración de selección, hay un plan de ejecución. Cada ejecución lleva un segundo: 48, 000 ejecuciones. Eso suma 48, 000 horas más de ejecuciones.
El azul oscuro, una vez más, es CPU. Esto está vinculado a la CPU, no es un estado de espera, no es un registro. Destaco que debido a que algunos de nuestros competidores solo miran los estados de espera y los eventos de registro, pero en términos generales, la CPU es el estado de ejecución más ocupado y ofrece la mayor recompra. Al entrar en esta visión experta, y voy muy rápido, lo que hice fue mirar la mesa, 100, 000 filas, 37, 000 bloques. Estamos haciendo una tabla completa, pero tenemos seis índices sobre esto. ¿Que está pasando aqui? Bueno, cuando miro la cláusula where, lo que está haciendo esta cláusula where es en realidad convertir una columna a mayúscula y dice dónde es igual a mayúscula, encontrar variable. Lo que sucede es que cada vez que se ejecuta esto, Oracle tiene que convertir esta columna a mayúsculas. En lugar de hacerlo casi cincuenta mil veces, es mucho más eficiente construir ese índice en mayúsculas de un índice basado en funciones y está disponible no solo en la división empresarial de Oracle, sino también en la división estándar. Cuando haces eso, lo que puedes hacer es verificar el plan de ejecución que emite esa nueva perm de usuario de índice en mayúscula, eso fue algo mío.
Luego, a partir de una medición de antes y después, está viendo un tiempo de ejecución de un segundo, agrega hasta 9 horas y 54 minutos, con esa misma declaración SQL exacta, pero con ese índice incorporado en mayúsculas para 58, 000 ejecuciones, la respuesta el tiempo cae a submilisegundos, se suman, llega a siete segundos. Básicamente ahorré diez horas de CPU en mi servidor. Esto es enorme Porque si no me corresponde una actualización del servidor, puedo vivir en ese servidor. De hecho, reduzco el uso de ese servidor en un 20 por ciento y puedes ver el antes y el después. Ese es el tipo de visibilidad que Precise puede proporcionar. También hay algunas cosas adicionales que podríamos considerar, ¿por qué tiene todos estos índices si no se utilizan? Pueden seguir con eso. Hay arquitectura, y la terminaré, ya que estamos llegando a la cima de la hora. Soy un verdadero creyente en esta solución y queremos que seas un verdadero creyente. En IDERA creemos que una versión de prueba lo convierte en un cliente, por lo que si está interesado, podemos hacer evaluaciones en su sitio.
Con eso, le devolveré el faro.
Eric Kavanagh: Sí, este ha sido un detalle tremendo que mostraste allí. Es realmente bastante fascinante. Creo que te he mencionado en el pasado que, y sé que en algunos de los otros webcasts que hemos hecho con IDERA, he mencionado que, en realidad, he estado rastreando Precise desde antes de que IDERA lo adquiriera, Creo que todo el camino hasta 2008, o 2009. Estaba fascinado por eso en aquel entonces. Tengo curiosidad por saber cuánto trabajo se necesita para estar al tanto de los nuevos lanzamientos de aplicaciones. Mencionó que SAP HANA, que creo que fue bastante impresionante, que realmente puede profundizar en la arquitectura de HANA y resolver algunos problemas allí. ¿Cuántas personas tienes? ¿Cuánto esfuerzo es de tu parte y cuánto de eso se puede hacer de manera dinámica, lo que significa que cuando la herramienta se implementa, comienzas a gatear y ver cosas diferentes? ¿Cuánto de eso puede ser determinado dinámicamente por la herramienta, de modo que pueda ayudar a las personas a solucionar problemas en entornos complejos?
Bill Ellis: Hiciste muchas preguntas allí.
Eric Kavanagh: Lo sé, lo siento.
Bill Ellis: Proporcioné muchos detalles porque para estas aplicaciones, al mirar el código, el diablo está en los detalles. Tienes que tener ese nivel de detalle para poder realmente tener algo que sea procesable. Sin métricas accionables, solo conoce los síntomas. En realidad no estás resolviendo problemas. IDERA se trata de resolver problemas. Mantenerse al tanto de los nuevos lanzamientos y demás es un gran desafío. La cuestión de qué se necesita para hacer eso, es realmente para la gestión de productos. No tengo mucha visibilidad en el equipo que básicamente nos mantiene al día sobre las cosas. En términos de HANA, esa es en realidad una nueva adición a la línea de productos IDERA; es muy emocionante. Una de las cosas con HANA es: déjame hablar sobre la tarea por un segundo. En la tarea, las tiendas de SAP harían si replicaran la base de datos con fines informativos. Entonces tendrías que hacer que las personas se reconcilien con lo que es realmente actual. Tendría estas bases de datos diferentes y estarían fuera de sincronización por diferentes niveles. Solo hay mucho tiempo y esfuerzo, además del hardware, el software y las personas para mantener todo eso.
La idea de HANA de tener una base de datos en memoria altamente paralela, para evitar básicamente la necesidad de duplicar bases de datos. Tenemos una base de datos, una fuente de verdad, siempre está actualizada, de esa manera evitas la necesidad de hacer toda esa reconciliación. La importancia del rendimiento de la base de datos de HANA aumenta: voy a decir 10 veces o al menos más valioso que la suma de todas esas otras bases de datos, hardware y recursos que pueden comprar. Ser capaz de administrar HANA, ahora ese componente está actualmente en prueba beta en este momento, es algo que pronto se convertirá en GA. Entonces, eso es bastante emocionante para IDERA y para nosotros básicamente apoyar la plataforma SAP. No estoy seguro de qué otras partes de tu pregunta he cambiado un poco, pero …
Eric Kavanagh: No, eso es todo lo bueno allí. Les tiré un montón a la vez, lo siento mucho por eso. Estoy fascinado, realmente, quiero decir, esta no es una aplicación muy simple, ¿verdad? Estás profundizando en estas herramientas y entendiendo cómo interactúan entre sí y hasta tu punto, tienes que armar la historia en tu cabeza. Debe combinar fragmentos de información para comprender lo que realmente está sucediendo y lo que le está causando el problema, para que pueda entrar y resolver esos problemas.
Un asistente pregunta, ¿qué tan difícil es implementar Precise? Otra persona preguntó, ¿quiénes son las personas, obviamente los DBA, pero cuáles son otros roles en la organización que usarían estas herramientas?
Bill Ellis: Preciso es un poco más complicado de implementar. Debe tener algún conocimiento del entorno de la aplicación, en términos de, ya sabes, esta aplicación se ejecuta en esta base de datos, necesita o - los servidores web de nivel medio, etc. Creo que dada la complejidad de algunas de estas aplicaciones, En realidad es relativamente fácil. Si puedo instrumentar el servidor web hasta su base de datos, puedo hacerlo de principio a fin. Se da cuenta de que no dije nada sobre la instrumentación de un cliente de usuario final y eso es porque lo que hacemos es que lo incluimos dinámicamente, por lo que no tiene que cambiar su código ni nada más. Un JavaScript entra en el marco de la página de la aplicación. No importa en qué parte del mundo se encuentre el usuario, cuando accede a la URL desde su aplicación y baja esa página, viene equipada con Precise. Eso nos permite elegir la ID de usuario, su dirección IP, también el tiempo de representación del primer byte de cada uno de los tiempos de ejecución del script de los componentes de la página dentro del navegador del usuario final.
En términos de las transacciones, no tiene que asignar las transacciones porque están estrechamente vinculadas. Esta URL se convierte en un punto de entrada a JVM y luego invoca este mensaje, lo que resulta en una JVC capturada de la base de datos. Básicamente, podemos capturar esos puntos de conexión naturales y luego presentarlos en la pantalla de transacciones que le mostré donde también calculamos cuánto tiempo, o el porcentaje de tiempo que se dedicó a cada paso individual. Todo eso se hace automáticamente. En términos generales, asignamos 90 minutos para hacerlo, básicamente para instalar el núcleo Precise y luego comenzamos a implementar la aplicación. Dependiendo del conocimiento de la aplicación, puede tomarnos algunas sesiones adicionales para instrumentar toda la aplicación. Muchas personas usan solo el componente de base de datos de Precise. Esta bien. Básicamente, puede dividir esto, dividirlo en los componentes que cree que su sitio necesita. Definitivamente creemos que el contexto de tener toda la pila de aplicaciones instrumentada para que pueda ver que la dependencia de nivel a nivel realmente aumenta el valor de monitorear un nivel individual. Si alguien quiere explorar la posibilidad de instrumentar aún más su pila de aplicaciones, vaya a nuestro sitio web; creo que esa es la forma más fácil de solicitar información adicional, y lo discutiremos un poco más.
Eric Kavanagh: Déjame lanzarte una o dos preguntas rápidas. Supongo que con el tiempo está recopilando y creando un repositorio, tanto para clientes individuales como como entidad corporativa en general, de interacciones entre diversas aplicaciones y diversas bases de datos. En otras palabras, el modelado de escenarios, supongo, es a lo que me estoy refiriendo. ¿Es ese el caso? ¿Realmente mantiene una especie de depósito de escenarios comunes para que pueda hacer sugerencias a los usuarios finales cuando ciertas cosas entran en juego? Al igual que esta versión de E-Business Suite, esta versión de esta base de datos, etc., ¿hace mucho de eso?
Bill Ellis: Bueno, ese tipo de información está integrada en el informe de hallazgos. El informe de hallazgos dice cuáles son los cuellos de botella de rendimiento y se basa en el tiempo de ejecución. Parte de ese informe de hallazgos es aprender más y qué hacer a continuación. La información o la experiencia de los clientes, etc., se incorpora básicamente a esa biblioteca de recomendaciones.
Eric Kavanagh: Bueno, eso suena bien. Bueno amigos, presentación fantástica hoy. Bill, me encantó la cantidad de detalles que tenías allí. Simplemente pensé que esta era una información realmente fantástica, arenosa y granular, que mostraba cómo se hace todo esto. En cierto punto es casi como magia negra, pero en realidad no lo es. Es una tecnología muy específica que ustedes reunieron para comprender entornos muy, muy complejos y hacer felices a las personas porque a nadie le gusta cuando las aplicaciones se ejecutan lentamente.
Bueno amigos, archivaremos este webcast. Puede conectarse en línea a Techopedia o insideanalysis.com y wow, gracias por su tiempo, nos pondremos en contacto con usted la próxima vez. Cuidate, chau chau.
