¿Cómo funciona FastCGI en un servidor web (por ejemplo, Apache 2.2+)?

Question

He echado un vistazo a las fuentes de FastCGI (fcgi-2.4.0) y en realidad no hay señales de fork. Si estoy en lo correcto, el servidor web spwans un proceso para el módulo FastCGI (compilado en él o cargado como SO/DLL) y maneja el control del socket principal (el puerto TCP: 80 por lo general) a él.

En * nix el módulo FastCGI "bloquea" ese socket utilizando un bloqueo de escritura de archivo (libfcgi/os_unix.c: 989) en todo el descriptor de archivo (el socket de escucha de hecho); De esta forma, cuando las nuevas conexiones generan ingresos, solo el módulo FastCGI puede procesarlas. El bloqueo del socket entrante se libera justo antes de entregarlo al procesamiento HTTP req.

Como se ve como módulo FastCGI no es de múltiples proceso/hilo (sin uso interno de tenedor/pthread_create) Asumo se obtiene el manejo simultáneo de varias conexiones simultáneas a través de desove de desde el servidor web (a través de OS_SpawnChild) de n FastCGI procesos de módulo. Si engendramos, por ejemplo, 3 procesos FastCGI (Apache llama a 3 x OS_SpawnChild), ¿significa eso que solo podríamos tener un máximo de 3 solicitudes atendidas simultáneamente?

A) ¿Es correcta mi visión de la manera de trabajar de FastCGI?

B) Si el costo para el sistema operativo para generar un nuevo proceso/crear una conexión a base de datos local podría considerarse insignificante, ¿cuáles son las ventajas de FastCGI en contra de un enfoque ejecutable pasada de moda ?

Gracias, Ema! :-)

Answer 1

Los procesos FastCGI engendrados son persistentes, no se eliminan una vez que se maneja la solicitud, sino que se "agrupan".

Answer 2

La ganancia de velocidad de FastCGI sobre CGI normal es que los procesos son persistentes. p.ej. si tiene manejadores de bases de datos para abrir, puede hacerlos una vez. Lo mismo para cualquier almacenamiento en caché.

La ganancia principal proviene de no tener que crear un nuevo php/perl/etc. intérprete cada vez, lo que lleva una cantidad sorprendente de tiempo.

Si desea tener múltiples conexiones concurrentes manejadas, tiene que tener múltiples procesos Procesos FastCGI en ejecución. FastCGI no es una forma de manejar más conexiones a través de ningún tipo de concurrencia especial. Es una forma de acelerar las solicitudes individuales, lo que a su vez permitirá gestionar más solicitudes. Pero sí tiene razón, más solicitudes simultáneas requieren más procesos en ejecución.

Answer 3

De hecho,

así como se ve (A) está bien, ahora ¿qué pasa con (B)? Si hablo de ejecutables (programas C/C++ compilados correctamente, no scripts como perl/php/...), y si consideramos que el costo del proceso spwan y la nueva conexión cuestan insignificantes, entonces este enfoque (FastCGI) es sólo un tipo de pequeña ganancia en comparación con los ejecutables CGI simples?

Quiero decir, dado que Linux es muy rápido en el desove (bifurcación) de un proceso y si el DB se ejecuta localmente (por ejemplo, el mismo host MySQL), el tiempo necesario para iniciar un nuevo ejecutable y conectarse al DB es prácticamente 0. En este caso, sin nada que interpretar, solo los módulos Apache C/C++ serían más rápidos que esto.

Usando el enfoque FastCGI entonces usted es aún más vulnerable a las fugas de mem ya que el proceso no se bifurca/reinicia cada vez ...En este punto, si tiene que desarrollar su CGI en C/C++, ¿no sería mejor utilizar old school CGI y/o módulos Apache C/C++ directamente?

Una vez más, no estoy hablando de scripts (perl/php/...), estoy hablando de compilar CGI.

Gracias de nuevo, Cheers, Ema! :-)

Answer 4

B, sí. SI el costo del desove es cero, el CGI heredado sería bastante bueno. Entonces, si no tienes muchos hits, el simple CGI está bien, corre con él. El objetivo de cgi rápido es hacer cosas que se beneficien de una gran cantidad de almacenamiento persistente, o estructuras que deben construirse ANTES de realizar su trabajo, como ejecutar consultas en bases de datos grandes, donde desea dejar las bibliotecas de DB en memoria en su lugar de tener que volver a cargar todo el shebang cada vez que desee ejecutar una consulta.

Importa cuando tienes MUCHOS GOLPES.