Jmeter es una de las herramientas de código abierto más extendidas para realizar pruebas de rendimiento en varios protocolos, como JDBC, FTP, LDAP, JMS y, el más utilizado, HTTP. Al ser una herramienta de OpenSource tiene limitaciones con respecto a herramientas profesionales, siendo la más destacada la gestión de los recursos hardware, debido especialmente a la ejecución de pruebas con un gran volumen de usuarios. Al simular escenarios con una gran cantidad de peticiones, puede saturar el rendimiento de la CPU y la memoria RAM del inyector, llegando a provocar excepciones en tiempo de ejecución y por consecuencia, la pérdida de peticiones e inducir al incumplimiento de la estimación prevista.
En primer lugar para optimizar el rendimiento de un inyector hay que tener en cuenta la complejidad de los scripts realizados, ya que si tiene una gran cantidad de elementos como parámetros, ficheros de I/O, expresiones regulares de control y temporizadores pueden llegar a utilizar un número excesivo de recursos y hasta incluso colapsar la máquina. Otro factor importante es la gestión de los recursos gráficos de Jmeter, para ello siempre es recomendable la ejecución sin entorno gráfico, ya que así no se desaprovechan los recursos para mostrar el interfaz, sino que se aprovechan para lanzar y recibir peticiones.
Todas estas soluciones optimizan el rendimiento de un inyector, pero tiene un tope, por lo que las máquinas tienen un máximo de usuarios soportados. Para intentar solucionar este inconveniente se debe de replantear un sistema lo más sencillo posible y con varios inyectores, paralelizando las peticiones, para optimizar recursos, rendimientos, estabilidad y resultados. Jmeter establece dos posibles soluciones al respecto:
- La primera solución, es crear un sistema distribuido con Jmeter, para ello es necesario la utilización de una máquina gestora o principal y una serie de máquinas esclavas que inyectan peticiones. Este método genera una carga adicional de datos entre la máquina gestora y las esclavas pudiendo saturar la red.
- La segunda solución es crear inyectores individuales con idénticos scripts sincronizados entre si, con la misma fecha de inicio y fecha de fin. Este sistema no satura la red con más información innecesaria ya que cada inyector trabaja de forma individual y se ejecutan en paralelo. La gran problemática que tiene es la gestión y la monitorización de los inyectores, porque son totalmente independientes entre si.
- El número máximo de usuarios que soporta un inyector sin que la máquina se vuelva inestable y por consiguiente, el número de peticiones totales que lanza por unidad de tiempo.
- El número de peticiones estimadas a realizar.
Con estos datos se puede calcular el número de inyectores que se deben de crear para generar la carga requerida y realizar una prueba exitosa. Teniendo siempre en cuenta que durante la ejecución se debe monitorizar cada uno de los inyectores por si se produce alguna anomalía.