procesos - pthreads php

¿Cómo se manejan las solicitudes concurrentes en PHP(usando-threads, grupo de hilos o procesos secundarios)

Question

Entiendo que PHP admite el manejo de múltiples conexiones simultáneas y, dependiendo del servidor, se puede configurar como se menciona en esta respuesta

¿Cómo gestiona el servidor las conexiones múltiples? ¿Crea un proceso secundario para cada solicitud o maneja el uso de subprocesos o maneja un grupo de subprocesos?

La respuesta vinculada dice que un proceso se bifurca y luego el autor en el comentario dice hilos o proceso, lo que lo hace confuso, si las solicitudes se sirven usando procesos hijo, hilos o grupo de hilos.

Answer 1

Creo que la respuesta depende de cómo se desplieguen el servidor web y el cgi.

En mi empresa, usamos Nginx como servidor web y php-fpm como cgi, por lo que la solicitud simultánea se maneja como proceso por php-fpm, no por subprocesos.

Configuramos el número máximo de procesos, y cada solicitud es manejada por un único proceso de php, si llegan más solicitudes (más grandes que el número máximo de procesos), esperan.

Por lo tanto, creo que PHP en sí mismo puede soportarlos a todos, pero cómo usarlo, eso depende.

Answer 2

Como sé, cada servidor web tiene su propio tipo de manejo simultáneo de solicitudes múltiples. Habitualmente, Apache2 puede bifurcar un proceso secundario para cada nueva solicitud. Pero de alguna manera puede configurar este comportamiento como se menciona en la respuesta de vinculada.

Nginx, por ejemplo, obtiene todas las solicitudes en un hilo (procesa nuevas conexiones asincrónicamente como lo hace Node.js) o a veces utiliza el almacenamiento en caché (como se configuró; Nginx también se puede usar como equilibrador de carga o proxy HTTP). Es una cuestión de elegir el servidor web adecuado para su aplicación.

Apache2 podría ser un servidor web muy bueno, pero necesita más balanceo de carga cuando quiera usarlo en producción. Pero también tiene buena potencia cuando se multiplican conexiones de corta duración o incluso documentos que no cambian en absoluto (o usando el almacenamiento en caché).

Nginx es muy bueno si espera muchas conexiones de larga duración con un tiempo de procesamiento largo. Entonces no necesitas tanto equilibrio de carga.

Espero, pude ayudarte con esto;)

Fuentes:

https://httpd.apache.org/docs/2.4/mod/worker.html

https://anturis.com/blog/nginx-vs-apache/

Te recomiendo que también veas: ¿Qué es un hilo seguro o no seguro para subprocesos en PHP?

Answer 3

Después de investigar un poco, terminé con las siguientes conclusiones.

Es importante tener en cuenta cómo se configuran los servidores PHP para obtener información valiosa. Para configurar el servidor y PHP por su cuenta, podría haber tres posibilidades:

1) Usar PHP como módulo (para muchos servidores PHP tiene una interfaz de módulo directa (también llamada SAPI))

2) CGI

3) FastCGI

Considerando el caso PHP # 1 como módulo, en este caso el módulo está integrado con el servidor web y ahora le da todo al servidor web cómo maneja las solicitudes en términos de proceso de bifurcación, uso de hilos, grupos de hilos, etc.

Para el módulo, apache mod_php parece ser muy utilizado, y el propio Apache maneja las solicitudes usando procesos e hilos en dos modelos como se menciona en esta respuesta

Prefork MPM utiliza múltiples procesos secundarios con un hilo cada uno y cada proceso maneja una conexión a la vez.

Worker MPM usa múltiples procesos hijos con muchos hilos cada uno. Cada hilo maneja una conexión a la vez.

Obviamente, otros servidores pueden tener otros enfoques, pero no estoy al tanto de lo mismo.

Para los n. ° 2 y n. ° 3, el servidor web y la parte de PHP se manejan en diferentes procesos, y la forma en que un servidor web maneja la solicitud y cómo la aplicación (parte de PHP) la procesa más varía. Por ejemplo: NGINX puede manejar la solicitud utilizando E / S asíncrona sin bloqueo y Apache puede manejar solicitudes que usan hilos, pero la forma en que la solicitud será procesada por FastCGI o la aplicación CGI es un aspecto diferente como se describe a continuación. Tanto los aspectos, es decir, cómo maneja el servidor web las solicitudes y cómo se procesa la parte de PHP serían importantes para el rendimiento de los servidores PHP.

Teniendo en cuenta el n. ° 2, el protocolo CGI hace que el servidor web y la aplicación (PHP) sean independientes entre sí, y el protocolo CGI requiere que la aplicación y el servidor web se manejen utilizando un proceso diferente y el protocolo no promueve la reutilización del mismo proceso, lo que a su vez Se requiere un nuevo proceso para manejar cada solicitud.

Considerando el n. ° 3, el protocolo FastCGI supera la limitación de CGI al permitir la reutilización del proceso. Si marca el enlace IIS FastCGI, FastCGI aborda los problemas de rendimiento que son inherentes a CGI al proporcionar un mecanismo para reutilizar un solo proceso una y otra vez para muchas solicitudes.

FastCGI mantiene la compatibilidad con bibliotecas que no son seguras para subprocesos al proporcionar un conjunto de procesos reutilizables y garantizar que cada proceso maneje solo una solicitud a la vez.

Dicho esto, en el caso de FastCGI, parece que el servidor mantiene un grupo de procesos y utiliza el grupo de procesos para gestionar las solicitudes de clientes entrantes y, dado que el grupo de procesos no requiere una verificación segura de subprocesos, proporciona un buen rendimiento.