En la actualidad, jmeter tiene una participación de mercado muy alta en el campo de las pruebas de rendimiento, la razón principal es que es relativamente más fácil de usar (código abierto, fácil de expandir) y más potente (interfaces que cumplen con múltiples protocolos) que otras pruebas de rendimiento. La actualización de las herramientas de pruebas de rendimiento basadas en plataformas permite una colaboración más eficiente en equipo, como la plataforma de pruebas de código abierto RunnerGo de la que vamos a hablar hoy.
Ventajas de la plataforma de herramientas de prueba de rendimiento
Como plataforma web, RunnerGo puede realizar gestión de interfaces, edición de guiones, edición de escenas y gestión de informes en línea, algo que herramientas como jmeter no tienen.
RunnerGo admite la visualización en tiempo real del estado del servidor, informes de prueba, registros de depuración y admite el envío de informes de prueba a buzones de correo específicos, mientras que jmeter no admite la supervisión del rendimiento de forma predeterminada y solo se puede implementar en modo GUI extendiendo el complemento de escucha. y modo sin GUI. A continuación solo se pueden generar informes de resultados.
Cuando se usa jmeter, la administración de la interfaz y las pruebas de rendimiento generalmente se realizan por separado, o se usan otras herramientas de depuración de API para la administración de la interfaz (como Apipost) y luego van a jmeter para configurar los scripts, pero de hecho, las pruebas de rendimiento deben basarse en la administración de la interfaz. Si lo hace, RunnerGo puede hacer referencia directamente a la interfaz depurada desde la administración de la interfaz, configurar una escena y luego realizar pruebas continuas y pruebas automatizadas sobre esta base, de modo que las pruebas de rendimiento se puedan realizar directamente durante la fase de prueba de la interfaz.
Análisis de estructura de RunnerGo y jmeter
El modo independiente de jmeter estará limitado por el propio mecanismo de jmeter y la configuración de hardware en la configuración general de la prensa, y puede admitir un máximo de varios cientos a mil subprocesos de solicitud de simulación. La implementación de pruebas de clústeres distribuidos traerá muchos problemas de gestión de operación y mantenimiento. Al mismo tiempo, el modo Maestro-Esclavo también ejercerá mucha presión interactiva sobre el nodo maestro, y es muy difícil implementar una prueba de presión de clúster distribuido a gran escala.
RunnerGo viene con una estructura distribuida que admite fácilmente la concurrencia a gran escala.
Para el rendimiento real de RunnerGo, hice un pequeño experimento para comparar y los resultados son los siguientes:
Un escenario de uso para ver noticias: seis interfaces, usando modo concurrente, 20 concurrencias y ejecutándose durante 10 minutos.
Prueba de presión bajo la misma configuración.
Informe de agregación de jmeter:
Informe de prueba enviado directamente al correo electrónico por RunnerGo
Debido a los diferentes métodos de cálculo, aquí solo se compara y se resume el número total de solicitudes:
RunnerGo número total de solicitudes: 98640, tasa de error: 0
Total de solicitudes de jmeter: 91219, tasa de error: 0