Prueba de Estrés

¿Qué factores afectan los resultados de la prueba de estrés?

• Latencia de red desde la máquina de presión hasta el servidor (se recomienda realizar pruebas en la red interna o local)
• Ancho de banda desde la máquina de presión hasta el servidor (se recomienda realizar pruebas en la red interna o local)
• Si se habilita HTTP keep-alive (se recomienda habilitar)
• Si el número de concurrencias es suficiente (en pruebas externas se debe intentar habilitar una mayor concurrencia)
• Si el número de procesos en el servidor es razonable (se sugiere que el número de procesos del servicio helloworld sea igual al número de CPU, y que el número de procesos de la base de datos sea cuatro veces o más que el número de CPU)
• Rendimiento de la propia aplicación (por ejemplo, si se utiliza una base de datos externa)

¿Qué es HTTP keep-alive?

El mecanismo HTTP Keep-Alive es una técnica utilizada para enviar múltiples solicitudes y respuestas HTTP en una sola conexión TCP, y tiene un gran impacto en los resultados de las pruebas de rendimiento. Si se desactiva keep-alive, el QPS puede disminuir drásticamente.
Actualmente, los navegadores tienen habilitado keep-alive por defecto, es decir, después de que el navegador accede a una dirección http, mantendrá la conexión temporalmente sin cerrarla, reutilizando esta conexión para la siguiente solicitud, mejorando así el rendimiento.
Se recomienda habilitar keep-alive durante las pruebas de estrés.
Además, si no se habilita keep-alive durante la prueba de estrés, los puertos locales del cliente se agotarán rápidamente en estado timewait, lo que se manifiesta en que el número total de solicitudes supera cierta cantidad (generalmente alrededor de 28,000), produciendo solicitudes fallidas.

¿Cómo habilitar HTTP keep-alive durante la prueba de estrés?

Si se utiliza el programa ab para realizar la prueba de carga, es necesario agregar el parámetro -k, por ejemplo, ab -n100000 -c200 -k http://127.0.0.1:8787/.
apipost necesita que el encabezado de respuesta contenga el encabezado gzip para poder habilitar keep-alive (un bug de apipost, ver más abajo).
Otros programas de prueba de carga generalmente tienen keep-alive habilitado por defecto.

¿Por qué el QPS es muy bajo al hacer pruebas a través de internet?

Una alta latencia de internet provoca un QPS bajo, lo cual es una situación normal. Por ejemplo, al probar la página de baidu, el QPS puede ser de solo unas pocas decenas.
Se sugiere realizar pruebas en la red interna o local para eliminar el impacto de la latencia de red.
Si es imprescindible realizar pruebas a través de internet, se puede aumentar el número de concurrencias para incrementar el rendimiento (asegurándose de que el ancho de banda sea suficiente).

¿Por qué el rendimiento disminuye después de pasar por un proxy nginx?

El funcionamiento de nginx consume recursos del sistema. Al mismo tiempo, la comunicación entre nginx y webman también utiliza ciertos recursos.
Sin embargo, los recursos del sistema son limitados y webman no puede acceder a todos los recursos del sistema, por lo que puede ser normal que el rendimiento general del sistema disminuya.
Para minimizar el impacto en el rendimiento causado por el proxy nginx, se puede considerar deshabilitar los registros de nginx (access_log off;), habilitar el keep-alive entre nginx y webman, ver proxy nginx.

Además, HTTPS consume más recursos que HTTP, ya que HTTPS necesita realizar un apretón de manos SSL/TLS, cifrado y descifrado de datos, y el tamaño de los paquetes aumenta, lo que consume más ancho de banda, lo que puede provocar una disminución del rendimiento.
Si las pruebas se realizan con conexiones cortas (sin habilitar HTTP keep-alive), cada solicitud requerirá una comunicación adicional de apretón de manos SSL/TLS, lo que reducirá drásticamente el rendimiento. Se recomienda habilitar HTTP keep-alive para pruebas HTTPS.

¿Cómo saber si el sistema ha alcanzado su límite de rendimiento?

Generalmente, si la CPU alcanza el 100%, significa que el rendimiento del sistema ha llegado a su límite. Si la CPU aún tiene recursos disponibles, significa que no se ha alcanzado el límite, y se puede aumentar la concurrencia para mejorar el QPS.
Si aumentar la concurrencia no mejora el QPS, puede ser que el número de procesos de webman sea insuficiente; se sugiere aumentar el número de procesos de webman. Si aún así no mejora, se debe considerar si el ancho de banda es suficiente.

¿Por qué mi resultado de prueba muestra que el rendimiento de webman es inferior al del marco gin de go?

Las pruebas de techempower muestran que webman supera a gin en todos los indicadores, ya sea en texto plano, consultas a la base de datos o actualizaciones de la base de datos, en casi el doble.
Si tus resultados son diferentes, puede ser porque has utilizado ORM en webman, lo que ha provocado una pérdida de rendimiento considerable; puedes intentar comparar webman+PDO nativo con gin+SQL nativo.

¿Cuánto se pierde de rendimiento al usar ORM en webman?

A continuación se presentan un conjunto de datos de prueba de carga.

Entorno
Servidor Alibaba Cloud 4 núcleos, 4G, base de datos MySQL local, consulta aleatoria de un registro de 100,000 y retorno en json, pruebas realizadas localmente.

Si se utiliza PDO nativo
QPS de webman es de 17,800

Si se utiliza Db::table() de Laravel
QPS de webman se reduce a 9,400

Si se utiliza el Modelo de Laravel
QPS de webman se reduce a 7,200

Los resultados de thinkORM son similares, no hay mucha diferencia.

Nota
Aunque el uso de ORM puede reducir el rendimiento, para el 99% de los negocios, el rendimiento ya es suficientemente bueno. Si tú estás en ese 1%, también puedes resolverlo fácilmente aumentando la CPU o el servidor.
Debemos encontrar un equilibrio entre la eficiencia de desarrollo, la mantenibilidad y el rendimiento, en lugar de perseguir el rendimiento sin más.

¿Por qué el QPS es tan bajo al probar con apipost?

El módulo de pruebas de estrés de apipost tiene un bug, si el servidor no devuelve el encabezado gzip, no se puede mantener keep-alive, lo que lleva a una disminución drástica del rendimiento.
La solución es comprimir los datos al devolver y añadir el encabezado gzip, por ejemplo:

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

Además, en algunas situaciones, apipost puede no proporcionar la presión adecuada, lo que se manifiesta como el mismo nivel de concurrencia con un QPS aproximadamente un 50% menor en comparación con ab.
Se recomienda usar ab, wrk u otro software especializado en pruebas de carga en lugar de apipost.

Establecer el número adecuado de procesos

Webman habilita de forma predeterminada un número de procesos igual a CPU*4. En realidad, para la prueba de carga del servicio hello world sin IO de red, el número óptimo de procesos es igual al número de núcleos de CPU, ya que esto reduce el coste del cambio de contexto.
Si se trata de un servicio que tiene base de datos, redis u otros IO bloqueantes, el número de procesos se puede establecer entre 3 a 8 veces el número de CPU, ya que se requerirán más procesos para aumentar la concurrencia, y el coste del cambio de contexto puede ser relativamente despreciable en comparación con los IO bloqueantes.

Algunos rangos de referencia para pruebas de estrés

Servidor en la nube 4 núcleos 4G 16 procesos Prueba local/en red interna

Datos de prueba de terceros de techempower

Ejemplos de comandos de prueba

ab

# 100000 solicitudes 200 concurrencias habilitando keep-alive
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 solicitudes 200 concurrencias sin habilitar keep-alive
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200 concurrencias probando durante 10 segundos con keep-alive habilitado (por defecto)
wrk -c 200 -d 10s http://example.com