Cómo cargar pruebas y ajustar el rendimiento de la API (I)
A lo largo de los años, el papel de las API ha seguido evolucionando, aunque las API solo se utilizaban como puntos de integración entre internos. sistemas en el pasado, pero ahora se ha convertido en el sistema central de la empresa, construido sobre aplicaciones web y móviles.
El rendimiento lento no es un problema cuando la API se utiliza solo para manejar tareas de backend, como generar informes. Pero hoy en día, las API están evolucionando lentamente hasta convertirse en el vínculo principal entre los servicios y los usuarios finales. Este cambio de roles clave plantea un punto importante: el rendimiento de la API sí importa.
Si la fuente de datos API responde rápidamente, no importa qué tan bien esté diseñada la aplicación front-end; si la API responde lentamente, no importa qué tan bien esté diseñada la aplicación front-end; . Ahora, nuestra aplicación cliente muestra fuentes de datos que pueden agregarse a partir de múltiples respuestas API, por lo que el rendimiento es muy importante para esta arquitectura de microservicios.
No es exagerado decir que un rendimiento excelente es la mayor ventaja de las API. Sabemos que la única forma correcta de lograr sus objetivos es encontrar el punto crítico o camino crítico del problema y medir y ajustar repetidamente su sistema arquitectónico hasta alcanzar el objetivo deseado. Para las API, el proceso de medir y mejorar el rendimiento es el proceso de pruebas de carga y estrés.
Este artículo se centrará en cómo realizar pruebas de estrés de carga en API. Comenzaremos con un ejemplo simple y no probado, luego agregaremos una capa de control de acceso para asegurarnos de que todo esté rigurosamente probado y listo para manejar tráfico real.
En primer lugar, debemos aclarar qué queremos probar, que pueden ser todas las interfaces API, una única interfaz API o pruebas de rutina de interfaces API que deben solucionarse o mejorarse.
En este artículo usaremos una API de muestra, una API de Node.js para juegos de mesa, que contiene tres API:
/question: devuelve una tarjeta negra aleatoria
/answer: devuelve una tarjeta blanca aleatoria.
/pick--devuelve un par aleatorio de preguntas y respuestas
Cuanto más similar sea el perfil de carga que pruebes al de tu entorno real, más útil será tu prueba de carga. No importa si sabe que su API puede manejar un rendimiento de 400 solicitudes por segundo si no sabe cuál es el tráfico real o si no sabe si la carga es consistente en todas las interfaces.
Por lo tanto, debes comenzar recopilando datos de uso de API. Puede obtener estos datos directamente de los registros del servicio API u otras herramientas de rendimiento de aplicaciones que esté utilizando, como New Relic. Antes de realizar la primera prueba de su API, debe comprender bien lo siguiente:
(1) Rendimiento promedio (expresado en solicitudes por segundo)
(2) Rendimiento máximo (¿Cuál es el tráfico máximo que obtiene en un momento determinado? (Rendimiento máximo))
(3) Distribución del rendimiento entre las interfaces API (¿Algunas interfaces tienen tráfico muy alejado entre sí? Mucho más alto que otras interfaces
(4) Distribución del rendimiento por usuario (¿unos pocos usuarios generan la mayor parte del tráfico o el tráfico se distribuye de manera más uniforme?)
Otro Los puntos clave a considerar son cuáles El tráfico se simulará durante la prueba. Los puntos clave a considerar son:
(1) Generación de carga repetida
(2) Patrones de tráfico simulados
(3) Tráfico real
Generalmente es mejor comenzar las pruebas con el método más eficiente y luego avanzar a pruebas que se parezcan más al mundo real.
Podemos utilizar la generación de carga repetida como primera prueba de la interfaz API. Esto no solo puede verificar si nuestro entorno de prueba es estable, sino que, lo que es más importante, nos permite encontrar el rendimiento máximo que la API puede soportar, conociendo así el límite superior. de rendimiento que la API puede lograr. ¿Cuánto es?
Una vez que encuentre el límite superior de rendimiento de su API, puede comenzar a pensar en cómo dar forma al tráfico de prueba generado para que se parezca más al mundo real. Realizar pruebas con tráfico real sería ideal, pero menos factible en la práctica. Simular el tráfico real es difícil y requiere mucho tiempo. Por lo tanto, tenemos un compromiso: primero estudiar los datos del análisis de tráfico y luego realizar una simulación probabilística simple. Por ejemplo, tiene 100 interfaces API (consejo: aquí traduje los puntos finales originales a interfaces. También puede traducirlos a puntos finales, pero es más fácil de entender cuando se traducen a interfaces. Verificó el uso el mes pasado y encontró que 80). El tráfico proviene de 20 interfaces, de las cuales 3 interfaces representan el 50% del tráfico. Luego puede crear una lista de solicitudes que coincidan con esta probabilidad y proporcionarla a la herramienta de prueba de carga. Esto es relativamente mucho más rápido y está relativamente cerca de su carga real y puede mostrarle lo que podría encontrar en un entorno real.
Finalmente, si tienes registros de acceso reales para la API que deseas probar, puedes usarlos para lograr lo más parecido a la realidad objetiva. La mayoría de las herramientas de prueba de carga que analizaremos más adelante toman una lista de solicitudes como archivo de entrada. Puede tomar sus registros de acceso y formatearlos ligeramente para que coincidan con el formato requerido por cada herramienta de prueba. Una vez que haya hecho esto, podrá reproducir fácilmente el tráfico de producción en su entorno de prueba.
Bien, ahora que sabes lo que quieres probar, el último paso de preparación es configurar tu entorno de prueba. Necesita un entorno de pruebas dedicado. Si no tienes miedo de que tu jefe te regañe, o simplemente eres un poco más voluntarioso, puedes realizar pruebas de rendimiento directamente en el entorno de producción, pero si algo sale mal, no me digas que no te lo dije. primero.
Si tiene un entorno de preproducción o sandbox configurado y su API se está ejecutando en él, ya está todo listo. Dado que usaremos la API de muestra en este artículo, configuraremos nuestro entorno en una instancia de servicio de AWS.
En nuestro ejemplo, utilizamos una API simple que no requiere leer datos del disco ni mantener grandes conjuntos de datos en la memoria. Podemos elegir la instancia de Linux C4.large.
Nota: Comparamos otras instancias de AWS con una cantidad similar de recursos de procesamiento pero con mayor memoria, pero en las pruebas reales, la mayor parte de la memoria no se utilizó, por lo que elegimos C4.large
A continuación, ejecutamos una instancia de prueba de carga emparejada (servidor), que es solo un servidor que ejecuta un programa de prueba simulado que ejecutará nuestra API enviándole solicitudes repetidamente a través de múltiples conexiones simultáneas. Este es solo un servidor que ejecuta un programa de prueba simulado que enviará solicitudes repetidas a nuestro servidor API a través de múltiples conexiones simultáneas. Cuanto mayor sea la carga a simular, mayores serán los requisitos de rendimiento de la máquina. Nuevamente, se trata de una carga de trabajo que requiere un uso intensivo de la CPU. Aquí elegimos un servidor AWS c4.xlarge con 4 núcleos virtuales y 16 ECU de procesador optimizadas
Elegimos implementar todas las instancias en la misma zona de disponibilidad (el servidor API está en la misma región que el servidor de prueba/ sala de ordenadores), que puede minimizar el impacto de factores externos en los resultados de la prueba.
Tenemos un entorno sandbox ejecutando la API y otro servidor listo para comenzar las pruebas de carga. Si es la primera vez que realiza pruebas de rendimiento, seguramente querrá saber cuál es la mejor manera de hacerlo. En esta sección, compartiremos con usted cómo elegimos nuestras herramientas y al mismo tiempo le presentaremos algunas de las mejores herramientas actualmente en el mercado.
JMeter
El número uno es Apache JMeter, un programa Java de código abierto cuya principal característica es que proporciona una potente y completa interfaz gráfica de usuario para la creación de pruebas. Un plan, que consta de pruebas. componentes que definen varias partes de la prueba, como (1) subprocesos utilizados para inyectar pruebas de carga
(2) solicitudes HTTP utilizadas en pruebas parametrizadas
(3) Se pueden agregar oyentes , como componentes de prueba de widgets, para mostrar los resultados principales de diferentes maneras
Ventajas:
(1) Es la mejor herramienta para pruebas de carga funcional. Puede establecer condiciones para simular flujos de usuarios complejos y crear aserciones para verificar el comportamiento.
(2) Es fácil modelar solicitudes http complejas (como verificación de inicio de sesión o carga de archivos antes de la solicitud)
(3) Es altamente escalable y tiene una gran cantidad de comunidades Se pueden utilizar complementos para modificar o ampliar comportamientos integrados
(4) Es de código abierto y gratuito
Desventajas:
(1) La interfaz gráfica de usuario tiene una larga curva de aprendizaje, hay un montón de opciones y mucha información que debes conocer antes de ejecutar tu primera prueba.
(1) La GUI tiene una larga curva de aprendizaje, con un montón de opciones y mucha información que debe entenderse antes de ejecutar la primera prueba.
(2) Los pasos son engorrosos cuando se prueban cargas elevadas. Primero debe generar un plan de prueba XML utilizando una herramienta GUI y luego importar el plan de prueba para ejecutar las pruebas en modo sin GUI porque la GUI consume muchos recursos para generar carga. También debe tener cuidado de deshabilitar o habilitar todos los oyentes (componentes que recopilan datos y muestran mediciones), ya que también consumen recursos. Una vez completada la prueba, debe importar los datos del resultado sin procesar a la interfaz gráfica de usuario para ver los resultados.
(3) Si su objetivo es probar el rendimiento sostenido durante un período de tiempo (por ejemplo, 1000 solicitudes por segundo durante 60 segundos), es difícil encontrar una cantidad adecuada de subprocesos y temporizadores simultáneos. para encontrar un valor estable.
JMeter fue justo la herramienta con la que empezamos a probar y rápidamente comenzamos a buscar alternativas. La razón es que si su objetivo es realizar pruebas de estrés en flujos de usuarios complejos en una aplicación web, entonces JMeter es probablemente la mejor herramienta, pero si solo necesita realizar pruebas de rendimiento en algunas interfaces API HTTP, entonces usar JMeter no es diferente. gallinas para obtener huevos.
Wrk
Wrk es una herramienta muy similar al tradicional Apache Benchmark (originalmente utilizado como herramienta de prueba para servidores Apache). Wrk y ab son completamente diferentes de JMeter:
(1) Todo se puede configurar y ejecutar mediante herramientas de línea de comandos.
(2) Menos configuración pero funciones potentes. Se puede generar una carga HTTP básica con solo unas pocas configuraciones.
(3) Rendimiento potente
Sin embargo, en comparación con En comparación con las herramientas ab tradicionales, todavía tienen algunas ventajas, principalmente:
(1) Multihilo, por lo que pueden aprovechar los procesadores multinúcleo y generar cargas más altas más fácilmente
(2) Es muy fácil comenzar a usar scripts Lua, por lo que es fácil generar cargas mayores. (2) Es fácil ampliar el comportamiento predeterminado utilizando scripts Lua
La principal desventaja es que el informe generado de forma predeterminada es muy limitado en contenido y formato (solo texto, sin gráficos). Si su objetivo es encontrar la carga máxima que puede manejar una API, entonces wrk es la mejor herramienta para usted.
Vegeta
Vegeta es una herramienta de línea de comandos de código abierto, pero adopta un enfoque diferente al que hemos visto antes. Se centra en cómo lograr y mantener una tasa de solicitudes por segundo.
Es decir, se enfoca en probar cómo se desempeñará la API como servicio al admitir X solicitudes por segundo, lo cual es útil cuando tienes datos reales o una estimación del tráfico pico que obtendrás, puedes usar esto para verificar que tu API cumpla tus necesidades.
Herramientas SaaS
Como se mencionó anteriormente, ejecutar pruebas de carga simples requiere un entorno configurado. Recientemente, hay algunos productos que ofrecen servicios de pruebas de carga. Probamos dos de ellos, Loader.io y Blazemeter (digresión: Alibaba también tiene una herramienta de prueba de rendimiento PTS, que quizás los extranjeros no hayan probado).
Nota: Solo probamos las versiones gratuitas de estas dos herramientas, por lo que los resultados que obtuvimos se limitan a las versiones gratuitas.
Blazemeter
Este producto tiene las mismas deficiencias que JMeter que mencionamos anteriormente: si solo necesita usarlo para pruebas de carga alta, entonces necesita crear la prueba en la interfaz GUI programe y luego impórtelo a otro JMeter que se ejecute en modo sin GUI.
JMeter puede importar planes de prueba a su nube y ejecutarlos, pero desafortunadamente, la versión gratuita solo se puede configurar con 50 usuarios simultáneos.
Loader.io
Esta es una herramienta de servicio de prueba de carga en la nube simple pero poderosa lanzada por SendGrid. Tiene las funciones que necesita y hermosos informes visuales. La versión gratuita de Loader.io es bastante buena, con un rendimiento de hasta 10.000 solicitudes por segundo y básicamente puedes ejecutar pruebas de carga reales con ella.
Recomendamos utilizar varias herramientas para verificar los resultados de la prueba, y diferentes herramientas tienen diferentes funciones y métodos que pueden reflejar más aspectos de los resultados de la prueba.
Primero intentamos encontrar el rendimiento máximo que la API puede manejar. Con este rendimiento, nuestro servicio API alcanzará la utilización máxima de la CPU sin devolver errores ni tiempos de espera. Este rendimiento se puede utilizar como la cantidad de solicitudes por segundo que usamos en pruebas posteriores.
Nuevamente: la CPU es uno de los factores limitantes, pero también debes saber qué recursos se convertirán en el cuello de botella de rendimiento de tu API.
Es necesario instalar algunas herramientas en el servidor API para monitorear la utilización de recursos durante las pruebas. Usamos Keymetrics.io y el módulo ?PM2.
Nuestra aplicación Node.js ejecuta un servicio HTTP muy simple. Node.js está diseñado para tener un solo subproceso, pero para aprovechar los núcleos duales en la instancia c4.large de AWS, utilizamos las capacidades de agrupación en clústeres de PM2 para ejecutar los dos procesos de trabajo de la aplicación.
Debido a que nuestra API es completamente sin estado, usar el módulo de clúster central de PM2 (que PM2 usa directamente internamente) es muy simple. Las capacidades de agrupación en clústeres proporcionadas por PM2 proporcionan excelentes comandos de acceso directo para iniciar/detener/recargar aplicaciones, así como para monitorear procesos.
Primero probamos la API usando Loader.io. A continuación se muestran los resultados de una prueba que duró 30 segundos a 10.000 solicitudes por segundo, que es el rendimiento máximo permitido por la versión gratuita de Loader.io.
Durante las pruebas, observamos que el procesador CPU del servidor API alcanzó una capacidad de 100 solo unas pocas veces durante las pruebas.
Esto indica que nuestra API puede ser capaz de manejar un mayor rendimiento. Luego hicimos una segunda prueba ejecutando wrk que confirmó esto. Nuestro objetivo es llevar el rendimiento del servidor API al límite.
wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions
Los siguientes son los resultados de nuestras múltiples iteraciones de pruebas:
Ejecución de prueba de 1 m @ http://api-server/question
4 subprocesos y 1000 conexiones
Estadísticas de subprocesos Avg Stdev Max /- Stdev
Latencia 62,23ms 30,85ms 1,35s 99,39
Solicitudes/segundo 4,07k 357,61 5,27k 94,29
Distribución de latencia
50 60,04ms
75 63.85ms
90 64.17ms
99 75.86ms
972482 solicitudes, tomando 1.00m, leyendo 189.89MB
Solicitud/ Segundos: 16,206.04
Transferencias/segundo: 3,16 MB
Los resultados mostraron que nuestra corazonada se confirmó: alcanzó 16.206 solicitudes/segundo manteniendo una latencia razonable en el percentil 99 es de sólo 75,86 milisegundos. Usaremos esto como base para obtener el máximo rendimiento, porque esta vez estamos analizando la capacidad máxima que puede manejar el servidor API:
Acabamos de presentar una forma sencilla de descubrir qué es la API. puede manejar cargas de tráfico máximas; a lo largo del camino, también presentamos y analizamos algunas de las herramientas que hemos visto.
Estén atentos a la segunda parte de este artículo, donde cubriremos cómo controlar el tráfico para que los clientes aleatorios no puedan dañar su API fácilmente. Mostraremos cómo garantizar que el rendimiento de su API no se vea afectado al agregar un proxy delante de la arquitectura.
Este artículo está traducido de: Cómo probar la carga de tu API y ajustar el rendimiento.