Reflexiones sobre la comparación de rendimiento entre Go y PHP

pensar

Al usar Go y PHP con una configuración razonable (marco convencional) para implementar las mismas funciones, la brecha de rendimiento es de órdenes de magnitud. Por supuesto, considerando la mayoría de los escenarios comerciales, el uso de PHP sigue siendo muy recomendable. Después de todo, los kits de herramientas de matriz y marco son realmente tan ¡útil! Y si es para aplicaciones front-end, especialmente en escenarios de alta concurrencia, creo que todavía hay que elegir con cuidado. Por supuesto, cambiar a los marcos swoole y workman en PHP supondrá un salto cualitativo. Sin embargo, a juzgar por el empleo actual mercado, es mejor dominar más habilidades. Sí, después de todo, ahora hay espacio para aumentar el salario PHP.

Preparación

herramienta de prueba de presión ab

Ir:

• Versión: 1.19.4
• Marco: Ninguno
• Si se debe utilizar el grupo de conexiones Mysql: Sí, el número máximo de conexiones es 100 Código relacionado
• Registro: Sí, use seelog

PHP:

• Versión: 8.1.15
• Marco: Yii2 2.0.47
• Caché: habilitar opcache, configuración jit
• FastFpm: modo dinámico, número máximo de procesos: 64 (la memoria ya es de 150 MB, mientras que Go tiene solo 2 MB, nuestro k8 aquí está configurado con 1 núcleo y 2 g)
• Registro: Sí, usando Yii Logger

La configuración de PHP opcache es la siguiente (el código no se actualiza, lo que obliga al almacenamiento en caché)

[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=192
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000

# 组合使用, 若为 1 则在 revalidate_freq 时间内刷新代码
opcache.validate_timestamps=0
# opcache.revalidate_freq=60

; jit配置
opcache.jit=true
opcache.jit_buffer_size=64M 

pm = dynamic
pm.max_children = 64
pm.start_servers = 32
pm.min_spare_servers = 16
pm.max_spare_servers = 64

Programa de prueba

• En las condiciones de QPS 20, 50, 100 y 200, realice una prueba de estrés de los programas correspondientes respectivamente para ver el tiempo correspondiente y el valor cuantil;
• Comparación de memoria, rendirse (no comparable)

Resultados de la prueba

El número total es: 1000

SWC	IR	PHP	Observación
20	QPS: 798,01 PROMEDIO: 25,062 ms	QPS: 99,98 PROMEDIO: 200,030 ms	PHP es principalmente más lento que la propia creación de conexiones de DB y el propio lenguaje.
50	QPS: 1593,46 PROMEDIO: 31,378 ms	QPS: 129,75 PROMEDIO: 385,357 ms	Go QPS mejora porque se empiezan a reutilizar conexiones
100	QPS: 1387,81 PROMEDIO: 72,056 ms	QPS: 121,31 PROMEDIO: 824,302 ms	El aumento en el consumo de tiempo promedio se debe a la presión de la base de datos, y PHP también comienza a aumentar la presión de la interfaz debido a la destrucción y creación del proceso FPM (por supuesto, se puede configurar para que sea residente, actualmente 32).
200	QPS: 1355,24 PROMEDIO: 147,575 ms	QPS: 118,41 PROMEDIO: 1689,022 ms	La cantidad de conexiones de bases de datos en GO está llena, por lo que es necesario esperar, por lo que el tiempo de respuesta promedio se vuelve más largo, mientras que PHP tiene un FPM máximo de 64, lo que limita el límite superior de concurrencia.

Las capturas de pantalla relevantes son las siguientes (vaya a la izquierda, PHP a la derecha)

consejos

Comandos relacionados y descripciones de parámetros

# 查询当前 php-fpm 进程数
ps -ef |grep "php-fpm"|grep "pool"|wc -l

# 查询内存占用
free -m

Opcaché PHP

Habilite OpCache y habilite OpCache en modo de línea de comando. Esto se puede lograr configurando los parámetros opcache.enable y opcache.enable_cli en 1 .
Ajuste el consumo de memoria para adaptarlo a la configuración de hardware del servidor. Normalmente, se recomienda configurar opcache.memory_consumption en 128 MB o más.
Se puede aumentar el tamaño del búfer de cadena configurando el parámetro opcache.interned_strings_buffer en 16 MB o más.
Se puede aumentar la cantidad máxima de archivos de script que se pueden acelerar configurando el parámetro opcache.max_accelerated_files en 4000 o superior.
Se puede desactivar la validación de la marca de tiempo estableciendo el parámetro opcache.validate_timestamps en 0.
Establezca el intervalo de tiempo para revalidar archivos en la caché estableciendo el parámetro opcache.revalidate_freq en 60 segundos o más.
Habilite el apagado rápido configurando el parámetro opcache.fast_shutdown en 1.
Permita que los scripts anulen los archivos de caché estableciendo el parámetro opcache.enable_file_override en 1.
Se pueden incluir archivos cuyo almacenamiento en caché está prohibido en la lista negra configurando el parámetro opcache.blacklist_filename. Esto evita agregar archivos al caché que no deberían almacenarse en caché.
Se puede configurar la ruta del archivo de registro de errores configurando el parámetro opcache.error_log. Esto puede ayudarle a identificar y solucionar rápidamente problemas potenciales.

ab descripción del parámetro común

-n：指定总请求数。例如，-n 1000表示发出1000个请求。

-c：指定并发请求数。例如，-c 10表示同时发出10个请求。

-t：指定测试持续时间，单位为秒。例如，-t 60表示测试持续60秒。

-k：启用HTTP KeepAlive功能，即在一次TCP连接中处理多个HTTP请求。默认情况下，ab在每个请求之间关闭连接。

-p：指定包含POST数据的文件。例如，-p postdata.txt表示从postdata.txt文件中读取POST数据。

-H：指定请求头。例如，-H "Accept-Encoding: gzip, deflate"表示在请求头中设置Accept-Encoding字段。

-A：指定HTTP认证信息。例如，-A "username:password"表示使用基本的HTTP认证。

-s：指定测试期间等待服务器响应的最大时间，单位为秒。例如，-s 10表示等待服务器响应的最大时间为10秒。

-v：输出详细的调试信息，包括请求和响应头。

-V：输出版本信息。

Explicación de los resultados devueltos por la herramienta ab.

		Benchmarking www.baidu.com (be patient).....done
		
		
		Server Software:        Apache   // web 服务软件名称
		Server Hostname:        www.baidu.com  // 请求域名
		Server Port:            80 // 请求端口
		
		Document Path:          /a // 请求路径（get 参数可以携带参数）
		Document Length:        199 bytes // 文档字节
		
		Concurrency Level:      20 // 并发数  -c 控制
		Time taken for tests:   1.054 seconds // 任务请求耗时
		Complete requests:      100 // 任务请求完成数量
		Failed requests:        0 // 任务失败请求数量
		Non-2xx responses:      100 // HTTP 码非 200 数量
		Total transferred:      34400 bytes // 相应字符数
		HTML transferred:       19900 bytes // 
		Requests per second:    94.86 [#/sec] (mean) // 平均每秒请求数
		Time per request:       210.841 [ms] (mean) //  批次平均耗时
		Time per request:       10.542 [ms] (mean, across all concurrent requests) // 单个请求的平均耗时 （基本等于 自身 * 并发数， 因为并发其实是 cpu 时间片轮询的）
		Transfer rate:          31.87 [Kbytes/sec] received // 每秒字节数
		
		Connection Times (ms)
		              min  mean[+/-sd] median   max     // 最小 平均 中位数  最大 
		Connect:        8   10   1.1     10      16
		Processing:    11  178  48.1    196     208
		Waiting:       10  115  56.0    114     205
		Total:          21  188  48.2    206     218
		
		Percentage of the requests served within a certain time (ms) // 看分位情况，避免出现极大值
		  50%    206
		  66%    208
		  75%    209
		  80%    213
		  90%    216
		  95%    217
		  98%    217
		  99%    218
		 100%    218 (longest request)