Tengo la intención de usar un solo VPS para implementar múltiples aplicaciones CherryPy de bajo tráfico como subdirectorios; por ejemplo: example.com/app1, example.com/app2, etc.

Después de investigar sobre la implementación de WSGI, parece que el método preferido para implementar aplicaciones es usar un servidor WSGI (Gunicorn, uWSGI, etc.) y NGinx en una configuración de proxy inverso. Parece excesivo usar dos servidores web en conjunto, especialmente porque mi aplicación CherryPy es en sí misma un servidor web, pero no quiero descartar la idea como aparece en todas partes . Ciertamente no soy un experto, así que me gustaría discutirlo.

Veo tres opciones:

• Implemente CherryPy por sí mismo.
• Implemente debajo de Gunicorn u otro servidor WSGI.
• Implemente debajo de un servidor WSGI y haga un proxy inverso a NGinx, que parece ser la solución de todos.

Mis preguntas:

• ¿Cuál es la razón principal por la que veo este patrón en todas partes? Nginx es simplemente que bueno?
• Para las aplicaciones de poco tráfico, ¿el servidor CherryPy nativo es lo suficientemente bueno o no debería intentarlo?

Todos y cada uno de los consejos son apreciados, gracias.

La razón por la que todos colocan nginx (u otro servidor como Apache) frente a sus servidores de aplicaciones es que todos tienen contenido estático como imágenes, CSS y JavaScript, y requisitos extraños que son exclusivos de su aplicación.

Su servidor de aplicaciones (CherryPy, gunicorn, lo que sea) está optimizado para ejecutar su aplicación y servir su salida. Si bien el servidor de aplicaciones también puede servir contenido estático, casi nunca están bien optimizados para esta tarea, ya que es secundario al propósito principal del servidor de aplicaciones. (Algunos servidores de aplicaciones también ayudarán al minimizar y comprimir su CSS y JS, para que el servidor web en frente pueda servir estos recursos aún más rápido).

Además, el servidor web real puede hacer mucho más que servir contenido de alto rendimiento. Cosas como el almacenamiento en caché, la manipulación de encabezados, la reescritura de URL, la geolocalización y muchas otras características que simplemente hincharían el servidor de aplicaciones sin ningún propósito.

Por lo general, solo ejecuta el servidor de aplicaciones solo cuando desarrolla la aplicación, cuando es el único usuario y el rendimiento no es un problema. Incluso si su sitio tiene poco tráfico, le gustaría que fuera más rápido, ¿verdad? Los sitios de bajo tráfico que son lentos generalmente no se convierten en sitios de alto tráfico ...

¿Por qué la gente pone a Nginx al frente?

1. Nginx es un servidor web asíncrono. Significa que no dedica un hilo o un proceso por conexión. En su lugar, utiliza la biblioteca de sondeo de socket preferida del sistema operativo y, por lo tanto, puede manejar cientos de miles de conexiones. ¿Por qué debería, como desarrollador de aplicaciones, preocuparse? Debido a que Nginx amortigua las conexiones y solo pasa la solicitud a su instancia ascendente CherryPy cuando la solicitud se lee por completo. Lo mismo para las respuestas. De esta manera, su aplicación CherryPy, que es un servidor roscado, detrás de Nginx en muchos sentidos, se vuelve asíncrona. Específicamente, agita la mano hacia un problema lento del cliente y los ataques loris DOS lentos.
2. Nginx tiene límite de velocidad de conexión fuera de la caja. Digamos, no quiero más de 8 conexiones simultáneas desde la misma IP.
3. CherryPy tiene un problema SSL . Nginx no lo hace.
4. Python puede enviar bytes de ida y vuelta casi tan bien como C. Python zlibes solo un contenedor alrededor de la biblioteca de C. Pero debido a que Nginx maneja la conexión de manera efectiva, es una buena idea evitar que sus hilos de trabajo CherryPy sirvan contenido estático en producción y dedicar solo contenido dinámico.
5. Multiplexar varias instancias de CherryPy en el mismo puerto, dominio, ruta, etc. Generalmente, flexibilidad adicional de otro nivel de configuración.

¿Es seguro usar CherryPy solo?

Según uno de los autores originales, sí . La mayoría de las cosas relevantes para la web puedes hacerlas solo con CherryPy.

CherryPy tiene la noción de una aplicación y puede servir varias aplicaciones con una instancia de CherryPy. CherryPy también puede servir otras aplicaciones WSGI .

Implementación de CherryPy

En una implementación tradicional * nix-style, escribe script de inicio, daemoniza su proceso, elimina sus privilegios, escribe su PID, etc. No es un gran problema cuando tiene un par de instancias de CherryPy. Cuando tiene docenas, se vuelve tedioso y tiene sentido transferir la gestión de procesos a Gunicorn o uWGSI y cambiar sus instancias CherryPy de HTTP a WSGI.

Escribí un tutorial / esqueleto de proyecto, cherrypy-webapp-skeleton , cuyo objetivo era llenar los vacíos para implementar (tradicional) una aplicación CherryPy del mundo real en Debian para un desarrollador web.

Envolver

1. Bajo tráfico, sin requisitos especiales → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. Alto tráfico, requisitos especiales → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Docenas de instancias separadas de CherryPy en el mismo servidor, ansiosas por exagerar la solución de todos → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.