Rendimiento

Recopile las expectativas de los usuarios en la fase de definición del producto, cuantifique los requisitos empresariales y utilice esta información como base para la arquitectura y el diseño posteriores del producto.

Los componentes de una solución bien diseñada pueden escalarse de forma independiente, por ejemplo, añadiendo otra instancia de un servicio, pero añadir o eliminar componentes puede tener efectos secundarios en otras partes de la solución; por ejemplo, añadir otro servidor web para atender un pico de tráfico web puede requerir más colas de mensajes para comunicarse con los servicios back-end. Conocer de antemano la escalabilidad de las dependencias puede ayudar a entender el comportamiento operativo de la solución y a evitar el agotamiento de los recursos por el sobreescalado de un solo recurso

Las soluciones de nube híbrida bien diseñadas aprovechan las arquitecturas multiplataforma para aplicar estrategias de escalabilidad y aumento repentino de la demanda con el fin de optimizar el rendimiento, la seguridad, los costes operativos y las expectativas de los usuarios finales. Por ejemplo, ejecutan cargas de trabajo en infraestructuras locales con sólidas garantías de rendimiento y costes operativos fijos, y aumentan repentinamente la demanda o escalan a un proveedor de servicios de nube pública durante los periodos de mayor carga de trabajo.

Mover datos es caro. Las soluciones bien diseñadas se benefician de la portabilidad y la movilidad de las cargas de trabajo en contenedores y sitúan los servicios lo más cerca posible de los datos que consumen

Las soluciones deben elegir la plataforma y los recursos adecuados para maximizar el valor de sus arquitecturas. Una solución de nube híbrida es capaz de abarcar múltiples nubes, incluidos los recursos on-premises, lo que da a los arquitectos la libertad de seleccionar la combinación óptima de recursos para satisfacer las necesidades de rendimiento de su solución

Las soluciones deben diseñarse para aumentar o reducir su capacidad de procesamiento añadiendo o eliminando unidades discretas (servidores, servicios, interfaces de red, etc.) en lugar de cambiar la capacidad de las unidades existentes, por ejemplo añadiendo más CPU a un servidor. Para lograrlo, las soluciones deben adoptar los siguientes principios de arquitectura:

• Los componentes sin estado son componentes que no conservan el estado del cliente o de la sesión (por ejemplo, la identidad de un usuario o las entradas de datos proporcionadas en la llamada anterior) entre interacciones, lo que elimina las dependencias entre los clientes y cualquier instancia específica de un componente. Esta falta de dependencia entre los componentes y sus consumidores significa que la solución puede ampliarse y reducirse añadiendo o eliminando instancias de componentes sin que ello repercuta en los consumidores de los servicios de los componentes. Un buen ejemplo de un componente sin estado es un cajero en la tienda de comestibles; siempre que haya al menos un cajero disponible, los compradores pueden pasar por caja y pagar sus compras, y los cajeros pueden añadirse y eliminarse según lo exija el volumen de compradores. Lo contrario de esto es que a los compradores se les asignara un cajero específico al comienzo de su visita al centro comercial. Si el cajero asignado se atasca o, peor aún, no está disponible, los compradores tienen que esperar o empezar de cero y el rendimiento general del supermercado (medido en compradores por hora) se ve afectado.

• Evitar las tareas de larga duración. Si una solución debe admitir tareas de larga duración (por ejemplo, realizar un cálculo científico complejo), la tarea debe diseñarse para admitir la ampliación o reducción a través de una instalación de interrupción y punto de control que permita a la solución apagar y reiniciar la tarea a medida que se agregan Recursos a y se eliminan de la solución.

• Datos en los extremos. Los componentes sin estado pueden, en teoría, escalar infinitamente y se pueden reutilizar entre clientes. Las soluciones de alto rendimiento envían el estado, es decir, los datos de usuario y aplicación, a la aplicación cliente y a las bases de datos en los extremos de la arquitectura de la solución y no mantienen ningún estado en las capas de arquitectura intermedias.

Recursos:
Con estado vs. sin estado

Diseñar soluciones como un conjunto de componentes altamente cohesionados y débilmente acoplados permite escalar los componentes de forma independiente en relación con la demanda del servicio que prestan. Enfoques de arquitectura como la arquitectura orientada a servicios y los microservicios incorporan esta práctica como principio básico de diseño, es decir, un conjunto de servicios altamente cohesivos que se comunican a través de API de alto nivel y débilmente acopladas.

Mover los datos entre los componentes de una solución suele ser el elemento que más tiempo consume en una transacción. Los componentes deben diseñarse para optimizar la frecuencia y el volumen de las comunicaciones para el ancho de banda disponible. Por ejemplo, una aplicación que realiza llamadas repetidas para recuperar valores individuales de una base de datos puede funcionar 'bastante bien' cuando se implementa en una red local, pero puede ralentizarse cuando el componente de la base de datos se traslada a un proveedor de servicios en la nube.

El estilo arquitectónico de transferencia de estado representacional (REST), que se utiliza habitualmente en aplicaciones basadas en web, es un buen ejemplo del tipo de equilibrio que presenta una solución bien diseñada: el estado representativo completo de un recurso se transfiere como un documento JSON, XML u otro tipo de documento que equilibra la cantidad de información transferida con la alta latencia de una interacción basada en web.

El almacenamiento en caché ayuda a limitar la demanda de recursos y servicios que producen datos. Considere utilizar el almacenamiento en caché para datos relativamente estáticos y de larga duración, y/o datos cuya producción resulte 'costosa'. Las soluciones bien diseñadas implementan mecanismos de almacenamiento en caché en todas las capas de la arquitectura de la solución, colocando las cachés lo más cerca posible del consumidor para limitar las comunicaciones entre el consumidor y la caché y mejorar el tiempo de respuesta general.

Los arquitectos deben tener en cuenta que el almacenamiento en caché puede ser exagerado. Un mecanismo de almacenamiento en caché mal diseñado o una caché demasiado grande pueden afectar negativamente al rendimiento general de la solución. Los arquitectos deben evaluar el tipo y la estrategia de almacenamiento en caché y, a continuación, medir su eficacia durante las pruebas y los análisis de rendimiento.

La mensajería asíncrona que utiliza colas de mensajes, modelos de devolución de llamada u otros medios permite que las soluciones se escalen de manera eficiente y se degraden con gracia bajo carga si se agotan los recursos. Las soluciones bien diseñadas se benefician de la comunicación asíncrona, especialmente las colas de mensajes, para dar a los usuarios finales una experiencia de usuario receptiva y evitar 'perder' las solicitudes de usuario si un componente falla. Este mismo mecanismo también se puede utilizar para interconectar sistemas que tienen diferentes niveles de servicio u horas de funcionamiento; por ejemplo, una aplicación 24x7 conectada a un sistema de registro de 9 a 5 con una cola de mensajes permite a la aplicación aceptar solicitudes de usuarios finales incluso cuando el sistema de registro no está disponible.

Las soluciones cambian con el tiempo y su rendimiento puede cambiar con ellas. Incorporar una instrumentación del rendimiento que permita a los equipos de desarrollo, pruebas y operaciones recopilar de forma no intrusiva las métricas de rendimiento de la aplicación ayuda a desarrollar y probar un producto sólido que utiliza métodos basados en pruebas. La instrumentación también ayuda en las pruebas funcionales y el análisis de defectos, y es una ayuda inestimable para mantener el rendimiento de una solución y ayudar a identificar las fuentes de los problemas de rendimiento en la producción. La instrumentación configurable y no intrusiva es compatible con la monitorización del producto, lo que garantiza la observabilidad de la solución en las operaciones y, por lo tanto, apoya a los equipos de DevOps y SRE.

Desde la perspectiva empresarial, el rendimiento de la solución en su conjunto es importante, lo que debe reflejarse en los requisitos holísticos no funcionales. Sin embargo, para las pruebas de rendimiento a nivel unitario, las pruebas de rendimiento tempranas que implementan el paradigma de desplazamiento a la izquierda y para el análisis de la causa raíz de los problemas de rendimiento, es posible que sea necesario especificar requisitos de bajo nivel, limitando la duración de las llamadas individuales, la latencia de la red, etc.

Por lo tanto, los requisitos de rendimiento de alto nivel suelen establecerse a nivel de proceso o transacción, por ejemplo, “el proceso de concesión de préstamos debe completarse en menos de dos minutos”, sin tener en cuenta cómo el rendimiento de los pasos y subprocesos individuales contribuye al resultado final. La creación de un presupuesto de rendimiento que asigne objetivos a cada paso del proceso en la fase de desarrollo proporciona objetivos medibles para los equipos de desarrollo de características, ayuda a identificar posibles áreas problemáticas y ayuda a centrar los esfuerzos de optimización del rendimiento y corrección donde sean más beneficiosos.

Los presupuestos de rendimiento deben considerar todas las capas de la solución, desde el hardware hasta el código de la aplicación. Omitir cualquiera de estos riesgos hace que la solución no pueda satisfacer las expectativas de los usuarios.

A la hora de probar el rendimiento, la prueba está en el resultado, es decir, solo probando la solución de extremo a extremo podemos estar seguros de que cumple con los requisitos. Esto refleja la naturaleza holística del análisis del rendimiento. Las pruebas de los componentes individuales (por ejemplo, la base de datos, el middleware, etc.) proporcionan una valiosa perspectiva sobre el análisis del rendimiento de una solución y ayudan a detectar los cuellos de botella en el rendimiento. Pero las pruebas de componentes por sí solas no son suficientes, ya que las interacciones entre los componentes pueden provocar cuellos de botella inesperados u otros impedimentos que pueden dar lugar a resultados subóptimos.

Centrarse en la percepción del usuario significa centrarse principalmente en los tiempos de respuesta percibidos y en la capacidad de respuesta general de la interfaz de usuario. La degradación de la capacidad suele ser invisible para los usuarios hasta que el rendimiento del producto se ve afectado. Un estudio de 1968 descubrió que hay tres órdenes de magnitud distintos en las interacciones humano-ordenador:

• Un tiempo de respuesta de 100 ms se percibe como instantáneo. Los humanos tienen un tiempo de reacción promedio de 250 ms, por lo que cualquier cosa menos de esto se percibe como muy rápido/instantáneo.
• Los tiempos de respuesta de 1 s o menos suelen ser lo suficientemente rápidos como para que los usuarios sientan que el rendimiento del sistema no les ralentiza.
• Los tiempos de respuesta superiores a 10 s hacían que los usuarios perdieran completamente la atención.

A partir de esto se planteó que un tiempo de respuesta de 2 s sería ideal, y por tanto 2 s o un poco más es un buen objetivo de tiempo de respuesta para soluciones de nube híbrida, siempre que sea posible. Por supuesto, las expectativas de los usuarios dependen de lo que estén haciendo; por ejemplo, nadie espera que una animación de pulsación de botón dure 2 s, pero 2-3 segundos es un buen objetivo general para aplicaciones orientadas al usuario.

Ampliando este principio, las soluciones deben incorporar la comprobación del tiempo de respuesta del usuario como parte de su ciclo de garantía de calidad mediante el uso de herramientas de comprobación de la interfaz de usuario. Por mucho que las latencias de las llamadas a la API sean importantes para el rendimiento general del producto, el rendimiento percibido por el usuario es la clave para atraer y retener a la base de usuarios.

Los usuarios suelen tener diferentes expectativas sobre lo que constituye un 'buen' rendimiento. Por ejemplo, un 'usuario avanzado' que utiliza una aplicación varias veces al día tiene unas expectativas de rendimiento muy diferentes a las de alguien que utiliza la misma aplicación quizás una vez al mes. Los usuarios también suelen tener dificultades para cuantificar lo que significa para ellos un 'buen' rendimiento, y a menudo se quedan atascados en requisitos como “lo suficientemente rápido” (que es un objetivo difícil de alcanzar). Además, la percepción individual del rendimiento del producto orientado al usuario es diferente para distintas personas. Por ejemplo, para algunos, un tiempo de inicio de sesión de 10 s es aceptable (especialmente si se trata de un evento singleton), para otros puede ser demasiado lento (especialmente si el inicio de sesión es una parte frecuente del flujo de trabajo).

Para ayudar a cuantificar y gestionar las expectativas de los usuarios, se recomienda:

•  Crear los requisitos no funcionales con un buen conocimiento de la base de usuarios y sus patrones típicos de uso de la aplicación.
  
  
•  Ponerse en contacto con los usuarios al principio del ciclo de diseño de la solución para comprender qué características utilizan con frecuencia y esperan una alta capacidad de respuesta, y qué características utilizan con menos frecuencia y, por lo tanto, pueden tolerar tiempos de respuesta más lentos.
  
  
• Utilizar percentiles para definir umbrales de tiempo de respuesta promedio o mediano. Esto permite algunas variaciones aleatorias inevitables de la capacidad de respuesta del producto y garantiza que unos pocos valores atípicos no provoquen que falle la aceptación general del producto.
  
  
•  Incluir pruebas realistas de tiempo de respuesta y feedback en las primeras versiones y previos de la solución. Las pruebas de rendimiento que se dejan para el final del desarrollo de una solución a veces pueden hacer que los equipos no puedan abordar los problemas de rendimiento sin tener que 'deshacer' partes significativas de la arquitectura de la solución. Solucionar los problemas de rendimiento al final del ciclo de desarrollo es caro.
  
  
• Asegúrese de que el diseño de IU incluya elementos como indicadores giratorios y barras de estado, para que el usuario sepa que la aplicación está activa y funcionando. Esto permite evitar la frustración innecesaria del rendimiento lento percibido del producto.
  
  
• Si es necesario, investigue soluciones similares y 'las mejores de su clase', analice las tendencias y publicaciones del sector y entreviste a expertos en la materia para desarrollar objetivos adecuados en cuanto a tiempo de respuesta y capacidad.

Monitorice y comunique los límites de rendimiento a los clientes.

El mal uso o la configuración incorrecta de un producto o de un componente de la solución puede ser una fuente de rendimiento deficiente y de una experiencia negativa para el usuario. Para evitar esta situación, los arquitectos deben:

• Tener en cuenta las limitaciones de rendimiento dentro de la solución y comunicarlas proactivamente a los usuarios. Por ejemplo, si una solución utiliza un canal de comunicación lento/de bajo ancho de banda, el arquitecto debe concienciar a los usuarios finales de que la descarga de imágenes de alta resolución se verá afectada.

• Permitir que los sistemas detecten y comuniquen cuándo las solicitudes están fuera de los parámetros de diseño de la solución siempre que sea posible. Por ejemplo, hacer que el sistema advierta activamente a los usuarios cuando intenten descargar archivos grandes a través de un canal lento.

Un enfoque habitual para las pruebas de rendimiento consiste en comprobar que la solución cumple sus objetivos de tiempo de respuesta con la carga máxima prevista para la solución, partiendo del supuesto de que, si la solución funciona bien con la carga máxima prevista, también lo hará con cargas inferiores. El problema de este enfoque es que solo proporciona un punto de datos por cada carga máxima probada, casi como un ejercicio de aprobado/suspenso.

Se prueba una solución bien diseñada utilizando el enfoque exploratorio por su capacidad de respuesta ante una variedad de cargas que varían en tamaño, mezcla de tipos de usuario y combinación de funciones probadas. Esto proporciona al equipo de soluciones información valiosa y multifacética sobre cómo interactúan los componentes de la solución para afectar al rendimiento, posibles cuellos de botella y cómo escalar la solución para abordar cargas de trabajo menores o mayores.

Este enfoque permite evitar las pruebas adicionales si los objetivos de carga previstos cambian y es necesario recopilar métricas de rendimiento en diferentes condiciones de carga. La interpolación de las dependencias existentes del rendimiento en las magnitudes de carga permite calcular métricas de rendimiento para cualquier carga dentro del espectro de las cargas probadas inicialmente (desde cero hasta las magnitudes del punto de interrupción y superiores).

El enfoque típico de las pruebas de rendimiento sigue el patrón simplificado “Medir los tiempos de respuesta con cargas/rendimientos determinados”. Este enfoque responde a la pregunta de si el tiempo de respuesta de las transacciones clave en las magnitudes máximas cumple con los acuerdos de nivel de servicio (SLA) existentes. Y, por lo general, las magnitudes probadas se limitan a "bajo”, "máxima” y "estrés”. Este enfoque puede responder a las preguntas sobre los tiempos de respuesta con cargas típicas, pero no ofrece la imagen completa del rendimiento del sistema en todas las situaciones vitales posibles.

El enfoque más avanzado de *pruebas exploratorias de rendimiento* tiene como objetivo la creación de una *instantánea del rendimiento* de la solución probada. La instantánea incluye un conjunto completo de métricas de rendimiento, recopiladas en el espectro más amplio de cargas soportadas, desde mediciones de un solo usuario hasta las cargas posteriores al punto de ruptura (cuando es posible, excepto cuando el sistema se bloquea). Esto incluye una recopilación de los tiempos de respuesta de las transacciones, el rendimiento de los datos y los datos de consumo de recursos recopilados en condiciones de carga creciente. Por “transacción” entendemos un trabajo finito del sistema, desde macrotransacciones como Iniciar sesión o Actualizar cuenta, hasta subtransacciones individuales (como la llamada de autenticación dentro de la transacción de inicio de sesión) o simples visitas http.

El conjunto completo de datos de rendimiento, la instantanea de rendimiento, incluye las métricas de rendimiento anteriores para el rango de carga “lineal” de baja carga (donde los subprocesos procesados individualmente no perciben la presencia de los demás y los tiempos de respuesta no aumentan con el aumento de la carga), el rango “no lineal”, en el que los tiempos de respuesta aumentan a medida que aumenta la carga, los puntos de saturación, en los que los rendimientos dejan de aumentar con el incremento de la carga y alcanzan niveles de saturación, y el rango posterior al punto de ruptura, en el que el rendimiento disminuye después de que los rendimientos alcancen su máximo y los tiempos de respuesta superen los niveles del SLA.

Cubrir toda la gama de cargas no suele requerir más esfuerzo por parte de los equipos de pruebas que las meras pruebas en las magnitudes “máxima” y “estrés” y las pruebas de resistencia, ya que se utilizan los mismos scripts de prueba (y el esfuerzo principal suele ser para crear esos scripts). Pero las ventajas de crear este tipo de instantáneas de rendimiento son las siguientes:

• No es necesario dedicar tiempo y esfuerzo a adivinar la configuración de prueba correcta que produzca el rendimiento de transacción “correcto” (“máxima” o “estrés”), simplemente incremente su carga y cubra *todas* las magnitudes de carga y rendimientos admitidos.

• Se puede determinar a partir de qué cargas comienzan a aumentar los tiempos de respuesta, dónde superan los niveles del SLA y dónde alcanzan los rendimientos sus niveles máximos.

• Esto permite medir directamente la capacidad del sistema, por ejemplo, la magnitud de la carga en la que se alcanza la condición de punto de interrupción (el tiempo de respuesta supera el SLA, o los rendimientos alcanzan los niveles máximos, o el uso de recursos del sistema entra en la 'zona roja' especificada, por ejemplo el uso de la CPU alcanza el 90 % o el sistema se bloquea, lo que ocurra primero). Esto significa que no es necesario utilizar los métodos típicos basados en conjeturas para el análisis y la planificación de la capacidad.

• En caso de que cambien las condiciones esperadas de la operación de producción (por ejemplo, la empresa redefine las cargas promedio y máxima esperadas), no es necesario volver a ejecutar las pruebas de rendimiento: las métricas de rendimiento buscadas para las diferentes magnitudes de carga se pueden obtener simplemente por interpolación o extrapolación de los resultados de las pruebas existentes.

• Cubrir todo el espectro de cargas en lugar de unas pocas magnitudes predefinidas permite garantizar que tengamos una visión completa del rendimiento del sistema y no pasemos por alto ningún posible problema de rendimiento al no probar el producto en condiciones extremas.

• Garantizar que las pruebas incluyan alcanzar los puntos de interrupción del rendimiento del sistema significa que sabemos dónde están los cuellos de botella de rendimiento, qué enlace, componente o capa fallará primero a medida que aumentan las cargas. Esto permite proporcionar un feedback útil y basado en pruebas a los equipos de arquitectura y diseño para mejorar la robustez y el rendimiento del producto.

Existen varios tipos de pruebas de rendimiento que pueden ejecutarse en una solución. Una solución bien diseñada hace uso de todos ellos.

• La evaluación comparativa manual es lo que su nombre implica, ejecutar manualmente funciones de la solución para tener una idea de primera mano de cómo responde la solución a un usuario.
• Las pruebas de calibración son pruebas que se realizan para comparar los resultados de las herramientas de pruebas automatizadas con otras fuentes, como las pruebas manuales o las métricas de rendimiento incorporadas, para validar la corrección de los guiones de prueba y los resultados de la herramienta de pruebas.
• Una prueba de inmersión, o prueba de resistencia, consiste en probar la solución bajo carga durante un tiempo prolongado para garantizar que la solución es estable bajo carga y no se deteriora con el tiempo, se puede utilizar de forma fiable y muestra el consumo de recursos previsto (es decir, no hay pérdidas de memoria).
• Las pruebas de máximas prueban la solución bajo la carga de trabajo máxima esperada, por ejemplo, el día más ocupado del año para garantizar la estabilidad de la solución y recopilar medidas clave como el tiempo de respuesta y el consumo de recursos bajo la carga máxima esperada.
• Las pruebas de estrés y picos se utilizan para probar la solución en múltiplos (por ejemplo, 2x o 3x) de la carga máxima esperada durante un intervalo corto (una prueba de estrés) o incluso cargas más altas durante un tiempo muy corto (pruebas de picos). Estos ayudan a identificar cuellos de botella en la solución y a ayudar al equipo de soluciones a identificar las dependencias escaladas de la solución.
• Las pruebas de carga variable, o pruebas de punto de interrupción, se utilizan para probar la solución bajo un rango de cargas para comprender el rendimiento de la solución bajo diferentes magnitudes de carga y ayudar al equipo de la solución a descubrir tendencias y límites de recursos dentro de la solución. Estas pruebas también permiten registrar los puntos de interrupción del producto, medir la capacidad de la solución y detectar los componentes más débiles del producto (los que tienen más probabilidades de fallar).

Su objetivo es aprovechar al máximo la variedad de datos de rendimiento adquiridos en las pruebas:

• Aplique métodos creativos y exploratorios para analizar los resultados de la prueba. Utilice los enfoques de *qué pasaría si* para explorar otros escenarios.
• Asigne los resultados de rendimiento a entornos de diferente tamaño y arquitectura para predecir el rendimiento de la solución en diferentes plataformas e implementaciones.
• Detecte cualquier incoherencia de los datos de rendimiento obtenidos mediante la detección de patrones y tendencias inesperados (por ejemplo, el *aumento* de la carga produce *reducción* de las tasas de transacción).
• Utilice técnicas de modelado para vincular la capacidad medida del sistema con el tamaño correspondiente de la base de usuarios, basándose en los patrones de uso asumidos.
• Recuerde siempre evaluar el impacto mutuo en el rendimiento de los diferentes flujos de trabajo que se pueden ejecutar simultáneamente en producción.
• Utilice diferentes fuentes de datos de rendimiento: desde los proyectos piloto hasta las pruebas unitarias y funcionales, pasando por DevOps y las señales doradas de SRE. Cualquier dato tiene valor en el análisis de rendimiento.
• Comparta más a menudo los resultados del análisis con los stakeholders. A menudo resulta útil obtener aportaciones valiosas de los demás, mejora la concienciación sobre el progreso de las pruebas y el análisis del rendimiento, ayuda a otros a comprender mejor un área tan *técnica* como el análisis del rendimiento y la capacidad, y mejora la visibilidad de los esfuerzos generales de validación no funcional.