webserver - que - ¿Algunas preguntas fundamentales pero importantes sobre el desarrollo web?

que es un lenguaje de programacion para web (4)

He desarrollado algunas aplicaciones basadas en web hasta ahora utilizando PHP, Python y Java. Pero algunas preguntas fundamentales pero muy importantes aún están más allá de mi conocimiento, así que hice esta publicación para obtener ayuda y aclaraciones de ustedes.

Digamos que uso algún lenguaje de programación como mi lenguaje de fondo (PHP / Python / .Net / Java, etc.) y despliegue mi aplicación con un servidor web (apache / lighttpd / nginx / IIS, etc.). Y supongamos que en el momento T, una de mi página recibió 100 solicitudes simultáneas de diferentes usuarios. Así que mis preguntas son:

¿Cómo maneja mi servidor web esas 100 solicitudes simultáneas? ¿El servidor web generará un proceso / subproceso para cada solicitud? (En caso afirmativo, ¿proceso o hilo?)
¿Cómo funciona el intérprete del lenguaje backend? ¿Cómo manejará la solicitud y generará el html adecuado? ¿El intérprete generará un proceso / subproceso para cada solicitud? (Si es así, ¿proceso o subproceso?)
Si el intérprete generará un proceso / subproceso para cada solicitud, ¿qué tal estos procesos (subprocesos)? ¿Compartirán algún espacio de código? ¿Se comunicarán entre ellos? ¿Cómo manejar las variables globales en los códigos de backend? ¿O son procesos independientes (hilos)? ¿Cuánto dura la duración del proceso / hilo? ¿Se destruirán cuando se maneje la solicitud y se devuelva la respuesta?
Supongamos que el servidor web solo puede admitir 100 solicitudes simultáneas, pero ahora tiene 1000 solicitudes simultáneas. ¿Cómo maneja tal situación? ¿Los manejará como una cola y manejará la solicitud cuando el servidor esté disponible? U otros enfoques?
Leí algunos artículos sobre Comet en estos días. Y descubrí que una conexión larga puede ser una buena manera de manejar el caso de uso de múltiples usuarios en tiempo real. Entonces, ¿qué hay de la conexión larga? ¿Es una característica de algunos servidores web específicos o está disponible para todos los servidores web? ¿La conexión larga requerirá un proceso de intérprete ya existente?

EDITAR: Recientemente leí algunos artículos sobre CGI y fastcgi, lo que me hace saber que el enfoque de fastcgi debería ser un enfoque típico para la solicitud de hanlde.

el protocolo multiplexa una única conexión de transporte entre varias solicitudes FastCGI independientes. Esto es compatible con aplicaciones que son capaces de procesar solicitudes concurrentes usando técnicas de programación controladas por eventos o con múltiples subprocesos.

Citado de la especificación de fastcgi , que mencionó la conexión que puede manejar varias solicitudes y puede implementarse en tecnología multiprocesador. Me pregunto si esta conexión se puede tratar como un proceso y puede generar varios subprocesos para cada solicitud. Si esto es cierto, me siento más confundido acerca de cómo manejar el recurso compartido en cada hilo.

PS agradece a Thomas por el consejo de dividir la publicación en varias publicaciones, pero creo que las preguntas están relacionadas y es mejor agruparlas.

Agradezca a S.Lott por su excelente respuesta, pero algunas respuestas a cada pregunta son demasiado breves o no están cubiertas en absoluto.

Gracias a la respuesta de todos, lo que me acerca a la verdad.

Para empezar, requerir respuestas detalladas a todos sus puntos es un poco demasiado, en mi humilde opinión.

De todos modos, algunas respuestas breves sobre tus preguntas:

# 1

Depende de la arquitectura del servidor. Apache es un servidor multiproceso y, opcionalmente, también multiproceso. Existe un proceso maestro que escucha en el puerto de la red y administra un grupo de procesos de trabajo (donde, en el caso de los "mpm" de trabajo, cada proceso de trabajo tiene varios subprocesos). Cuando llega una solicitud, se reenvía a uno de los trabajadores inactivos. El maestro administra el tamaño de la agrupación de trabajadores iniciando y terminando trabajadores según la carga y los ajustes de configuración.

Ahora, lighthttpd y nginx son diferentes; son las llamadas arquitecturas basadas en eventos, en las que se multiplexan múltiples conexiones de red en uno o más procesos / subprocesos de trabajo mediante el uso del soporte del sistema operativo para la multiplexación de eventos, como el clásico () / poll () en POSIX, o más escalable pero Desafortunadamente, mecanismos específicos del sistema operativo, como epoll en Linux. La ventaja de esto es que cada conexión de red adicional necesita solo unos pocos cientos de bytes de memoria, lo que permite a estos servidores mantener abiertos decenas de miles de conexiones, lo que generalmente sería prohibitivo para una arquitectura de solicitud por proceso / subproceso como Apache . Sin embargo, estos servidores basados en eventos todavía pueden usar múltiples procesos o subprocesos para utilizar múltiples núcleos de CPU, y también para ejecutar llamadas de sistema de bloqueo en paralelo, como la E / S normal de archivos POSIX.

Para obtener más información, consulte la página de C10k de Dan Kegel .

# 2

Una vez más, depende. Para el CGI clásico, se inicia un nuevo proceso para cada solicitud. Para mod_php o mod_python con apache, el intérprete está integrado en los procesos de apache y, por lo tanto, no es necesario iniciar un nuevo proceso o subproceso. Sin embargo, esto también significa que cada proceso de apache requiere bastante memoria, y en combinación con los problemas que expliqué anteriormente para el número 1, limita la escalabilidad.

Para evitar esto, es posible tener un grupo separado de procesos pesados que ejecuten los intérpretes, y los servidores web front-end para los backends cuando se necesita generar contenido dinámico. Este es esencialmente el enfoque adoptado por FastCGI y mod_wsgi (aunque utilizan protocolos personalizados y no HTTP, por lo que, técnicamente, no es un proxy). Este también suele ser el enfoque elegido cuando se utilizan los servidores basados en eventos, ya que el código para generar el contenido dinámico rara vez vuelve a entrar, lo que tendría que ser para funcionar correctamente en un entorno basado en eventos. Lo mismo ocurre con los enfoques de subprocesos múltiples también si el código de contenido dinámico no es seguro para subprocesos; uno puede tener, digamos, el servidor de apache frontend con el mpm de trabajador de subprocesos para servidores de apache de back-end ejecutando código PHP con el prefork mpm de subproceso único.

# 3

Según el nivel al que preguntes, compartirán algo de memoria a través del mecanismo de almacenamiento en caché del sistema operativo, sí. Pero en general, desde la perspectiva del programador, son independientes. Tenga en cuenta que esta independencia no es per se una cosa mala, ya que permite el escalado horizontal directo a múltiples máquinas. Pero, ay, a veces es necesaria cierta cantidad de comunicación. Un enfoque simple es comunicarse a través de la base de datos, asumiendo que uno es necesario por otras razones, como suele ser. Otro enfoque es utilizar algún sistema dedicado de almacenamiento en caché de memoria distribuida, como memcached .

# 4

Depende. Pueden estar en cola, o el servidor puede responder con algún código de error adecuado, como HTTP 503, o el servidor puede simplemente rechazar la conexión en primer lugar. Por lo general, todo lo anterior puede ocurrir según la carga del servidor.

# 5

La viabilidad de este enfoque depende de la arquitectura del servidor (vea mi respuesta al # 1). Para un servidor basado en eventos, mantener las conexiones abiertas no es un gran problema, pero para apache ciertamente se debe a la gran cantidad de memoria requerida para cada conexión. Y sí, esto ciertamente requiere un proceso de interpretación de larga duración, pero como se describió anteriormente, a excepción del CGI clásico, esto está bastante garantizado.

~~Los servidores web son entornos multihilo~~ ; Además de utilizar variables de ámbito de aplicación, una solicitud de usuario no interactúa con otros subprocesos.

Asi que:

Sí, se creará un nuevo hilo para cada usuario.
Sí, se procesará HTML para cada solicitud.
Tendrá que utilizar variables de ámbito de aplicación
Si recibe más solicitudes de las que puede atender, se pondrán en cola. Si fueron atendidos antes del tiempo de espera configurado, el usuario recibirá su respuesta o un error de "servidor ocupado".
Comet no es específico para ningún servidor / idioma. Puede lograr el mismo resultado preguntando a su servidor cada n segundos, sin tener que lidiar con otros problemas de subprocesos desagradables.

¿Cómo maneja mi servidor web esas 100 solicitudes simultáneas? ¿El servidor web genera un proceso / hilo para cada solicitud? (En caso afirmativo, ¿proceso o hilo?)

Varía. Apache tiene tanto hilos como procesos para manejar solicitudes. Apache inicia varios procesos concurrentes, cada uno de los cuales puede ejecutar cualquier cantidad de subprocesos simultáneos. Debe configurar Apache para controlar cómo esto se reproduce realmente para cada solicitud.

¿Cómo funciona el intérprete del lenguaje backend? ¿Cómo manejará la solicitud y generará el html adecuado? ¿El intérprete generará un proceso / subproceso para cada solicitud? (Si es así, ¿proceso o subproceso?)

Esto varía con su configuración de Apache y su idioma. Para Python, un enfoque típico es tener procesos de daemon ejecutándose en segundo plano. Cada proceso de Apache posee un proceso de daemon. Esto se hace con el módulo mod_wsgi. Se puede configurar para trabajar de varias maneras diferentes.

Si el intérprete generará un proceso / subproceso para cada solicitud, ¿qué tal estos procesos (subprocesos)? ¿Compartirán algún espacio de código? ¿Se comunicarán entre ellos? ¿Cómo manejar las variables globales en los códigos de backend? ¿O son procesos independientes (hilos)? ¿Cuánto dura la duración del proceso / hilo? ¿Se destruirán cuando se maneje la solicitud y se devuelva la respuesta?

Los hilos comparten el mismo código. Por definición.

Los procesos compartirán el mismo código porque así es como funciona Apache.

No se comunican intencionalmente entre sí. Su código no tiene una manera de determinar fácilmente qué está pasando. Esto es por diseño. No puede saber en qué proceso se está ejecutando y no puede saber qué otros subprocesos se están ejecutando en este espacio de proceso.

Los procesos son de larga ejecución. Ellos no (y no deben) ser creados dinámicamente. Configura a Apache para que bifurque varias copias simultáneas de sí mismo cuando comienza a evitar la sobrecarga de la creación del proceso.

La creación de hilos tiene mucho menos sobrecarga. Cómo los apaches manejan los hilos internamente no importa mucho. Sin embargo, puede pensar en Apache como un inicio de un hilo por solicitud.

Supongamos que el servidor web solo puede admitir 100 solicitudes simultáneas, pero ahora tiene 1000 solicitudes simultáneas. ¿Cómo maneja tal situación? ¿Los manejará como una cola y manejará la solicitud cuando el servidor esté disponible? U otros enfoques?

Esta es la pregunta de "escalabilidad". En resumen, ¿cómo se degradará el rendimiento a medida que aumenta la carga? La respuesta general es que el servidor se vuelve más lento. Para algunos niveles de carga (digamos 100 solicitudes concurrentes) hay suficientes procesos disponibles para que todos se ejecuten rápidamente. En algún nivel de carga (por ejemplo, 101 solicitudes concurrentes) comienza a ser más lento. En algún otro nivel de carga (quién sabe cuántas solicitudes) se vuelve tan lento que no está satisfecho con la velocidad.

Hay una cola interna (como parte de la forma en que funciona TCP / IP, en general) pero no hay un gobernador que limite la carga de trabajo a 100 solicitudes simultáneas. Si obtiene más solicitudes, se crean más subprocesos (no más procesos) y las cosas se ejecutan más lentamente.

Actualización, primavera 2018 :

Escribí esta respuesta en 2010 y, desde entonces, muchas cosas han cambiado en el mundo de un desarrollador web. En concreto, la llegada de los servicios de conversión en "nube", como los balanceadores de carga con un solo clic y la autoescala en productos básicos, ha facilitado mucho más la mecánica real de escalar su aplicación.

Dicho esto, lo que escribí en este artículo en 2010 sigue siendo cierto en su mayoría hoy en día, y entender los mecanismos detrás de cómo funcionan realmente el servidor web y el entorno de alojamiento de idiomas y cómo ajustarlos puede ahorrarle una cantidad considerable de dinero en costos de alojamiento. Por esa razón, he dejado el artículo como se escribió originalmente a continuación para cualquier persona que esté comenzando a adentrarse en sus codos.

1. Depende del servidor web (y en ocasiones de la configuración de los mismos). Una descripción de varios modelos:

Apache con mpm_prefork (predeterminado en unix): Proceso por solicitud. Para minimizar el tiempo de inicio, Apache mantiene un grupo de procesos inactivos a la espera de manejar nuevas solicitudes (que configura el tamaño). Cuando llega una nueva solicitud, el proceso maestro lo delega a un trabajador disponible, de lo contrario genera una nueva. Si se reciben 100 solicitudes, a menos que tenga 100 trabajadores inactivos, será necesario realizar un cierto bifurcación para manejar la carga. Si el número de procesos inactivos excede el valor MaxSpare, algunos se cosecharán después de finalizar las solicitudes hasta que haya solo tantos procesos inactivos.
Apache con mpm_event, mpm_worker, mpm_winnt: Hilo por solicitud. Del mismo modo, apache mantiene un grupo de subprocesos inactivos en la mayoría de las situaciones, también configurables. (Un pequeño detalle, pero funcionalmente el mismo: mpm_worker ejecuta varios procesos, cada uno de los cuales es multihebra).
Nginx / Lighttpd: estos son servidores ligeros basados en eventos que utilizan select () / epoll () / poll () para multiplexar una cantidad de sockets sin necesidad de múltiples procesos o subprocesos. Mediante una codificación y un uso muy cuidadosos de las API no bloqueantes, pueden escalar a miles de solicitudes simultáneas en el hardware de los productos, siempre que el ancho de banda esté disponible y los límites de descriptores de archivos estén configurados correctamente. La advertencia es que la implementación de lenguajes de script integrados tradicionales es casi imposible dentro del contexto del servidor, esto anularía la mayoría de los beneficios. Ambos admiten FastCGI, sin embargo, para lenguajes de scripting externos.

2. Depende del idioma, o en algunos idiomas, en qué modelo de implementación utiliza. Algunas configuraciones de servidor solo permiten ciertos modelos de implementación.

Apache mod_php, mod_perl, mod_python: estos módulos ejecutan un intérprete separado para cada trabajador de apache. La mayoría de estos no pueden funcionar muy bien con mpm_worker (debido a varios problemas con la seguridad de subprocesos en el código del cliente), por lo que se limitan principalmente a los modelos de bifurcación. Eso significa que para cada proceso de apache, tiene un intérprete php / perl / python ejecutándose en su interior. Esto incrementa considerablemente la huella de la memoria: si un trabajador de Apache dado normalmente toma alrededor de 4 MB de memoria en su sistema, uno con PHP puede tomar 15 MB y uno con Python puede tomar 20-40 MB para una aplicación promedio. Parte de esto será la memoria compartida entre procesos, pero en general, estos modelos son muy difíciles de escalar muy grandes.
Apache (configuraciones compatibles), Lighttpd, CGI: este es principalmente un método de alojamiento que se apaga. El problema con CGI es que no solo crea un nuevo proceso para manejar solicitudes, sino que lo hace para cada solicitud, no solo cuando necesita aumentar la carga. Dado que los idiomas dinámicos de hoy tienen un tiempo de inicio bastante grande, esto no solo crea mucho trabajo para su servidor web, sino que también aumenta significativamente el tiempo de carga de la página. Una pequeña secuencia de comandos de Perl podría funcionar como CGI, pero una aplicación grande de python, ruby o java es bastante difícil de manejar. En el caso de Java, es posible que esté esperando un segundo o más solo para el inicio de la aplicación, solo para tener que hacerlo todo de nuevo en la siguiente solicitud.
Todos los servidores web, FastCGI / SCGI / AJP: este es el modelo de alojamiento ''externo'' para ejecutar lenguajes dinámicos. Hay una lista completa de variaciones interesantes, pero lo esencial es que su aplicación escucha en algún tipo de socket, y el servidor web maneja una solicitud HTTP, luego la envía a través de otro protocolo al socket, solo para páginas dinámicas (las páginas estáticas son generalmente manejado directamente por el servidor web).
Esto le confiere muchas ventajas, ya que necesitará menos trabajadores dinámicos de los que necesita para manejar conexiones. Si por cada 100 solicitudes, la mitad corresponde a archivos estáticos como imágenes, CSS, etc. y, además, si la mayoría de las solicitudes dinámicas son cortas, es posible que con 20 trabajadores dinámicos manejando 100 clientes simultáneos. Es decir, dado que el uso normal de una conexión de mantenimiento del servidor web dado es 80% inactivo, sus intérpretes dinámicos pueden manejar las solicitudes de otros clientes. Esto es mucho mejor que el enfoque mod_php / python / perl, donde cuando su usuario está cargando un archivo CSS o no está cargando nada, su intérprete se sienta allí usando la memoria y sin hacer ningún trabajo.
Apache mod_wsgi: esto se aplica específicamente al alojamiento de Python, pero toma algunas de las ventajas de las aplicaciones alojadas en servidores web (configuración fácil) y el alojamiento externo (multiplexación de procesos). Cuando lo ejecuta en modo daemon, mod_wsgi solo delega solicitudes a sus trabajadores de daemon cuando es necesario, y por lo tanto, 4 daemons pueden ser capaces de manejar 100 usuarios simultáneos (depende de su sitio y su carga de trabajo)
Phusion Passenger: Passenger es un sistema de alojamiento de apache que se utiliza principalmente para alojar aplicaciones ruby, y al igual que mod_wsgi ofrece ventajas tanto de alojamiento externo como de servidor web.

3. Una vez más, dividiré la pregunta según los modelos de alojamiento para los casos en que sea aplicable.

mod_php, mod_python, mod_perl: en general, solo las bibliotecas de C de su aplicación se compartirán entre los usuarios de apache. Esto se debe a que apache primero se bifurca y luego carga su código dinámico (que, debido a las sutilezas, en su mayoría no puede usar páginas compartidas). Los intérpretes no se comunican entre sí dentro de este modelo. Generalmente no se comparten variables globales. En el caso de mod_python, puede hacer que los globales permanezcan entre las solicitudes dentro de un proceso, pero no entre los procesos. Esto puede llevar a algunos comportamientos muy extraños (los navegadores rara vez mantienen la misma conexión para siempre, y la mayoría abren varios a un sitio web determinado), así que ten mucho cuidado con la forma en que usas los globales. Use algo como memcached o una base de datos o archivos para cosas como almacenamiento de sesión y otros bits de caché que deben compartirse.
FastCGI / SCGI / AJP / Proxied HTTP: Debido a que su aplicación es esencialmente un servidor en sí mismo, esto depende del idioma en el que está escrito el servidor (generalmente el mismo idioma que su código, pero no siempre) y varios factores. Por ejemplo, la mayoría de la implementación de Java usa un subproceso por solicitud. Python y su biblioteca FastCGI de "flup" pueden ejecutarse en modo prefork o en subproceso, pero como Python y su GIL son limitantes, es probable que obtenga el mejor rendimiento de prefork.
mod_wsgi / passenger: mod_wsgi en modo servidor puede configurarse de la manera en que maneja las cosas, pero le recomendaría que le asigne un número fijo de procesos. Desea mantener su código de Python en la memoria, girar y listo para funcionar. Este es el mejor enfoque para mantener la latencia predecible y baja.

En casi todos los modelos mencionados anteriormente, la vida útil de un proceso / subproceso es más larga que una sola solicitud. La mayoría de las configuraciones siguen una cierta variación en el modelo de apache: mantenga a algunos trabajadores de repuesto a su alrededor, genere más cuando sea necesario, coseche cuando haya demasiados, en función de unos pocos límites configurables. La mayoría de estas configuraciones no destruyen un proceso después de una solicitud, aunque algunas pueden borrar el código de la aplicación (como en el caso de PHP fastcgi).

4. Si dice "el servidor web solo puede manejar 100 solicitudes" depende de si se refiere al servidor web real en sí mismo o a la parte dinámica del servidor web. También hay una diferencia entre los límites reales y funcionales.

En el caso de Apache, por ejemplo, configurará un número máximo de trabajadores (conexiones). Si esta cantidad de conexiones era 100 y se alcanzó, apache no aceptará más conexiones hasta que alguien se desconecte. Con keep-alive habilitado, esas 100 conexiones pueden permanecer abiertas durante mucho tiempo, mucho más tiempo que una sola solicitud, y esas otras 900 personas que esperan en las solicitudes probablemente caducarán.

Si tiene límites lo suficientemente altos, puede aceptar a todos esos usuarios. Sin embargo, incluso con el apache más liviano, el costo es de aproximadamente 2-3 mb por trabajador, por lo que solo con apache puede estar hablando de 3 gb + de memoria solo para manejar las conexiones, por no mencionar otros recursos posiblemente limitados del sistema operativo, como identificadores de procesos, descriptores de archivos, y buffers, y esto es antes de considerar el código de su aplicación.

Para lighttpd / Nginx, pueden manejar un gran número de conexiones (miles) en una pequeña huella de memoria, a menudo solo unos pocos megas por cada mil conexiones (depende de factores como los búferes y cómo se configuran las apis de IO asíncronas). Si asumimos que la mayoría de sus conexiones están activas y el 80% (o más) inactivas, esto es muy bueno, ya que no está perdiendo el tiempo de proceso dinámico o mucha memoria.

En cualquier modelo externo alojado (mod_wsgi / fastcgi / ajp / proxied http), digamos que solo tiene 10 trabajadores y 1000 usuarios hacen una solicitud, su servidor web hará una cola de las solicitudes a sus trabajadores dinámicos. Esto es ideal: si sus solicitudes se devuelven rápidamente, puede seguir manejando una carga de usuarios mucho mayor sin necesidad de más trabajadores. Por lo general, la prima es la memoria o las conexiones de base de datos, y al hacer cola puede servir a muchos más usuarios con los mismos recursos, en lugar de negar a algunos usuarios.

Tenga cuidado: diga que tiene una página que genera un informe o realiza una búsqueda y tarda varios segundos, y muchos usuarios atan a los trabajadores con esto: alguien que quiera cargar su página de inicio puede ponerse en cola durante unos segundos mientras todos solicitudes de larga duración completas. Las alternativas son usar un grupo separado de trabajadores para manejar las direcciones URL de la sección de la aplicación de informes o hacer informes por separado (como en un trabajo en segundo plano) y luego sondear su finalización más tarde. Hay muchas opciones allí, pero es necesario que reflexione sobre su aplicación.

5. La mayoría de las personas que usan apache y necesitan manejar muchos usuarios simultáneos, por razones de gran huella de memoria, desactiva el mantenimiento. O Apache con keep-alive activado, con un límite de tiempo de keep-alive corto, digamos 10 segundos (para que pueda obtener su página principal e imágenes / CSS en una sola carga de página). Si realmente necesitas escalar a 1000 conexiones o más y quieres mantenerte vivo, querrás ver Nginx / lighttpd y otros servidores ligeros basados en eventos.

Es posible que tenga en cuenta que si desea apache (por la facilidad de uso de la configuración, o si necesita alojar ciertas configuraciones), puede poner Nginx delante de apache, utilizando el proxy HTTP. Esto permitirá que Nginx maneje conexiones de mantenimiento (y, preferiblemente, archivos estáticos) y apache para manejar solo el trabajo duro. Nginx también resulta ser mejor que apache al escribir archivos de registro, de manera interesante. Para un despliegue de producción, estamos muy contentos con nginx delante de apache (con mod_wsgi en esta instancia). Apache no realiza ningún registro de acceso, ni maneja archivos estáticos, lo que nos permite deshabilitar una gran cantidad de módulos dentro de apache para mantenerlo en un tamaño reducido.

La mayoría de las veces ya he respondido a esto, pero no, si tiene una conexión larga, no tiene por qué afectar el tiempo de ejecución del intérprete (siempre que esté utilizando una aplicación externa alojada, lo que debería estar claro hasta ahora) vastamente superior). Entonces, si quieres usar un cometa, y una larga vida de mantenimiento (lo que generalmente es bueno, si puedes manejarlo) considera el nginx.

Pregunta de FastCGI de bonificación Usted menciona que fastcgi puede multiplexarse dentro de una sola conexión. Esto está respaldado por el protocolo (creo que el concepto se conoce como "canales"), de modo que en teoría un solo socket puede manejar muchas conexiones. Sin embargo, no es una característica requerida de los implementadores de fastcgi, y en realidad no creo que haya un solo servidor que use esto. La mayoría de los respondedores de fastcgi tampoco usan esta característica, porque implementar esto es muy difícil. La mayoría de los servidores web solo realizarán una solicitud a través de un determinado socket fastcgi a la vez, y luego realizarán la siguiente solicitud a través de ese socket. Por lo tanto, a menudo solo tiene un socket fastcgi por proceso / hilo.

Depende de usted si su aplicación fastcgi usa procesamiento o subprocesos (y si lo implementa a través de un proceso "maestro" que acepta conexiones y delegaciones o simplemente muchos procesos que hacen sus propias cosas); y varía según las capacidades de su lenguaje de programación y sistema operativo también. En la mayoría de los casos, cualquiera que sea el valor predeterminado que utilice la biblioteca debería estar bien, pero prepárese para realizar algunas evaluaciones y ajustes de parámetros.

En cuanto al estado compartido, le recomiendo que pretenda que no existen usos tradicionales del estado compartido en proceso: incluso si pueden funcionar ahora, es posible que tenga que dividir sus trabajadores dinámicos en varias máquinas más adelante. Para el estado como carritos de compras, etc; La base de datos puede ser la mejor opción, la información de inicio de sesión se puede mantener en Secececookies, y para el estado temporal algo parecido a memcached es bastante bueno. Cuanto menos dependa de las características que comparten datos (el enfoque de "nada compartido"), mayor será la escala en el futuro.

Postscript : He escrito e implementado una gran cantidad de aplicaciones dinámicas en el ámbito de las configuraciones anteriores: todos los servidores web mencionados anteriormente, y todo lo que se encuentra en el rango de PHP / Python / Ruby / Java. He probado ampliamente (utilizando tanto la evaluación comparativa como la observación en el mundo real) los métodos, y los resultados a veces son sorprendentes: menos es a menudo más. Una vez que se haya alejado del alojamiento de su código en el proceso del servidor web, a menudo puede salirse con un número muy pequeño de trabajadores de FastCGI / Mongrel / mod_wsgi / etc. Depende de cuánto tiempo permanezca su aplicación en la base de datos, pero es muy frecuente que más procesos que el número de CPU de 2 * en realidad no le ganen nada.