FAQ de OpenResty | Estructura de red para pruebas, características relacionadas con SSL, DSL, herramienta `ab`

La serie de artículos de OpenResty ha sido actualizada hasta ahora, y hemos terminado de aprender la parte sobre pruebas. Felicitaciones por no quedarse atrás, por aprender y practicar operaciones activamente, y por dejar entusiastamente sus pensamientos.

Muchas de las preguntas planteadas en los comentarios son valiosas, y algunas de las más típicas e interesantes han sido extraídas especialmente como el Q&A de hoy.

Hoy vamos a ver estas cinco preguntas.

Pregunta 1: ¿Cómo construir la estructura de red para las pruebas?

P: ¿Debería el cliente que ejecuta wrk colocarse en una máquina en la red externa o en una máquina en la misma LAN que el servidor? ¿Cuál de estas dos opciones es más significativa para las pruebas de rendimiento?

R: Para probar servicios relacionados con la web, elegir la herramienta de prueba adecuada es solo un buen comienzo, y cómo construir la estructura de red para las pruebas también es una parte esencial del seguimiento.

En general, queremos probar los límites de rendimiento del servicio solo, excluyendo todas las interferencias de la red. Para este propósito, podemos tener dos formas de construir la red para hacer la prueba de estrés.

El primer método es desplegar wrk y las aplicaciones del servidor en la misma máquina con buen rendimiento. Por ejemplo, podemos activar ocho trabajadores en NGINX y dividir los recursos restantes de la CPU entre wrk, por lo que solo hay comunicación de red local, minimizando el impacto de la red.

El segundo método es construir una LAN con un enrutador dedicado y conectar la máquina donde está wrk a la máquina donde está el servidor.

No se recomienda probar directamente en una red existente porque la mayoría de las redes tienen switches y firewalls, que pueden limitar las pruebas de estrés de grandes volúmenes de tráfico y causar resultados de prueba inexactos.

Además, me gustaría mencionar algunas palabras más sobre las herramientas de prueba de rendimiento. Primero, las herramientas de prueba de rendimiento pueden tener problemas de Coordinated Omission, a los que debes prestar especial atención al analizar los datos de latencia de la herramienta.

Coordinated Omission significa que al hacer pruebas de rendimiento, no es suficiente contar el tiempo entre enviar y recibir una respuesta, que es solo el tiempo de servicio, por lo que las estadísticas perderán muchos problemas potenciales. Por lo tanto, también necesitamos incluir el tiempo de espera de la solicitud de prueba, que en general es el tiempo de respuesta que les importa a los usuarios. Por supuesto, si tu programa del lado del servidor puede estar bloqueando, solo necesitas considerar este problema. De lo contrario, puedes ignorarlo.

Pregunta 2: ¿Puede test::nginx probar características relacionadas con SSL?

P: ¿Es imposible probar características relacionadas con SSL con test::nginx?

R: Este no es el caso. test::nginx puede probar características relacionadas con SSL; puedes consultar ssl.t. Este archivo de caso de prueba prueba todo el proceso del certificado SSL. Primero, como puedes ver, el caso de prueba usa código Lua para leer las claves públicas y privadas del certificado local; luego, configura el certificado a través de la API HTTP; finalmente, usa cosocket para hacer el handshake SSL y acceder para verificar si el certificado es válido.

De hecho, no solo SSL, sino también las características incluidas en OpenResty pueden ser anuladas usando test::nginx.

Cuando no estés seguro de si una característica particular puede implementarse con test::nginx, puedes buscar primero los casos de prueba de lua-nginx-module y otros proyectos de código abierto de OpenResty, y generalmente puedes encontrar ejemplos correspondientes. Después de todo, test::nginx es muy jugable y variable, y algunas combinaciones y trucos inesperados están esperando ser descubiertos.

Pregunta 3: ¿Qué es exactamente DSL?

P: ¿Qué son exactamente DSL y test::nginx?

R: DSL significa Domain Specific Language. El propósito de DSL es diferente de los lenguajes de desarrollo comunes. No es para resolver las necesidades de un dominio general, sino las de algún dominio. El DSL más famoso es SQL, el Lenguaje de Consulta Estructurado utilizado en el dominio de las bases de datos.

En cuanto a test::nginx, es un DSL creado para abordar las necesidades de prueba de NGINX y OpenResty. De hecho, los autores de OpenResty han inventado muchas ideas de DSL y han traído muchos intentos y soluciones nuevos a la comunidad de OpenResty. Sin embargo, como se mencionó en el artículo anterior, DSL es un arma de doble filo, y el criterio principal para medir el valor de DSL es si puede traer una mejora en la productividad a los usuarios finales.

Pregunta 4: Problema de instalación de test::nginx

P: Después de ejecutar git clone, ¿necesito ejecutar el siguiente comando para instalar test::nginx?

cd test-nginx
perl Makefile.PL
make
sudo make install

R: De hecho, este no es el caso. Aquí puedes consultar algunos proyectos de código abierto.

Paso 1: instálalo a través del gestor de paquetes

sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)

Paso 2: git clone el último test::nginx

git clone https://github.com/openresty/test-nginx.git test-nginx

Paso 3: incluye el directorio test-nginx cuando uses el comando prove

prove -Itest-nginx/lib -r t

Como mencioné anteriormente, las mejores guías para instalar OpenResty y los proyectos circundantes están en CI, no en la documentación. Esto puede ser diferente de otros proyectos, principalmente porque OpenResty mantiene su propio fork o versiones específicas de algunos de los proyectos circundantes y porque OpenResty también depende en gran medida de CI. Por lo tanto, debes usar y probar OpenResty de la misma manera que se construye en CI para garantizar la coherencia con la oficial.

Pregunta 5: ¿Es buena la herramienta de prueba ab?

P: ¿Cómo recuerdo que Yichun Zhang mencionó frecuentemente ab como la mejor herramienta de prueba en Google Groups?

R: Como mencioné en el artículo, ab no es una buena herramienta de prueba de rendimiento en cuanto a características de la herramienta, porque no puede generar suficiente presión de solicitudes. Sin embargo, el rendimiento del programa del lado del servidor es poderoso ahora. Usamos ab en lugar de wrk en test::nginx porque en el modo TEST_NGINX_BENCHMARK, test::nginx usa ab o weighttp, dependiendo de la versión del protocolo HTTP, como la herramienta para las pruebas de rendimiento.

Además, espero que notes que la tecnología de Internet está cambiando muy rápido, y cada uno de nosotros necesita actualizar nuestros conocimientos y habilidades a tiempo. Por ejemplo, en mi opinión, esta elección de test::nginx ahora necesita ser actualizada, y Yichun Zhang puede no haber sabido de la existencia de wrk en ese momento. Por supuesto, tal vez habrá mejores herramientas de prueba de rendimiento en el tiempo que wrk, y naturalmente deberíamos tener una mente positiva y abierta para aprender y elegir.

Hoy, principalmente respondo las preguntas mencionadas anteriormente. Espero que a través de la comunicación y Q&A, pueda ayudarte a convertir lo que aprendes en lo que obtienes. También te invito a compartir este artículo para que podamos comunicarnos y progresar juntos.