Algunas preguntas fundamentales pero importantes sobre el desarrollo web?

Actualización, Primavera 2018:

Escribí esta respuesta en 2010 y desde entonces, muchas cosas han cambiado en el mundo de un desarrollador de backend web. Es decir, la llegada de la "nube" convirtiendo servicios como balanceadores de carga de un solo clic y escalado automático en productos básicos han hecho que la mecánica real de escalar su aplicación sea mucho más fácil de comenzar.

Dicho esto, lo que escribí en este artículo en 2010 todavía se mantiene hoy en día, y la comprensión de la mecánica detrás de cómo funciona realmente su servidor web y el entorno de alojamiento de idiomas y cómo ajustarlo puede ahorrarle cantidades considerables 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á empezando a conseguir codos profundos en la sintonización de su pila.

1. Depende del servidor web (y a veces de su configuración). Una descripción de varios modelos:

• Apache con mpm_prefork (por defecto en unix): Proceso por solicitud. Para minimizar el tiempo de inicio, Apache mantiene un grupo de procesos inactivos esperando para manejar nuevas solicitudes (cuyo tamaño se configura). Cuando llega una nueva solicitud, el proceso maestro la delega en un worker disponible, de lo contrario genera uno nuevo. Si llegaran 100 solicitudes, a menos que tuviera 100 trabajadores inactivos, se necesitaría hacer alguna 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 solo haya muchos procesos inactivos.

• Apache con mpm_event, mpm_worker, mpm_winnt: Hilo por petición. 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 multi-threaded).

• Nginx / Lighttpd: Estos son servidores ligeros basados en eventos que utilizan select()/epoll () / poll () para multiplexar un número de sockets sin necesidad de múltiples hilos o procesa. A través de una codificación muy cuidadosa y el uso de API sin bloqueo, pueden escalar a miles de solicitudes simultáneas en hardware de productos básicos, con ancho de banda disponible y límites de descriptores de archivos correctamente configurados. La advertencia es que la implementación de lenguajes de scripting integrados tradicionales es casi imposible dentro del contexto del servidor, esto negaría la mayoría de los beneficios. Ambos soportan FastCGI sin embargo para lenguajes de scripting externos.

2. Depende de la idioma, o en algunos idiomas, en qué modelo de implementación se 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 threadsafety 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 corriendo dentro. Esto aumenta severamente la huella de memoria: si un trabajador de apache dado normalmente tomaría alrededor de 4MB de memoria en su sistema, uno con PHP puede tomar 15mb y uno con Python puede tomar 20-40MB para una aplicación promedio. Parte de esto será memoria compartida entre procesos, pero en general, estos modelos son muy difíciles de escalar a gran escala.

• Apache (configuraciones soportadas), Lighttpd, CGI: Este es en su mayoría un método de alojamiento que se extingue. El problema con CGI es que no solo bifurca un nuevo proceso para el manejo de solicitudes, lo hace para cada solicitud, no solo cuando necesita aumentar la carga. Con los lenguajes dinámicos de hoy en día teniendo un tiempo de inicio bastante grande, esto no solo crea mucho trabajo para su servidor web, sino que aumenta significativamente el tiempo de carga de la página. Un pequeño script de perl podría estar bien para ejecutarse como CGI, pero una gran aplicación 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, sólo 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 la esencia 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 generalmente son manejadas directamente por el servidor web).

  Esto le confiere muchas ventajas, porque necesitará menos trabajadores dinámicos que la capacidad de manejar conexiones. Si por cada 100 solicitudes, la mitad son para archivos estáticos como imágenes, CSS, etc., y además si la mayoría de las solicitudes dinámicas son cortas, podría arreglárselas con 20 trabajadores dinámicos que manejan 100 clientes simultáneos. Es decir, dado que el uso normal de una conexión keep-alive de un servidor web dado es 80% inactivo, sus intérpretes dinámicos pueden manejar solicitudes de otros clientes. Este es mucho mejor que el enfoque mod_php/python/perl, donde cuando su usuario está cargando un archivo CSS o no está cargando nada en absoluto, su intérprete se sienta allí usando memoria y no haciendo 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 (fácil configuración) y el alojamiento externo (multiplexación de procesos). Cuando se ejecuta en modo demonio, mod_wsgi solo delega las solicitudes a los trabajadores de demonio cuando necesario, y por lo tanto 4 demonios podrían 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 apache que es principalmente para alojar aplicaciones ruby, y al igual que mod_wsgi proporciona ventajas de alojamiento externo y administrado por un servidor web.

3. Nuevamente, dividiré la pregunta en función de los modelos de alojamiento para donde esto sea aplicable.

• Mod_php, mod_python, mod_perl: Solo las bibliotecas C de su aplicación generalmente se compartirán entre los trabajadores de apache. Esto se debe a que apache se bifurca primero, luego carga su código dinámico (que debido a sutilezas, en su mayoría no es capaz de 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 las globales permanezcan entre solicitudes dentro de un proceso, pero no entre 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 tenga mucho cuidado con la forma en que usa los globales. Use algo como memcached o una base de datos o archivos para cosas como el almacenamiento de sesiones 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 las implementaciones de Java utilizan un subproceso por solicitud. Python y su biblioteca FastCGI" flup " pueden ejecutarse en modo prefork o threaded, pero dado que Python y su GIL son limitantes, es probable que obtenga el mejor rendimiento de prefork.

• Mod_wsgi / passenger: mod_wsgi en modo servidor se puede configurar cómo maneja las cosas, pero te recomiendo que le des un fijo número de procesos. Quieres mantener tu código python en memoria, spun up y listo para ir. 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/hilo es más larga que una sola solicitud. La mayoría de las configuraciones siguen alguna variación en el modelo apache: Mantener algunos trabajadores de repuesto alrededor, generar más cuando sea necesario, cosechar cuando hay demasiados, basado en unos pocos límites configurables. La mayoría de estas configuraciones-no - destruyen un proceso después de una solicitud, aunque algunos pueden borrar la aplicación código (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 en sí 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, se configurará un número máximo de trabajadores (conexiones). Si este número de conexiones fue 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 que una sola solicitud, y las otras 900 personas que esperan solicitudes probablemente se agotarán.

Si tiene límites lo suficientemente altos, puede aceptar todos esos usuarios. Sin embargo, incluso con el apache más ligero, el costo es de aproximadamente 2-3 mb por trabajador, por lo que solo con apache podría estar hablando de 3 gb+ de memoria solo para manejar las conexiones, por no mencionar otros posiblemente limitados Recursos del sistema operativo como identificadores de proceso, descriptores de archivo y búferes, y esto 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 mil conexiones (depende de factores como los búferes y cómo se configuran las api de IO async). Si asumimos que la mayoría de sus conexiones se mantienen vivas y el 80% (o más) están inactivas, esto es muy bueno, ya que no está desperdiciando el proceso dinámico tiempo o mucha memoria.

En cualquier modelo externo alojado (mod_wsgi/fastcgi/ajp/proxied http), digamos que solo tiene 10 workers y 1000 usuarios hacen una solicitud, su servidor web pondrá en cola las solicitudes a sus dynamic workers. Esto es ideal: si sus solicitudes regresan rápidamente, puede seguir manejando una carga de usuario 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 algunos usuarios.

Tenga cuidado: digamos que tiene una página que construye un informe o hace una búsqueda y toma varios segundos, y muchos usuarios atan a los trabajadores con esto: alguien que quiera cargar su página principal puede estar en cola durante unos segundos mientras se completan todas esas solicitudes de larga duración. Las alternativas son usar un grupo separado de trabajadores para manejar las URL a la sección de la aplicación de informes, o hacer informes por separado (como en un trabajo en segundo plano) y luego encuestar su finalización más tarde. Un montón de opciones allí, pero requieren que usted ponga un poco de pensamiento en su aplicación.

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

Se puede notar que si desea apache (para facilitar la configuración de uso, o necesita alojar ciertas configuraciones) puede poner Nginx delante de apache, usando proxy HTTP. Esto permitirá que Nginx maneje conexiones mantenidas vivas (y, preferiblemente, archivos estáticos) y apache maneje solo el trabajo grunt. Nginx también resulta ser mejor que apache en la escritura de archivos de registro, curiosamente. Para un despliegue de producción, hemos sido muy felices con nginx delante de apache (con mod_wsgi en este caso). El apache no hace ningún registro de acceso, ni maneja archivos estáticos, lo que nos permite deshabilitar un gran número de módulos dentro de apache para mantenerlo pequeño.

En su mayoría ya he respondido a esto, pero no, si tiene una conexión larga no tiene que tener ninguna relación con el tiempo que se ejecuta el intérprete (siempre y cuando esté utilizando una aplicación alojada externa, que por ahora debería estar claro es muy superior). Así que si usted quiere utilizar comet, y un largo keep-alive (que es generalmente una buena cosa, si usted puede manejarlo) considere el nginx.

Bonus FastCGI Question Mencionas que fastcgi puede multiplexar dentro de una sola conexión. Esto es apoyado por el protocolo de hecho (creo que el concepto se conoce como" canales"), por lo que en teoría un solo zócalo puede manejar un montón de conexiones. Sin embargo, no es una característica requerida de los implementadores fastcgi, y en realidad no creo que haya un servidor único que usa esto. La mayoría de los respondedores de fastcgi tampoco usan esta característica, porque implementarla es muy difícil. La mayoría de los servidores web solo harán una solicitud a través de un socket fastcgi dado a la vez, y luego harán la siguiente a través de ese socket. Por lo tanto, a menudo solo tiene un socket fastcgi por proceso/hilo.

Si su aplicación fastcgi utiliza procesamiento o subproceso (y si lo implementa a través de un proceso "maestro" que acepta conexiones y delega o simplemente un montón de procesos cada uno haciendo su propia cosa) depende de usted; y varía en función de las capacidades de su lenguaje de programación y el sistema operativo también. En la mayoría de los casos, cualquiera que sea el valor predeterminado que use la biblioteca debería estar bien, pero prepárese para hacer un benchmarking y ajuste de parámetros.

En cuanto al estado compartido, le recomiendo que pretenda que los usos tradicionales del estado compartido en proceso no existen: incluso si pueden funcionar ahora, es posible que tenga que dividir sus trabajadores dinámicos en varias máquinas más tarde. Para el estado al igual que los 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 securecookies, y para el estado temporal algo similar a memcached es bastante limpio. Cuanto menos dependas de las características que comparten datos (el enfoque de "nada compartido"), más grande podrás escalar en el futuro.

Postscript: He escrito y desplegado un montón de aplicaciones dinámicas en todo el alcance de las configuraciones anteriores: todos los servidores web enumerados anteriormente, y todo en el rango de PHP / Python / Ruby / Java. He probado exhaustivamente (utilizando tanto el benchmarking como la observación del mundo real) los métodos, y los resultados a veces son sorprendentes: menos es a menudo más. Una vez que haya dejado de alojar su código en el proceso del servidor web, a menudo puede salirse con la suya con un número muy pequeño de trabajadores FastCGI/Mestrel/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 2 * número de CPU no ganen realmente nada.