Diferencias entre APM y NPM

El objetivo de este artículo es explicar las diferencias entre los conceptos de APM y NPM. Para plasmarlas se confrontaran las similitudes y divergencias en puntos clave. NPM significa “Network Performance Monitoring” o Monitorización del Rendimiento de la Red.  APM significa “Application Performance Monitoring” o Monitorización del Rendimiento de las Aplicaciones. Orientación/objetivos

• Puntos en común: En ambos casos, el objetivo es detectar incidencias en IT que puedan llegar a afectar la experiencia del usuario final y disponer de información necesaria para facilitar su resolución. Adicionalmente, también se recoge información que resulta útil para planificar mejoras en la infraestructura IT.
• Puntos de divergencia: El foco de NPM es “controlar” el rendimiento de la red y detectar posibles incidencias tanto a nivel LAN como WAN. La orientación es más a nivel de enlaces o grupos de usuarios. El foco de APM está en “controlar” el rendimiento de las aplicaciones desde el punto de vista de los servidores y del usuario final. La orientación es más a nivel de usuario o incluso a nivel de transacción

Métodos/puntos de captura

• Puntos en común: En ambos casos se almacena un gran número de datos e información que permiten tener histórico que incluye la captura de tráfico en tiempo real.
• Puntos de divergencia: NPM puede recibir pasivamente información de elementos de red a través de protocolos como NetFlow o IPFIX o bien realizar consultas a través de protocolos tipo SNMP. APM extrae información a través de agentes en los servidores involucrados en el suministro de la aplicación y también de los dispositivos que realizan las consultas (PC o navegador).

Alcance de la información obtenida

• Puntos en común: En ambos casos, se espera obtener información que pueda permitir emitir un veredicto sobre la experiencia del usuario final en el uso de una aplicación. Por tanto, se tiene que poder distinguir y categorizar aplicaciones a la vez que se obtienen métricas relevantes al respecto.
• Puntos de divergencia: NPM centra la información proporcionada en estadísticas de red tales como retransmisiones, pérdidas de paquetes o tiempos de respuesta. APM se centra en datos como recogidos en servidores o PC como por ejemplo tiempos de carga, componentes software ejecutados o recursos consumidos.

Usos de la información obtenida:

• Puntos en común: En ambos casos se obtiene una alerta en cuanto hay una degradación de la experiencia de usuario. Adicionalmente, se proporcionan información y herramientas para realizar un rápido diagnóstico del foco del problema.
• Puntos de divergencia: NPM permite obtener información detallada de usos indebidos de la red o detección de congestiones. Adicionalmente permite realizar acciones de “capacity planning” a nivel de infraestructuras IT. APM centra la obtención de información en la “performance” de las aplicaciones dentro de los servidores y de los dispositivos de los usuarios. La información obtenida permite realizar mejoras a nivel de aplicación, como por ejemplo cambios en código o formato de consultas en base de datos.

Automatización de Pruebas con Selenium

Selenium es un framework Open Source que permite realizar pruebas sobre aplicaciones Web. Se trata de una herramienta especialmente útil para todos los desarrollos basados en Web porque permite automatizar procesos de testing y repetirlos de manera iterativa, lo que nos lleva a un ahorro de tiempo y esfuerzo muy importante en un proceso de desarrollo y mantenimiento de cualquier aplicación.

Vamos a ver dos elementos claves del ecosistema Selenium:

Selenium IDE

Se trata de un entorno para la grabación guiada de test basada en Mozilla Firefox, se instala como un plugin sobre nuestro navegador y permite la grabación guiada de test mediante clicks en la página web a testear.

También permite la reproducción de las pruebas de manera individual o conjunta y da la posibilidad de configurar una planificación ordenada para realizar las mismas.

El lenguaje en el que las pruebas quedan registradas en Selanese, un lenguaje propio de Selenium con el objetivo de facilitar la creación de scripts, interpretando los elementos existentes en una navegación Web y dotando de múltiples posibilidades en la personalización de las acciones, con un funcionamiento muy usable e intuitivo.

Esta es la apariencia que tiene el plugin:

Plugin

Una de las limitaciones más significativas es que solamente podemos utilizarlo en Firefox, por lo que si necesitamos realizar pruebas contra otros navegadores no es una opción válida.

Selenium Web Driver

Es la implementación clave de Selenium y permite enviar comandos al navegador mediante un controlador especifico a cada una de las instancias que nos interese, lo que se traduce en que podemos realizar nuestras pruebas a distintos navegadores, bastará con tenerlos instalados en nuestro entorno de trabajo donde se ejecuten las pruebas y tener el controlador correcto que podemos descargar de la página de Selenium.

Soporta Selanese y un número elevado de los lenguajes más populares  (Java, Ruby, Pythin, C#). Su API nos provee de todas las acciones necesarias para emular todas aquellas navegaciones de usuario que necesitemos crear.

El proceso más óptimo para crear estas pruebas para Java, por ejemplo, pasa por grabarlas con Selenium IDE, por su comodidad y rapidez, exportar la prueba como Java / Junit / WebDriver e importarla en un proyecto que tenga las siguientes librerías incluidas:

Proyecto para Java

Una vez hecho esto, podremos ejecutar nuestra prueba como un test unitario con el framework JUnit y evaluar sus resultados, cosa muy útil si queremos realizar múltiples casos de pruebas para nuestra aplicación que ejecutaremos de manera recurrente.

Veamos un ejemplo de código:

Código del test

Dónde en el momento de la instalación del driver (new FireFoxDriver) podríamos variarlo y realizar la prueba sobre cualquier navegador que necesitemos, siempre y cuando tengamos el driver accesible y cargado en nuestro proyecto.

Monitorización avanzada de sistemas en aplicaciones web multicapa

En el actual entorno de aplicaciones web multicapa con balanceadores, frontales web, servidores de aplicaciones y servidores de bases de datos, la monitorización tradicional de sistemas –para entendernos– limitada a monitorizar el uso de CPU, memoria y espacio en disco disponible, queda obsoleta.

En estos entornos se producen frecuentemente problemas de rendimiento que serán muy complicados de analizar si utilizamos únicamente la monitorización tradicional.

La monitorización de estos entornos presenta un desafío porque constan de determinados elementos que no deben quedar fuera del alcance de la monitorización como pueden ser los siguientes:

Servidores de aplicaciones

• Servidores de aplicaciones (con sus instancias de java o JVMs): Dentro de estos servicios se ejecutan máquinas virtuales de JAVA o .NET que poseen porciones de memoria asignadas y gestionadas por las propias instancias. El uso que se realiza dentro de los servidores de aplicaciones (Tomcat, Websphere, Jboss) de estas porciones de memoria queda oculta a las métricas proporcionadas por el sistema operativo y por ello es necesario utilizar herramientas adicionales para obtener los parámetros clave de rendimiento. Estos parámetros clave son:

1. Tiempo en Garbage Collection: Es valor nos permite obtener el % del tiempo de ejecución que se está gastando en limpieza de los objetos que están presentes en la pila (Heap Space) pero ya no están referenciados y por lo tanto pueden ser eliminados. Si se llena el Heap Space y el proceso recolector de basura no es capaz de liberar memoria estará pasando continuamente dejando la JVM de atender las transacciones de los usuarios. Más info en: http://en.wikipedia.org/wiki/Java_virtual_machine#Generational_heap
2. % Libre de Heap Space: Porcentaje libre de pila para el almacenaje de los objetos generados mediante la ejecución del código de la aplicación.
3. Heap Consumption: Medido en MBytes por segundo nos indica el nivel de actividad (lecturas/escrituras) en la Heap Space. Valores muy elevados en relación a la actividad realizada por las aplicaciones (nivel de usuarios y operaciones realizadas) nos indicaran ineficiencia en el uso de dicho espacio de memoria.

• Servidores de bases de datos: Estos sistemas sufren de forma muy intensa la actividad de los usuarios de aplicaciones transaccionales. Además de la monitorización clásica de sistemas (CPU/Memoria/Disco) es muy importante no olvidarse de monitorizar otros parámetros críticos:
  1. Delays en los accesos a disco: Los delays en los accesos a disco deben ser muy bajos para garantizar tiempos de bloqueo en los accesos a datos mínimos que eviten que ciertas peticiones sean retardadas de forma importante. Por ejemplo, los sistemas basados en Oracle están pensados para funcionar de forma óptima con delays de escritura a disco inferiores a 10 ms.
  2. Parámetros relevantes de BBDD: Aunque en otro post analizaremos en detalle los parámetros más relevantes en cuanto a la monitorización de métricas de estos sistemas, podemos avanzar que tener en cuenta parámetros como Buffer Cache Hit Ratio (que indica el porcentaje de peticiones que son resultas mediante accesos a páginas que están en memoria) o el Average Lock Wait Time (que nos indica el promedio de tiempo que las peticiones tienen que esperar para ser ejecutadas) son críticos para asegurar un óptimo rendimiento del servicio. Más información en https://thwack.solarwinds.com/docs/DOC-167343

• Cabinas de discos: Con el uso intensivo de la virtualización el nivel de actividad que sufren estos sistemas es muy elevado. Además el hecho de que diversos sistemas diferentes estén a menudo accediendo sobre el mismo conjunto de discos puede crear penalizaciones cruzadas en los accesos muy difíciles de detectar. En este caso problemas en una aplicación pueden provocar problemas de rendimiento en otra aplicación que no tienen nada que ver con el diseño de la misma ni los servidores sobre los que está funcionando. Por ello es muy relevante monitorizar tanto el nivel de IOPS (número de operaciones de acceso a discos por segundo) total que le estamos pidiendo a la cabina en cada intervalo determinado como el número individual de IOPS generado por cada sistema para en el caso de que alguno de ellos este generando de forma prolongada un número muy elevado de accesos investigar cual es la causa.

Creemos que tener en cuenta estos puntos a la hora de definir como debe ser la monitorización de los sistemas en arquitecturas web multicapa es crucial para garantizar el correcto funcionamiento de los mismos.

Mobile Application Status Monitor

Mobile Application Status Monitor, MASM, es un servicio de monitorización de aplicaciones para dispositivos móviles que permite recrear la experiencia del usuario con el fin de obtener métricas en tiempo real.

Es decir, este servicio monitorizará la aplicación de su negocio y le alertará si ésta no estuviera disponible para sus usuarios, pues el control de la user experience con su marca debe ser lo más importante.

Para mostrar la capacidad de la herramienta MASM este es el vídeo que se presentó en el Mobile World Congress 2015.

Frame de la presentación en el MWC 2015.

Testing de aplicaciones móviles: principales herramientas

Mientras que el testing de aplicaciones de escritorio desde la interfaz del usuario es bien conocido, con una gran cantidad de herramientas disponibles, el entorno móvil es diferente. Debido a la fragmentación de la plataforma y a las restricciones impuestas en los dispositivos iOS, el testing de aplicaciones móviles es algo más difícil de solventar. Con el tiempo se han desarrollado varias herramientas y en este post se mencionan las más populares. Podrían clasificarse de la siguiente forma:

1.  Herramientas específicas de la plataforma. – Normalmente las proporciona el propio proveedor del Sistema Operativo. Estas herramientas son capaces de testear la aplicación tanto en un dispositivo móvil como en el emulador. Las más conocidas son:

Instruments* – Instruments es un aplicación de Mac que forma parte de Xcode (IDE de desarrollo de aplicaciones iOS). A partir de Xcode4 se incluye una herramienta llamada “Automation” que permite testear aplicaciones desde la interfaz gráfica del usuario. Los scripts que simulan la interacción del usuario están escritos en JavaScript y Apple proporciona un conjunto de librerías.

Monkeyrunner** – Con Monkeyrunner se puede escribir un script en Python que controle tanto emuladores como terminales móviles Android.

2.  Herramientas de Scripting genéricas. – Estas herramientas son desarrolladas por terceros y suelen realizar el testing mediante scripts. Algunas de las más populares son:

Sikuli***– Sikuli utiliza procesado de imagen para testear gráficamente interfaces gráficas de usuario. Esta herramienta puede automatizar cualquier cosa que se vea en la pantalla mediante comparación de imágenes.

Robot Framework**** – Robot Framework es una librería de testing de aplicaciones Android que utiliza ‘Calabash Android’ para comunicarse con la aplicación. Esta herramienta tiene una sintaxis de tabulaciones que utiliza un enfoque de testing basado en palabras clave.
3.  Generadores de eventos aleatorios. – Existen herramientas que testean la estabilidad de las aplicaciones enviándoles eventos aleatorios.

Monkey***** – Monkey (que no es lo mismo que Monkeyrunner) puede ejecutarse tanto en emuladores como en terminales Android y generar secuencias pseudo-aleatorias de eventos de usuario como clic y ‘drag-and-drop’.

Automation – La herramienta Automation de iOS no tiene ningún generador de eventos aleatorios por defecto, pero estos pueden desarrollarse fácilmente creando módulos personalizados con JavaScript con la capacidad de toques, movimientos con los dedos, etc.
4.  Herramientas de testing whitebox. – Estas herramientas pueden examinar la estructura interna de la aplicación. Para este tipo de testing es necesario tener acceso al código de la aplicación, o al menos poder lincar la librería de teing a la aplicación para poder compilar.

Android Instrumentation – Este framework está basado en JUnit y permite testear clases/métodos que no usan APIs específicas de Android. Para testear clases/métodos específicos de Android se usan extensiones de JUnit.

Instruments – La herramienta Instruments forma parte del IDE de desarrollo de aplicaciones iOS y permite testing whitebox de aplicaciones iOS.
Frank y TestStudio también son herramientas de testing whitebox para aplicaciones iOS.

5.  Herramientas de testing Blackbox – Las herramientas de testing Blackbox comprueban la funcionalidad de la aplicación y no cómo se consigue esa funcionalidad. Estas herramientas no requieren tener acceso al código de la aplicación ni saber cómo funciona internamente.

Sikuli – Debido a la tecnología visual en la que se basa, no requiere de ningún tipo de conocimiento del código de la aplicación.

Robotium****** – Robotium es un framework que permite a los desarroladores crear tests blackbox así como whitebox para aplicaciones Android.

* http://bit.ly/fZDCKT

** http://developer.android.com/tools/help/monkeyrunner_concepts.html

*** http://www.sikuli.org/

**** http://code.google.com/p/robotframework/

***** http://developer.android.com/tools/help/monkey.html

****** http://code.google.com/p/robotium/

La necesidad de la monitorización de experiencia de usuario

Vivimos en un momento donde la tecnología se ha extendido a la mayoría de la población. El uso de internet se ha vuelto cotidiano, no solo para consultar información (como hasta hace unos años) sino para realizar todo tipo de acciones que hasta hace poco eran impensables, tanto por la facilidad del acceso a internet des del hogar así como con la popularización de los Smartphones y las tarifas planas de acceso a internet.

Ya no vamos a nuestra oficina bancaria a realizar una transferencia, simplemente accedemos al servició de banca electrónica de nuestro banco donde podremos realizar la mayoría de los trámites habituales.

Todo esto ha conseguido abrir un gran mercado de servicios on-line, des de la banca electrónica al E-commerce, y ha obligado a cambiar el modelo de negocio de muchas empresas, donde estas ya tienen en la venta on-line una gran fuente de ingresos.

Para poder ofrecer estos servicios on-line se requiere de una infraestructura cada vez más compleja (frontales web, bases de datos, pasarelas de pago, etc.). Con la monitorización tradicional conocemos el estado de nuestros equipos, pero: ¿podemos afirmar que aun sin detectar problemas en nuestra infraestructura estamos ofreciendo un buen servicio a nuestros usuarios?

Con esta simple pregunta nace la necesidad de monitorizar des del punto vista de un usuario, además de la monitorización tradicional. Existen dos vías distintas para realizar la monitorización de experiencia de usuario. En este artículo nos centraremos en la monitorización web:

• Monitorización de experiencia de usuario con transacción sintética
  • Esta solución se basa en la creación de usuarios ficticios que realizan siempre las mismas acciones de forma periódica, recogiendo métricas  de disponibilidad, tiempo, etc.  En el entorno web se utilizan aplicaciones que automaticen el navegador, y realice las acciones configuradas en un script tal como lo haría un usuario: rellenar formularios, acciones sobre la web, validación de contenido, etc.  Un robot será el encargado de ejecutar periódicamente estos scripts. Permite detectar fallos de rendimiento o caídas, notificando a los responsables y reduciendo el tiempo de reacción. Con la transacción sintética siempre tendremos un entorno de monitorización controlado y con condiciones repetibles.

• Monitorización de usuarios reales (RUM)
  • Esta solución se basa en analizar los datos de todos los usuarios  que acceden a nuestro servicio. Estos nos permiten tener una visión global de todas las transacciones realizadas. Al tener una ventana de muestras más diversa, podremos procesar los datos obtenidos según diversos parámetros (Sistema Operativo, Localización, navegador,…).  Al igual que con transacción sintética, nos permitirá detectar en tiempo real fallos de rendimiento, indisponibilidades. Al tener un mayor número de muestras podremos identificar si los problemas son solo para una determinada localización, un determinado navegador, etc. Este tipo de monitorización se puede realizar de dos formas distintas, o bien se inserta un javascript en nuestra aplicación web (como google analytics) o bien poniendo productos específicos que capturaran (de forma transparente y no intrusiva) el tráfico dirigido a nuestra aplicación web.

Criterios para la evaluación de soluciones de Application Performance Monitoring

Vamos a introducir algunos conceptos en cuanto a los criterios más interesantes que podemos pedir a las soluciones de Application Performance Monitoring. Una fuente para estos criterios puede ser los que utiliza Gartner para la evaluación de estas soluciones. Los criterios que os presentamos son un poco más concretos. A grandes rasgos, nos gustaría:

Monitorización de la experiencia del usuario.

• Una monitorización continua de la experiencia de usuario
• La medida de la experiencia web a nivel de página, no sólo objetos. Incluyendo la complejidad de las peticiones AJAX.
• El establecimientos de baseline y la generación de alertas para usuarios con bajo rendimiento
• Una visión completa sobre geografía, plataforma y tendencias
• La distribución de la latencia de los distintos componentes (red, servidor, etc)
• La monitorización la disponibilidad de las aplicaciones incluso cuando no hay usuarios, usando transacciones sintéticas
• Visibilidad de la experiencia de usuario para casos especiales

Seguimiento de transacciones y monitorización de los componentes de la aplicación.

• Poder seguir a la aplicación por todas las capas: frontales, servidores de aplicaciones, bases de datos
• Grabar e indexar todas las transacciones, no sólo muestras. Además, debemos poder encontrar lo que buscamos
• Monitorizar los datos de rendimiento de manera fina, asegurando que no se pierden las anomalías. Las medias generalmente sólo sirven para el capacity planning
• Soportar múltiples entornos, como java, .Net, paquetes comerciales y aplicaciones a medida
• Monitorizar métricas de aplicación y de sistema
• Bajo overhead
• Configuración simple/automática y no intrusiva. Las soluciones que requieren la modificación del código no son bienvenidas
• Facilidad para encontrar las transacciones con problemas

Mapas de transacciones

• Generar mapas de dependencia de la aplicación en tiempo real
• Generar mapas para entornos dinámicos (SOA, máquinas virtuales)
• Aprovechar los datos obtenidos de fuentes existentes
• Capacidad para trabajar con cualquier tipo de aplicación

Analítica

• Detectar y correlar anomalías
• Capturar e indexar todas las transacciones de los usuarios
• Capacidad para la analítica con un gran volumen de información forénsica y de rendimiento
• Utiliza métodos sencillos para la búsqueda de información

Cuadros de mando

• Vistas personalizables para usuarios distintos
• Vista de alto nivel que permiten una primera diagnosis
• Facilita la exploración de información de forma sencilla (drill down)

Cuadro de Mando

Ejemplo de cuadro de mando

Causas retransmisiones TCP

El objetivo de este post es analizar las posibles causas que pueden provocar las retransmisiones TCP.  Este es de un protocolo de la capa de transporte que proporciona un flujo de datos seguro, ordenado y libre de errores. El emisor envía los datos fragmentados, encapsulados y numerados al receptor que verifica su integridad y devuelve un acknowledge (ACK) indicando el paquete recibido. El emisor no considerará que el receptor ha recibido la información hasta que no reciba el ACK. Si tras un tiempo proporcional al delay el receptor no recibe respuesta reenviará el paquete. Estos paquetes retransmitidos están marcados, es por ese motivo que la mayoría de elementos de red son capaces de detectar las retransmisiones.

A partir de este punto, estas son los posibles casos de retransmisión de paquetes:

Paquete perdido: Consideramos que se podría haber perdido tanto el paquete de información original como el ACK. Causas más habituales:

• Descartado por el camino: Hay algún elemento de red, como un Firewall, que filtra los paquetes.
• Wireless: Una bajada momentánea de cobertura ocasiona pérdida de paquetes.
• Congestión: Todos los elementos de red tienen un caudal máximo que pueden tratar y si lo superan lo almacenan en su buffer. Si esta saturación es continuada el buffer se llena y se descartan paquetes. Los cuellos de botella más habituales son los provocados por una mala negociación de interfaces (dúplex mismatch por ejemplo) o por la capacidad de los enlaces WAN.
• Error hardware: Un problema con una tarjeta de red o una interface en un elemento de red puede ocasionar pérdidas.

Paquete retrasado: Si el receptor no recibe el ACK en un tiempo proporcional al delay estimado reenviará el paquete. Causas más habituales:

• Alta latencia: Cuando los paquetes circulan por la WAN, especialmente en largas distancias, la latencia puede resultar muy elevada.
• Elemento intermedio: En ciertas infraestructuras hay elementos intermedios que por mala configuración o saturación pueden añadir delays adicionales, como por ejemplo un proxy.

Paquete corrompido: El paquete TCP tiene control de errores, y en caso de que el receptor reciba un paquete corrompido no devolverá ACK y el emisor reenviará el paquete. Posibles causas:

• Mala calidad del medio de transmisión: Los elementos con peor calidad suelen ser los entornos Wireless.
• Error hardware: Una electrónica de red averiada o defectuosa puede corromper paquetes.

Técnicas de monitorización del rendimiento de las aplicaciones

Entendemos como monitorización del rendimiento de las aplicaciones aquellas técnicas mediante las cuales se pueden detectar desviaciones en los tiempos de respuesta y/o un malfuncionamiento de las mismas de forma proactiva, generando las oportunas alertas cuando corresponda.

Existen 4 grandes técnicas de monitorización:

• Transacciones sintéticas: Mediante esta técnica se generan peticiones utilizando las mismas herramientas (por ejemplo: un navegador o una aplicación cliente) que utiliza el usuario para acceder a la aplicación y se miden los tiempos de respuesta de las diversas operaciones que puede hacer un usuario comparándolos con una línea base. Es importante no confundir las transacciones sintéticas con las sondas pues estas últimas no utilizan la misma aplicación utilizada por el usuario.
• Monitorización de la red: Mediante captura de tráfico se analiza el comportamiento de la aplicación a partir de los resultados obtenidos a partir del análisis del mismo (tiempo de respuesta del servidor, retardo causado por la red, etc). Para utilizar esta técnica es necesaria que los equipos que procesan este tráfico posean una gran inteligencia pues deben recomponer las transacciones de la aplicación a partir de la captura de paquetes a nivel de red.
• Monitorización desde la estación de trabajo del usuario (experiencia final del usuario): Esta técnica se basa en la captura del rendimiento de la aplicación des de la misma estación de trabajo del usuario obteniendo de esta forma el rendimiento de la aplicación para transacciones reales de usuario. En el caso de aplicaciones web se utiliza la inserción de código JavaScript para obtener estas mediciones en el equipo final del usuario ya que al ejecutarse dicho código en el navegador del usuario se podrán obtener medidas reales de la experiencia final del mismo (por ejemplo Google Analytics utiliza este sistema para obtener los resultados de rendimiento).
• Instrumentación de servidores: En este caso se utilizan agentes en los servidores (web, aplicaciones, bases de datos) para obtener medidas del rendimiento de la aplicación a partir del seguimiento de la ejecución del código dentro de estos servidores. Esta técnica es muy útil para obtener los puntos de la aplicación que presentan problemas de rendimiento y suministrar información útil a los desarrolladores para solucionar dichos problemas.

En futuros posts analizaremos las soluciones de algunos fabricantes (por ejemplo OPNET) al respecto de la monitorización de aplicaciones.

Extraer datos de rendimiento en páginas Web

Es posible, y en ocasiones altamente interesante, obtener información en forma de tiempo de todos los procesos que realizar una página web mientras se carga desde el lado del cliente, es decir, en el navegador, sin necesidad de acudir a complejos códigos que se ejecuten en el servidor.

En el pasado, los desarrolladores web accedían a estas métricas de carga de la página del lado del cliente mediante el uso de JavaScript Date. Un simple código como este : var  inicio = Date.now(); al inicio de la carga nos almacena una variable con el tiempo en que empieza el proceso y en el momento de finalizar la carga, con simple resta como esta : var tiempoCarga = Date.now()-inicio obtendríamos el tiempo total que se ha empleado en realizar la carga.

Este funcionamiento es limitado y poco fiable por algunas razones evidentes:

• El código de medida de tiempo se encuentra en la página, por lo que afecta a la forma en que la página se carga y modifica su comportamiento natural.  (Navigation Timing Api puede ser utilizado para obtener los tiempos
• Este javascript se trata de una aproximación, y dista mucho de ser preciso
• El objeto Date de JavaScript no se puede usar para medir la latencia de la red antes del comienzo de la carga.

Para solucionar todo este vacío que existía en este apartado es donde Navigation Timing entra en escena.

Navigation Timing es una Api Javascript que provee de los métodos necesarios para medir el funcionamiento de la web de forma precisa y sencilla y conseguir las estadísticas de la navegación y tiempos de carga.

Esta Api puede ser utilizada después de que la página haya terminado la carga, por lo que no afecta al proceso y no incrementa  de forma artificial sus tiempos, solucionando así uno de los puntos más críticos  mencionados anteriormente en el uso del objeto Date de JavasCript para la medición de tiempos.

Esta Api es accesible mediante las propiedades del objeto window.performance en dos variantes:

• Navigation : como navega a la página el usuario
• Timing: datos de la navegación y eventos de carga de la pagina

Los atributos accesibles a través de estos objetos quedan ilustrados en el siguiente diagrama extraído de la página: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html

Timing

Esta Api está disponible en muchos de los navegadores más utilizados habitualmente, pero no está soportada en todos. En la siguiente tabla se resume la disponibilidad asociada a la versión de navegador:

Navegador	Versión
Internet Explorer	9.0 +
Firefox	7.0 +
Chrome	6.0 +
Safari	No soportado
Opera	15.0 +
IOS Safari	No soportado
Opera mini	No soportado
Android browser	4.0 +
Black Berry browser	10.0 +
Opera mobile	14.0 +
Chrome android	29.0 +
Internet Explorer mobile	10.0 +
Firefox android	23.0 +

Actualmente, y mediante el uso de la Api Navigation timing, la herramienta ISM de experiencia web de usuario de NexTret implementa la recogida de nuevas métricas que complementan los datos que ya ofrecíamos a nuestros usuarios, dando así un valor añadido y una información extra, del comportamiento de una web, que resulta ser de gran utilidad y  muy valorada por nuestros clientes.