Pruebas de rendimiento en Producción

1. ¿Pruebas en Producción?

Los entornos diseñados para pruebas presentan limitaciones a la hora de realizar pruebas de rendimiento:

• Los entornos de pruebas son de capacidad inferior a los entornos productivos. Se han diseñado esencialmente para realizar pruebas funcionales y para soportar niveles de concurrencias inferiores a las de producción.

• No son idénticos. El entorno de pruebas y el entorno de produción están configurados por elementos diferentes:
• Elementos de red: firewalls, encriptadores, balanceadores
• Sistemas Operativos diferentes.
• Configuraciones diferentes en los servidores.

• Generalmente, el volumen de datos almacenados es inferior en los entornos de pruebas.

Estas limitaciones implican que los resultados de las pruebas de rendimiento obtenidos en los entornos de pruebas no son extensibles a los entornos de producción. Más allá de que los tiempos de respuesta estén relacionado con la capacidad de las máquinas, en general, el comportamiento de un sistema o aplicación depende de la configuración y carácterísticas de los recursos. Todos hemos oído frases como "en el entorno de pruebas no conseguimos reproducir el error que se está dando en producción", o "en producción ese error no se va a dar porque la configuración es diferente".

Una posible solución, más usada de lo que a podría caber esperar, es realizar las pruebas de rendimiento directamente sobre el entorno de producción para garantizar que los resultados obtenidos y el comportamiento del sistema bajo pruebas sea similar al que los usuarios se van a encontrar una situación real.

 

2. Condicionantes de las pruebas en Producción

A la hora de diseñar y ejecutar pruebas de rendimiento en entorno productivos, debemos tener en cuenta algunos condicionantes y carácterísticas. Veamos algunos de ellos:

• Datos de prueba:
• En Producción, las pruebas se realizan sobre datos reales. El uso de usuarios, passwords u otros datos de prueba puedeestar sujetos a clausulas de confidencialidad.

• Ciclos de pruebas/modificación de datos: 
• Por defecto, los ciclos de prueba actúan sobre datos reales. Las actuaciones sobre los datos quedarán realizadas de manera real: Altas, Bajas, modificaciones, etc.. se realizan sobre datos reales.

• Inyección de carga:
• Tenemos que asegurarnos que nuestros inyectores de carga "atacan" a la aplicación a través de los mismos componentes que los usuarios reales. La situación habitual en la que los inyectores de carga se encuentran sobre la misma red que los servidores de la aplicación, puede implicar que las peticiones se salten ciertos elementos de red como firewalls, encriptadores, etc... que sí se encuentran los usuarios reales. 

• Intrusividad:
• Las pruebas sobre entornos productivos son intrusivas para los usuarios reales. Por ejemplo, pueden introducir retardos, sobresaturar elementos de la red etc...

Podemos aplicar distintas soluciones para solventar estos condicionantes. Entre ellos podemos citar la creación de datos ficticios dentro de la producción, conmuntar el entorno a una base de datos ficticia para su uso únicamente durante las pruebas, o la posibilidad de recurrir al cloud testing para la inyección de carga desde áreas geográficas externas a la red corporativa.

Para el disño de las pruebas en producción podemos realizar  un mapa menata en el que escribamos cada una de las fases y las posibles condicionantes o riesgos. Un ejemplo es el siguiente:

"Click" para aumentar la imagen

3. Alcance de las pruebas en producción.

A pesar de que las pruebas de rendimiento en producción se acercan más a la realidad que las realizadas en un entorno de pruebas, no son la solución a todos los problemas. También presentan limitaciones y se ven afectados por factores que pueden alterar los resultados obtenidos y la propia efectividad de las pruebas. 

• Los entornos productivos suelen ser entornos securizados y que involucran un gran número de tecnologías: WEB, Base de Datos, HOST, distintas arquitecturas Middleware, Sistemas operativos, infraestructura de red, etc... Contar con equipos especialistas en todas las áreas implicadas y con permisos para realizar las monitorizaciones adecuadas puede ser una labor complicada. Una buena práctica, sobre todo en grandes organizaciones, es llevar la ejecución de pruebas de rendimiento al Comité de Cambios (CAB). 

• La selección de un horario de ejecución de bajo impacto (generalmente horario nocturno) puede provocar que elementos compartidos entre varias aplicaciones no se vean sometidos a  carga realista. Servidores, bases de datos, elementos de red, etc... suelen ser compartidos por varias aplicaciones. Es difícil evaluar el impacto que tendrá la actividad en otras aplicaciones sobre la aplicación probada.

• Generalmente se dispone de un juego de datos limitado para las pruebas. Reproducir la casuística de los usuarios reales es complejo y utilizar un juego limitado de datos hace que las pruebas se puedan ver afectadas por cacheos, bloqueos de datos, etc..

• La inyección de carga desde un conjunto limitado de IP's puede ser considerado como un ataque/hacking a nuestra organización.

• Debemos considerar el impacto en terceros sistemas ajenos a nuestra organización como son: webs/herramientas de estadísticas (p.e. google analitycs), servidores de correos, o terceras webs que han insertado publicidad o anuncios (ads) en la aplicación bajo pruebas.

A pesar de las limitaciones, sigue siendo necesaria la realización de pruebas de rendimiento sobre los entornos preproductivos. Las pruebas funcionales no aportan niveles de concurrencia elevados sobre las aplicaciones y ciertos errores permanecerán enmascarados. Aunque los entornos de pruebas sean limitados y diferentes en configuración, las pruebas de rendimiento sobre ellos pueden descubrir errores software antes que la aplicación llegue a producción.  Por ejemplo, errores como: memory leaks, agotamiento de cursores, bloqueos, uso incorrecto de los recursos, etc... es posible detectarlos con independencia del entorno en que se realicen las pruebas.

 

¿Habéis realizado pruebas de rendimiento sobre entornos productivos?, ¿cómo habéis gestionado las limitaciones?, ¿los resultados han sido más fiables que las pruebas realizadas en otros entorno?... Te invitamos a compartir tus experiencias dejando un comentario.