Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. General

Atención desarrolladores: New Relic es tu arma secreta

by
Length:LongLanguages:

Spanish (Español) translation by Steven (you can also view the original English article)

Si bien el título de este artículo puede parecer un cliché, nacido en las entrañas del infierno de las relaciones públicas, lo digo en serio cuando digo que New Relic es tu arma secreta.

En este artículo, hablaré sobre los aspectos comunes del rendimiento de las aplicaciones web y luego demostraré cómo New Relic hace que sea increíblemente fácil de administrar.

En los casi seis años que he trabajado en Envato, anteriormente desarrollando y administrando la serie de mercados y actualmente administrando el desarrollo de la red de blogs Tuts+, he usado New Relic para mantener bajos los costos, mejorar y depurar problemas de rendimiento desde pequeños hasta los grandes y evitar catástrofes potenciales.

Si eres nuevo en este tema, o no administras actualmente un sitio web para alguien de ninguna manera, no te preocupes; este artículo seguirá siendo útil. Nunca se sabe cuándo este conocimiento podría salvar tu tocino, y apuesto a que es inevitable que lo hará, a menos que, por supuesto, decidas tirar la toalla del desarrollador hipotético y convertirte en astronauta o ranchero.


New Relic en 20 segundos

Antes de lanzarme a una diatriba razonablemente larga sobre el rendimiento de las aplicaciones web, tiene sentido resumir rápidamente qué es New Relic antes de ir a Reddit o algo similar.

New Relic es un servicio administrado (SaaS) que tú "conectas" a tu aplicación web, que recopila y agrega métricas de rendimiento de tu aplicación web en vivo.

La información que proporciona puede ayudarte a encontrar respuestas a preguntas como: ¿Mi sitio web es lento? ¿Para quién es lento? ¿Dónde es exactamente lento? ¿Necesitamos más servidores o más grandes? ¿Qué podemos hacer para mejorar las cosas?

Estas preguntas y sus respuestas suelen ser cruciales para el éxito o el fracaso de tu aplicación web. Si nunca has recopilado métricas de rendimiento de tu aplicación web en vivo, literalmente estás corriendo con los ojos vendados; en algún momento vas a chocar contra una pared.

Antes de que hagas un recorrido por las funciones de New Relic, tengo que definir qué es el rendimiento de la aplicación web. Hagámoslo.


¿Qué es exactamente el rendimiento de las aplicaciones web?

El rendimiento del front-end se trata de un rendimiento "percibido".

Me gusta dividir el rendimiento de las aplicaciones web en dos partes conceptuales: rendimiento de front-end y rendimiento de back-end. Si bien las dos áreas efectivamente se cruzan y se afectan entre sí, es útil hacer una distinción.

En primer lugar, puedes pensar en el rendimiento del front-end como áreas relacionadas con el rendimiento percibido, como el tiempo que tarda una página en mostrarse por completo a un usuario final. Las variables que afectan este tipo de desempeño incluyen:

  • Qué tan grandes son tu HTML, CSS, JavaScript e imágenes.
  • Cuántas solicitudes HTTP se envían a los servidores para recuperar todos estos recursos.
  • Cómo están organizados en la página para afectar el rendimiento percibido, si el navegador de un usuario tiene que volver a descargar los recursos, independientemente de si son iguales o no.

Solo he visto aplicaciones web y sitios web "caer" como resultado de una mala gestión del back-end.

El rendimiento de back-end implica algún tipo de lenguaje de programación que ejecuta tu código (es decir, PHP, Ruby) y algún tipo de servidor de base de datos (es decir, MySQL). Generalmente, la mayoría de las aplicaciones web ensamblan documentos HTML para enviarlos al navegador de tu usuario y se componen de datos extraídos de una o más bases de datos, o incluso de uno o más servicios externos (como la API de Twitter). También suelo agrupar los recursos del servidor (como el uso de CPU, uso de memoria, E/S de disco) en esta categoría, ya que es el código que se ejecuta en tu servidor (no en el navegador de tu usuario) el que afecta estos recursos.

¿Por qué es tan importante esta distinción? Porque, en mi experiencia, he descubierto que una confusión entre los dos conduce a que se aplique un esfuerzo inútil al intentar mejorar los problemas de rendimiento. He sido testigo del trabajo en el rendimiento del front-end de sitios web con problemas cuando el problema real ha sido el backend. Por otro lado, he visto a la gente enfocarse en la optimización del back-end cuando el problema ha estado en el front-end. Es fundamental que comprendas y aprecies la diferencia.

Por sí solos, estos dos temas pueden ser bastante profundos y complicados, y es un tema para una serie de publicaciones completamente diferente. Si bien estoy decididamente especializado en el desempeño de back-end, en toda mi carrera profesional, solo he visto aplicaciones web y sitios web "caer" como resultado de una mala gestión del back-end.


Tres enfoques y medio para gestionar el rendimiento

Hay tres formas en que las personas tienden a administrar el rendimiento de sus aplicaciones web:

  1. Escribe código, impleméntalo y espera lo mejor.
  2. Escribe código, adivina qué áreas se convertirán en cuellos de botella, mide y optimízalas desde el principio, implementa y espera lo mejor.
  3. Escribe el código, mide la aplicación en vivo con algo como New Relic, luego corrígelo y ajústalo según corresponda.

El primer enfoque es 100% reaccionario. Si sigues este método, solo sabrás si tu aplicación web está fallando o funcionando mal cuando tus clientes te lo digan (si es que alguna vez te lo dicen).

El segundo enfoque es considerablemente más maduro; los desarrolladores se están adelantando a los problemas e intentando resolverlos por adelantado. Si bien esto es admirable, la posibilidad de gastar recursos vitales optimizando el área incorrecta y la falta de retroalimentación continua proporcionarán pocos datos sobre lo que realmente está sucediendo en el entorno en vivo.

El tercer enfoque es la situación casi ideal. Al monitorear una aplicación web en vivo, puedes revisar cómo se están desempeñando varias cosas, en función de lo que realmente están haciendo tus clientes. Puedes escribir código y recibir comentarios inmediatos sobre qué tan bien (o no) está funcionando.

El enfoque ideal

El enfoque ideal es seguir el tercero y aplicar una medida saludable del segundo.

No está de más considerar el desempeño desde el principio; es infinitamente más útil tener métricas verdaderas. El viejo adagio de la programación, "la optimización prematura es la raíz de todos los males" puede aplicarse aquí, aunque, en la programación, como en la vida, los axiomas rara vez son algo más que medias verdades.


Medición y gestión: Un acto de equilibrio

No existe un método verdadero para administrar el rendimiento de tu aplicación web.

No importa lo que digan (¡incluyéndome a mí!), no existe un método verdadero para administrar el rendimiento de tu aplicación web. Dependiendo de tu aplicación y clientes, habrá diferentes enfoques y técnicas. Sin embargo, una cosa permanece constante: hay que medir.

Entonces, ¿qué medir? Una vez más, no hay una lista verdadera, pero siempre habrá una cantidad común de métricas que valga la pena medir. Por ejemplo:

  • El número de solicitudes de aplicaciones a lo largo del tiempo.
  • Las solicitudes de tiempo del reloj de pared tardan en completarse.
  • El uso de CPU de tus servidores a lo largo del tiempo.
  • El disco duro lee, escribe y utiliza a lo largo del tiempo (conocido como "Disk IO").
  • El número de consultas a la base de datos y el tiempo que tardan en ejecutarse.
  • Las consultas se ejecutan en tu base de datos y tardan más de dos segundos en completarse (consultas lentas).
  • Ancho de banda entrante y saliente a lo largo del tiempo.

Esta lista, aunque ciertamente no es exhaustiva, ofrecerá información significativa sobre el comportamiento de tu aplicación web, especialmente si nunca la has monitoreado anteriormente.

Una vez que tengas este tipo de datos, la administración de tu aplicación web es donde comienza toda la diversión. Puedes encontrar que, una vez que elimines un cuello de botella en tu base de datos (tal vez algunas consultas ejecutadas lentamente), expondrás otra a medida que se liberen más recursos del servidor. Realmente es un acto de equilibrio.

En última instancia, lo que parece una gestión exitosa es algo como esto: puedes duplicar la eficiencia de ese único servidor tuyo, lo que te permite retrasar la compra de un segundo. A mayor escala, puedes reducir tu granja de servidores en un factor del 50%, y en una escala lo suficientemente grande, eso puede equivaler a una gran cantidad de dinero. En un lado más ligero, simplemente puedes brindar una buena calidad de servicio a tus clientes sin sorpresas repentinas.


New Relic: Tu arma secreta

Ahora que hemos cubierto los bits de "qué" y "cómo", echemos un vistazo a New Relic. Érase una vez en la tierra del software, donde tenías que convertir tus propias mediciones en una aplicación, si es que mediste (lo que puede ser tanto trabajo como escribir tu propia aplicación). New Relic te permite simplemente conectar tu agente a tu aplicación Ruby, PHP, .NET o Python y comenzar a recopilar datos reales de inmediato.

Cuidadosamente, tu producto se divide en tres regiones principales:

  • Monitoreo del usuario final (front-end, el navegador)
  • Monitoreo de aplicaciones (back-end, tu código)
  • Monitoreo del servidor (back-end, los servidores)

Echemos un vistazo a cada uno, en el orden en el que se publicaron históricamente.

La primera característica que lanzó New Relic fue la supervisión de aplicaciones. Realiza un seguimiento e informa sobre las 'Solicitudes por minuto' (también conocido como RPM), los tiempos de respuesta promedio de estas solicitudes y mantiene estos datos para que los analices. Esto es particularmente útil para descubrir tendencias en el tráfico a lo largo del tiempo (por ejemplo, ¿mi sitio se vuelve más lento a medida que aumentan las visitas a nuestra página?).

Además, los "seguimientos de transacciones lentas" te proporcionarán una lista de solicitudes recientes de usuarios reales que fueron desproporcionadamente lentas. Inspeccionarlos te permite profundizar y determinar por qué una solicitud tomó tanto tiempo, brindándote la información que necesitas para mejorarla.

La supervisión del usuario final te proporcionará información sobre cómo se está visualizando tu sitio en los navegadores de los usuarios. Divide el tiempo total en partes, en función de cosas como el tiempo de la red (cuánto tiempo tardaron en descargarse los recursos), la representación DOM (cuánto tiempo tu navegador tarda en descifrar tu HTML), la carga de imágenes (según la entrega de tu servidor web o un CDN) .

Una característica interesante de la supervisión del usuario final es que te muestra qué tan bien o mal está funcionando tu aplicación para los usuarios de diferentes países. Por ejemplo, quizás el 50% de tus clientes están en el Reino Unido, mientras que el otro 50% está en los EE. UU. Es posible que descubras que el rendimiento del front-end no es demasiado bueno en el Reino Unido, debido a la distancia física de tus servidores. La introducción de un CDN o un servidor en el Reino Unido mejorará la experiencia de tus usuarios.

La mejor parte de usar New Relic y tomar medidas basadas en tus datos es que, una vez que hayas realizado cualquier número de cambios, ¡puedes revisar inmediatamente si los cambios han sido efectivos o no!

La última pieza del rompecabezas, y la supervisión más reciente que ha introducido New Relic, son sus herramientas de supervisión del servidor. Siempre he comentado que debes correlacionar los recursos de tu servidor con los tiempos de respuesta de tu aplicación web para obtener una imagen más completa de la eficiencia. Puedes tener excelentes tiempos de respuesta, pero también puedes estar sacrificando innecesariamente importantes recursos del servidor para proporcionarlos.

He visto aplicaciones con excelentes puntajes de YSlow, por ejemplo, pero absolutamente ningún margen para más tráfico, ¡incluso en cantidades significativas de hardware!

¡Espero que a estas alturas empieces a ver lo valioso que es este tipo de información!


Instalación de New Relic

Necesitarás al menos estar en un VPS y tener acceso de tipo root para el agente PHP.

Una de mis únicas críticas a New Relic es que no es fácil de instalar para algunos tipos de usuarios. Si eres un programador de Ruby on Rails, lo encontrarás bastante fácil, ya que es un simple complemento de Rails.

Si eres un desarrollador PHP y no te sientes cómodo jugando con la línea de comandos, te resultará difícil de instalar, ya que es una extensión de PHP y requiere que se instale un demonio junto con tu servidor web. Sin embargo, algunas plataformas PHP en la nube, como PHPFog, ofrecen la integración de New Relic lista para usar.

Esto es lamentable en mi opinión, ya que es un obstáculo para la mayoría de las personas. Espero que New Relic esté buscando asociarse con más proveedores de alojamiento web básico, para que su producto sea más accesible para una audiencia más amplia. Literalmente, no hay una herramienta como esta en el mercado en la actualidad, y deberían facilitar el uso de todos los desarrolladores de PHP.

Si estás utilizando un alojamiento existente, deberás al menos estar en un VPS y tener acceso de tipo root para el agente PHP. Siendo completamente justo, poner en marcha un VPS de un proveedor como Linode e instalar Apache, PHP, MySQL y New Relic es un proceso corto, pero requiere cierta comodidad y conocimientos en un shell.

La mejor manera de comenzar a usar PHP y New Relic es usar una herramienta como Oracle VirtualBox, instalar Linux, configurar Apache y PHP y luego instalar el agente. Entonces podrás utilizar New Relic en tu entorno de desarrollo local, como mínimo.

Personalmente, no he tenido ninguna experiencia con el agente de Python, y he escuchado de tercera mano que el componente .NET es fácil de poner en marcha.


Cómo Envato utiliza New Relic

Envato ha estado usando New Relic desde 2008. Lo hemos usado en los siguientes productos con buenos (y a veces interesantes) resultados:

Los mercados

Al inicio, descubrimos aproximadamente tres puntos lentos importantes en lugares inesperados de los mercados. Descubrimos cuáles eran nuestras solicitudes con mayor tráfico y nos enfocamos en optimizarlas específicamente. Si dedicamos el 80% de nuestro tiempo a un solo lugar, hacerlo dos veces más rápido aumenta la capacidad y nos ahorra la asignación de más fondos al hardware. Hemos detectado tráfico inusual (como spammers y piratas informáticos) lo que nos permite tomar medidas de precaución más temprano que tarde, mejorando así la experiencia de nuestros clientes reales. Lo usamos a diario para monitorear el rendimiento de todo nuestro código nuevo y existente.

Los blogs de Tuts+

En 2009-2010, la red de blogs de Envato tuvo serios problemas de estabilidad debido a una serie de problemas de arquitectura. Mi trabajo era intervenir y resolver los problemas. Después de realizar un análisis arquitectónico y un rediseño del mismo, conectamos el monitor PHP (¡entonces beta!). ¡Descubrimos muchas, muchas cosas indeseables!

  • El 20% de las solicitudes fueron visitas a feeds (que deberían haberse almacenado en caché o enviarse a FeedBurner)
  • 3 consultas SQL tardaban habitualmente más de 5 segundos en devolver resultados.
  • Las tareas de WP-Cron de larga duración estaban agotando nuestro grupo de trabajadores web.
  • ¡Las páginas 404 tardaban más de 1 segundo en generarse!

En el transcurso de 2010-2011, solucionamos progresivamente los problemas hasta que, más o menos, se resolvieron todos. Hasta el día de hoy, seguimos monitoreando los blogs PHP usando New Relic. Y ahora, afortunadamente, la red de blogs es agradable y estable.

El rediseño de Tuts+ Premium

Cuando lanzamos el rediseño de Tuts+ Premium, usamos New Relic para depurar problemas de rendimiento antes del lanzamiento real, en los servidores reales en los que debían ejecutarse. Esto disipó cualquier temor de desastre en el lanzamiento. Continuamos monitoreando el desempeño del sitio, usando New Relic.

Hoy en día, cualquier aplicación importante en Envato tiene un agente New Relic conectado. Honestamente, nos ha ahorrado mucho tiempo y dinero, y nos ha permitido brindar calidad de servicio a nuestros usuarios y clientes.


Otras herramientas que Envato usa para aumentar New Relic

No sería justo no mencionar las otras herramientas que usamos para cuidar nuestras aplicaciones. Actualmente usamos ScoutApp para un monitoreo más detallado del servidor (admite 'complementos' aportados por el usuario para que podamos monitorear servicios específicos como HAProxy, Nginx, etc.). También usamos AirBrake, que registra y agrega nuestros errores en nuestras aplicaciones Ruby on Rails.

Por último, hemos implementado algunas de nuestras propias herramientas personalizadas y especializadas que verifican cosas como accesos de caché, solicitudes de backend, ingresos, registros y notificaciones cuando ocurre una desviación significativa de las tendencias. Por ejemplo, la interrupción o caída de los ingresos podría significar que nuestra integración de pagos esté rota; un cambio en las suscripciones significa que es posible que los spammers nos hayan atacado creando cuentas fantasma para su uso posterior.


Conclusión

Si trabajas en cualquier tipo de aplicación web que sea crítica para el negocio, o si tienes la tarea de arreglar una aplicación que no funciona del todo, New Relic será invaluable para ti.

Si tienes alguna pregunta, déjala en los comentarios y haré todo lo posible para responderla. En particular, si hay interés en un screencast sobre cómo configurar un VPS o máquina virtual con New Relic, estoy seguro de que podemos organizar uno para ti.

¡Conviértete en un superhéroe programador; usa New Relic!

Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.