Rendimiento vs Satisfacción

Uno de los problemas principales de las áreas IT es el rendimiento de la plataforma y cómo dicho rendimiento tiene una relación directa con el negocio de nuestra organización. En plataformas donde la interacción de las personas con la plataforma es una parte importante para el desarrollo del negocio, por ejemplo, todas aquellas aplicaciones que interactuan con los usuarios, como son las aplicaciones Web,  el termino Rendimiento tiene un peso específico, ya que nosotros como ingenieros debemos conseguir el mayor rendimiento posible para ofrecer una respuesta a un ser humano y no a una máquina.

Una de las diferencias principales entre una máquinas y un ser humano es la subjetividad con la que una persona experimenta una situación y esta diferencia para una plataforma IT se puede convertir en un problema que debemos tener en cuenta, ya que no todas las personas, aun obteniendo los mismo resultados, experimentarán de la misma forma el uso que hacen de la plataforma. Cuando una persona interactua con un sistema de información, realiza dos acciones básicas, independientemente de la complejidad de las operaciones:

  • Introducir información en el sistema.
  • Obtener una respuesta satisfactoria del sistema.

Es importante entender que el usuario espera una respuesta satisfactoria y este es uno de los trucos que utilizan algunas aplicaciones muy conocidas. El tiempo que trascurren entre que el usuario finaliza la introducción de la información en el sistema, hasta que obtiene una respuesta, es el tiempo de espera. Dependiendo de la duración del tiempo de espera la satisfacción del usuario puede ser mayor o menor, además la subjetividad del ser humano impide que podamos obtener una relación directa entre tiempo de espera y satisfacción, no todos los seres humanos perciben las situaciones de la misma manera, por lo que el problema de cubrir las expectativas de los usuarios del sistemas frente a los tiempos de respuesta es un problema crítico para las organizaciones, ya que usuarios insatisfechos pueden convertirse en usuario que el negocio pierde.

Debemos entender que Rendimiento no significa Velocidad, de hecho según la Real Academia Española, el significado del término rendimiento es:

 

Rendimiento.

  • 1. m. Producto o utilidad que rinde o da alguien o algo.
  • 2. m. Proporción entre el producto o el resultado obtenido y los medios utilizados.
  • 3. m. cansancio (falta de fuerzas).
  • 4. m. Sumisión, subordinación, humildad.
  • 5. m. Obsequiosa expresión de la sujeción a la voluntad de otro en orden a servirle o complacerle.

 

 

Podemos comprobar que ninguna de las definiciones habla de velocidad, de hecho la que mejor se ajusta para un entorno IT es:

Proporción entre el producto o el resultado obtenido y los medios utilizados.”

En este punto, hemos hablado sobre el concepto de Rendimiento y sobre  la Satisfacción de los usuario, pero no hemos comentado nada sobre la relación que existe entre estos dos términos. No existe una relación directa entre Rendimiento y Satisfacción, ya que podemos tener una plataforma con un rendimiento inmejorable pero cuyos usuarios tengan un grado de insatisfacción enorme y
viceversa, podemos disponer de una plataforma con un rendimiento pésimo pero que permite a la organización disponer de un nivel excelente de satisfacción de los usuarios. Vamos a ver dos casos que nos sirvan como ejemplo de las situaciones anteriores:

Ejemplo A: Una plataforma dispuesta por 5 máquinas, las cuales están dando servicio al 90% de sus posibilidades, tanto de velocidad de procesamiento, como de uso de memoria y tiempo de respuesta en el acceso a disco. La plataforma soporta una aplicación para 1000 usuarios, es normal que aun estando los tiempos de respuesta al 100% la plataforma no da unos tiempos de respuesta al usuario los cuales sean satisfactorios. Este problema de satisfacción de los usuarios no está relacionado con el rendimiento, ya que el rendimiento de la plataforma es del 90%, estamos aprovechando los recursos disponibles sacando el mayor provecho de ellos, el problema está relacionado con el capacity planning que se haya realizado de la plataforma, ya que la plataforma debe crecer, bien para absorber mas usuarios, bien para intentar reducir los tiempos de respuesta.

Ejemplo B: Supongamos la misma plataforma del ejemplo anterior, pero esta vez el número de usuarios que la utilizan es de dos, es normal que pensemos que el grado de satisfacción de los usuarios sea muy superior al del ejemplo anterior pero el rendimiento de la plataforma deja mucho que desear, ya que no estamos sacando provecho de los recursos disponibles.

Los ejemplos anteriores ilustran como la relación entre rendimiento y satisfacción del usuario no es línea, es decir mayor rendimiento mayor satisfacción. Nosotros como ingenieros de la plataforma IT, debemos buscar un punto intermedio que permita tener un rendimiento en la plataforma el cual genere un grado de satisfacción del usuario correcto para el desarrollo del negocio.

esquema_1_rs.jpg

Tiempo de respuesta vs respuesta satisfactoria

En el apartado anterior comentamos que un usuario espera una respuesta satisfactoria del sistema y la interpretación de respuesta satisfactorio es subjetiva, como también es subjetivo la forma en la que  el usuario experimenta el tiempo de espera. Pero ¿qué ocurre cuando modificamos alguno de los parámetros anteriores? es decir, modificamos
el tiempo de respuesta  o bien el resultado que obtiene el usuario, para que la  sensación que tenga sea satisfactoria. Nosotros como ingenieros podemos trabajar en la reducción del tiempo de espera, ya que este tiempo está relacionado directamente con la plataforma IT. Pensemos en Google, la cual posee una enorme infraestructura IT
la cual permite reducir los tiempos de respuesta, pero Google no siempre da una respuesta satisfactoria en cuanto a los resultados, pero su tiempo de respuesta siempre es muy bajo, por lo tanto el usuario aunque no recibe la respuesta esperada, tiene un buen nivel de satisfacción, sencillamente porque tienen la impresión que el sistema responde muy rápidamente.

Tiempo de respuesta

Vamos a centrarnos en la variable que está relacionada directamente con la plataforma IT, es el tiempo de respuesta de la plataforma frente a una petición determinada. El tiempo de respuesta comienza justo en el momento que el usuario termina de introducir la petición y da la orden de ejecutarla, nosotros vamos a pensar en un click del ratón sobre un botón “Aceptar” en una aplicación, por ejemplo una aplicación WEB.

Se envía la petición

Tiempo de red (Tr1)

Se recibe la petición

Se trata la petición

Tiempo de procesamiento (Tp)

Se envía la respuesta

Tiempo de red (Tr2)

Se recibe la respuesta

El tiempo de red depende del tamaño de la petición, por lo tanto Tr1 no tiene por qué ser igual a Tr2, aunque la infraestructura de red (en teoría) sea la misma tanto para el envío como para la recepción. De los 3 tiempos, nuestra plataforma intervienen los 3, pero no de manera homogénea, ya que el tiempo de red, tanto Tr1 como Tr2 dependerá de la infraestructura del usuario, la infraestructura de terceros y también de nuestra  infraestructura de red. Por lo tanto, nosotros somos responsables de una parte del tiempo que se emplea en Tr1 y Tr2. En cuanto a Tp, es el tiempo de procesamiento de la petición, en este tiempo se incluye todo el tiempo que emplean las distintas tareas de nuestra plataforma para devolver una respuesta. El tiempo de procesamiento (Tp) es 100% nuestra responsabilidad y por lo tanto es en la reducción de este tiempo, donde tendremos mayores oportunidades para mejorar la percepción que tienen los usuarios de la plataforma sobre los tiempos de respuesta.

Desde el punto de vista del usuario  el tiempo de respuesta es:

Tusr = Tr1 + Tp + Tr2

Desde nuestro punto de vista, el tiempo de respuesta debe ser el mismo, pero debemos ser conscientes que aunque podemos trabajar en los 3 tiempos,  donde conseguiremos mejores resultados será intentando minimizar el tiempo de procesamiento (Tp).

Tiempo de procesamiento

El análisis del tiempo de procesamiento nos ayudará en la tarea de intentar encontrar un punto del procesamiento de la petición que podamos mejorar para que se reduzca en su conjunto el Tp. Dependiendo de la plataforma en la que trabajemos, debemos realizar un desglose de todas las operaciones que se realizan para procesar una petición, analizando los tiempos que se emplean en cada una de las operaciones.

Siguiendo una arquitectura típica, la mayoría de las plataformas están formadas por 3 capas:

  • La capa de Presentación.
  • La capa de Aplicación.
  • La cada de Datos.

En cada una de las capas identificaremos las operaciones que realizan los distintos componentes de la capa para tratar la petición. También mediremos los tiempos de transferencia de información entre una capa y la siguiente, para identificar posibles mejoras en la capa de comunicaciones.

Este tipo de análisis nos permitirá identificar aquellas partes de la plataforma las cuales no  están dando un buen rendimiento, ya sea por exceso de provisión como por defecto. Recordemos que un buen rendimiento no es obtener un resultado lo más rápidamente posible, sino que el tiempo de respuesta quede justificado por el coste de la petición. No debemos pensar cuando hablemos de rendimiento únicamente de velocidad, también debemos pensar en costes y justificaciones de las distintas soluciones que se ajusten a las necesidades de negocio de nuestra organización.

El análisis del rendimiento debemos verlo como ejercicio que abarque el conjunto de la plataforma IT, ya que debemos considerar la plataforma IT como un sistema complejo formado por elementos que interactuan mediante una serie de directrices, por lo tanto en el rendimiento intervienen tanto los elementos como la definición de las directrices.  Pensemos por ejemplo, para qué queremos disponer de discos rápidos, si resulta que la infraestructura de comunicaciones no tiene suficiente ancho de banda para transmitir todo lo que las aplicaciones obtienen de los discos, este es un ejemplo de una plataforma que pensamos dispone de un buen rendimiento en los discos, pero cuya infraestructura de red está por debajo de las necesidades de la nuestra plataforma, por lo que podemos afirmar que en su conjunto el rendimiento es muy bajo, ya que tenemos elementos que tienen un coste alto, como pueden ser los discos de fibra, pero de los que conseguimos una tasa de transferencia muy por debajo de sus posibilidades potenciales, debido a que las aplicaciones no conseguirá transmitir por la red, tan rápido como podrían leer de los discos.

Otro ejemplo, podría ser el uso de CPU, actualmente existen en el mercado una serie de procesadores multicore. Este tipo de procesadores tienen un gran potencial en cuanto a l rendimiento que podemos obtener de ellos. Han sido diseñados para ejecutar aplicaciones multithread, ya que se basan en un principio mediante el cual una aplicación multihread comparte el espacio de direcciones del proceso, por lo tanto todos lo threads, por el principio de proximidad tendrán las mismas peticiones de memoria y por lo tanto muchos aciertos en las caches. Pero por muchas máquinas con procesadores multicore que tenga nuestra plataforma, si la aplicación no está preparada para cierta carga, el rendimiento que sacaremos de los procesadores será muy pobre. Por ejemplo, un problema típico de las aplicaciones multithread es  que a partir de un número de sesiones concurrentes los threads de aplicación comiencen a competir por elementos de sincronización, lo que provocará que la ejecución normal de dichos threads se ralentice. La pregunta que nos debemos hacer es ¿en qué nos ayudan nuestras nuevas CPUs multicore? La respuesta es sencilla, en disponer de más threads luchando por un recurso compartido, es decir, sencillamente en nada. Este es un ejemplo de como un elemento, como puede ser una CPU multicore, con un buen potencial en cuanto a rendimiento, en ciertas circunstancias su rendimiento es muy pobre y puede darse el caso que hasta peor que en otro tipo de CPUs, pero este es otro tema que discutiremos otro día.

Estos ejemplos, sirven para ilustrar el por qué debemos analizar los tiempos de cada una de las tareas que ejecutan los distintos elementos de una plataforma para procesar una petición. Es sorprendente la veces que en una plataforma con un potencial en rendimiento enorme, no podemos obtener los resultados esperados por culpa de que dicho potencial de rendimiento se empobreces por el comportamiento de un único elemento, que a primera vista parecía insignificante, como una tarjeta de red, un espacio de disco compartido, el número de semáforos de un SO o la configuración por defecto del pool de conexiones a una base de datos.

Capa de presentación

La capa de presentación es la encargada de presentar los resultados solicitados a la plataforma, normalmente está formada por un pool de máquinas, sobre las que se balancean las peticiones y de esta forma poder distribuir la carga. Existen tres problemas que se pueden presentar en la capa de presentación y que afectan directamente al tiempo de respuesta.

  • El balanceo no sea homogéneo, es decir, que todas las máquinas no reciben el mismo número de peticiones, en este caso se produciría un problema de carga en algunas de las máquinas, impidiendo que tanto la recepción como la presentación de los datos no se hagan en los tiempos esperados de operación normal del sistema.
  • El tiempo de sesión sea insuficiente, la capa de presentación se encarga de mantener establecida la sesión con el usuario, una elección errónea en la configuración del tiempo de sesión del servicio puede provocar que se generen timeout en esta capa, generando de esta forma 2 problemas, por un lado se cierra la comunicación con la capa de aplicación, lo que suponen no poder aprovechar el trabajo que ésta capa estaba realizando y por otro lado, al cerrar la conexión con el usuario, este tiene la sensación de que se ha producido un error.
  • Problemas de Caché, la mayoría de las plataformas implementan algún tipo de cache en la capa de presentación, lo que reduce el número de peticiones, sobre todo, cuando hablamos de contenido estático. No disponer de una buena politica para implementar las caches puede provocar un rendimiento ineficiente en la capa de presentación.

En la mayoría de los casos la capa de presentación no implementa demasiada lógica del negocio, sencillamente existe para recibir y enviar datos, por lo tanto debemos asegurarnos que los datos, tanto de peticiones de entrada, como las respuestas de salida estén el menor tiempo posible en tránsito en esta capa. Ni que decir tiene que cualquier problema en esta capa, independientemente de lo bueno que sea el rendimiento en las capas inferiores, afectará directamente en el tiempo de respuesta que percibe el usuario.

Capa de Aplicación

La capa de Aplicación implementa la lógica del negocio, dependiendo de la complejidad de esta lógica la capa de Aplicación será mas o menos complicada desde un punto de vista de su arquitectura. La capa de Aplicación se encarga de modelar las respuestas que la plataforma debe dar, en función de las peticiones recibidas. Esta capa es la que puede presentar el mayor número de problemas, en cuanto al rendimiento se refiere. Es la capa mas compleja desde un punto de vista lógico. También tenemos el problema de la implementación que se haya realizado en la lógica de negocio. En esta capa podemos encontrar, entre otros problemas, alguno de los siguientes,  que afecten de forma directa al tiempo de respuesta:

  • Una mala implementación de la lógica de Negocio. Los componentes de la capa de aplicación son los encargados de modelar los datos para construir una respuesta, dependiendo de la implementación de los procesos de modelado de datos, la capa necesitará mas o menos tiempo.
  • Problemas de sincronización. Hoy en día la mayoría de las aplicaciones están costruidas sobre entornos multithread, permitiendo que varios threads de un mismo proceso trabajen de forma mas o menos coordinada para modelar los datos. Si los métodos de sincronización entre los distintos threads no están correctamente implementados, pueden provocar esperas para intentar acceder al recurso compartido, lo que se traducirá en un aumento del tiempo de respuesta. A parte de los problemas derivados de las espera, se puede producir una situación aún peor en la que los threads queden bloqueados, lo que se conoce como deadlock.
  • Problema en el balanceo de peticiones. Al igual que ocurre en la capa de presentación, normalmente la capa de aplicación está formada por una granja de servidores, sobre los cuales se balancean las peticiones para intentar distribuir la carga. Si las peticiones que recibe la capa de aplicación no son homogéneas en cuanto al orden de magnitud de sus pesos, se puede producir un desequilibrio en el balanceo de carga, algunas de las máquinas estarían procesando peticiones pesadas mientras siguen recibiendo otro tipo de peticiones mas ligeras, frente al resto de máquinas que solo reciben peticiones ligeras. Esta diferencia entra la carga de las máquinas provocaría de forma aleatoria un problema con los tiempos de respuesta.

A grandes rasgos, estos son tres ejemplos, de los problemas que primero se deberían intentar resolver en la capa de aplicación, ya que, dependiendo de la naturaleza de la plataforma IT que tenga nuestra organización, son los principales causas de aumento en el tiempo de respuesta.

Capa de datos

La capa de datos es la encargada de almacenar los datos de la plataforma, normalmente esta compuesta por una serie de máquinas en las cuales corre varias Bases de Datos. La capa de Aplicación se encarga de solicitar los datos que necesita a la Capa de Datos, así como solicitar también que se almacenen nuevos datos o las modificaciones que se vayan realizando. Los tiempos de respuesta de la capa de Datos intervienen directamente en el tiempo de respuesta del usuario, ya que la capa de aplicación cuando solicita un dato, debe esperar un tiempo determinado a que la capa de datos conteste. Los principales problemas que nos podemos encontrar en la capa de Datos son:

  • Problemas de acceso al hardware de almacenamiento. Los datos, normalmente, están almacenados en un espacio de disco, este espacio puede ser interno a la máquina o externo servidor por una red SAN/NAS. Realizar un análisis sobre las distintas capas por la que pasa el dato desde que solicita hasta que se obtiene, es una tarea imprescindible para identificar algún posible cuello de botella.
  • Configuración de caches en los gestores de datos. La mayoría de los gestores de datos, normalmente las Bases de Datos, disponen de una serie de parámetros para la configuración de caches internas localizadas, en la mayoría de las veces, en memoria RAM, realizar una configuración correcta de estas caches, evitara tener que solicitar el dato a disco y por lo tanto evitamos el tiempo que se necesita para traer el dato del disco.

En la capa de Datos, debemos estar seguros que el acceso al almacenamiento físico en disco en correcto, está bien dimensionado y los tiempos de respuesta del acceso a los disco está dentro de los márgenes que hemos establecido para que la respuesta a la capa de aplicaciones sea optima. También revisar que los distintos niveles de caché están perfectamente configurados y trabajan de forma que su uso sea eficiente, todos los datos que podamos recuperar de cualquiera de los distintos niveles de caché será mas rápido que tener que recuperar un número determinado de bloques en un disco físico.

Conclusión

Como mensaje resumen del post, cuando hablemos de Rendimiento no debemos pensar en velocidad, sino en el término eficiencia. Si conseguimos que nuestra plataforma sea eficiente conseguiremos entre otras cosas velocidad, pero he dicho “entre otras cosas”, estas otras cosas son, ajuste de costes, justificación de las soluciones sobre la arqutectura de la plataforma y sobre todo conocimiento de nuestra propia plataforma.