tomcat - servidor - ¿La mejor estrategia de despliegue para las aplicaciones PlayFramework?

servlets

Question

Esta pregunta está orientada al servidor. Tengo un servidor alojado (uno bastante pequeño, un átomo de 1,6 Ghz, 2Go, 200 GO) con un par de aplicaciones de juego (4 o 5) y más. La mayoría de estas aplicaciones tienen un uso realmente pequeño, digamos cien solicitudes al día cada una.

1. ¿Es mejor implementar cada una de esas aplicaciones utilizando el servidor integrado de Play! y así usar 64mb de memoria para cada aplicación?

2. ¿O implementar un Tomcat con todas las aplicaciones dentro del tomcat? ¿Con una memoria más grande compartida por todas las aplicaciones?

EDITAR:

Añadiré un poco más de información sobre mi situación. El servidor también alberga:

• Alrededor de 10,15 sitios web PHP en Apache2
• Un servidor SVN pasando por Apache mod_dav_svn
• Un tomcat utilizado para sonar.
• Una instalación independiente de Jenkins (a través de Jetty)

Mi plan original era desplegar todas estas cosas en Tomcat. Teniendo las aplicaciones, Sonar & Jenkins ejecutándose en Tomcat y Apache2 para recursos estáticos. (Imágenes, guiones)

COMENTARIO

Último punto, soy consciente de que tener los sistemas de integración continua de Sonar & Jenkins en un entorno de producción no es realmente óptimo. Pero como estos solo se ejecutan de noche (compilaciones automatizadas) no están sobrecargando el sistema. Además, soy un estudiante, financieramente un servidor adicional "CI / build" está fuera de mi capacidad financiera.

Answer 1

El mejor enfoque es utilizar el servidor Play incluido, poniendo a NGinx como proxy inverso frente a él para abordar toda la redirección / gestión de solicitudes.

¿Por qué esto y no Tomcat? Puedes comenzar con este artículo que compara el rendimiento. Un argumento adicional sería que Tomcat carga todo el entorno Java EE que Play no requiere ni usa, ya que consume la memoria y los recursos que desea de forma gratuita para sus aplicaciones (especialmente si utiliza el almacenamiento en memoria caché).

En Nginx como proxy inverso, this debería dar una pista sobre por qué usarlo en lugar de Apache.

EDITAR (en la edición de la pregunta):

En su situación, puede optimizar sus recursos.

Primero reemplaza Apache 2 por Nginx. Nginx puede servir PHP, bastante bien (si usa Ubuntu vea this ). Servirá a Play de manera muy eficiente, y se puede usar como proxy para servidores Java.

Luego, puede mover todas sus aplicaciones Java a Jetty y deshacerse de Tomcat. Jetty consume menos recursos en promedio, e incluso si sus aplicaciones solo se ejecutan por la noche, el servidor todavía está en línea y acumulando RAM. Cuanto menos se necesita, mejor.

¿Qué pasa con SVN? Lamentablemente, necesitará Apache 2 y Nginx como proxy inverso de Apache 2. ¿Por qué no mantener Apache entonces? El argumento sería el uso. En teoría, las aplicaciones PHP tendrán más tráfico que el servidor SVN, lo que hace más relevante el consumo de recursos que tienen. Con nginx, ram y cpu asignados para servir PHP será menos haciendo que su máquina sea más receptiva. Apache solo actuará cuando uses SVN, que no será tan frecuente.

Si no quieres poner esfuerzo en mover cosas a Nginx (lo que puedo entender), simplemente mueve las aplicaciones Java a Jetty y usa Apache 2 como proxy inverso para Play. Pero use el servidor incorporado Play, no cargue la aplicación en Tomcat. Así será más eficiente.

Answer 2

Empezaría por cada aplicación un servidor de juego. Es más fácil en la configuración y más fácil tener archivos de registro separados. Además puedes reiniciar cada aplicación por separado sin problemas. Una redistribución en Tomcat es a menudo un trabajo con resultados en errores.

Desventaja: debe configurar un proxy inverso como lighttp para obtener direcciones URL agradables como mydomain.org/app1 y mydomain.org/app2

Answer 3

Las implementaciones de producción que estoy ejecutando están usando el servidor integrado Play. Hace la vida mucho más simple que Tomcat, especialmente la redistribución. Ejecuto los servidores en pantalla, y una actualización consiste en "Ctrl-C", "Flecha arriba", "Enter", ejecutando:

% git stash; git pull; git stash apply; play run

Con 2G de memoria, no me preocuparía demasiado la sobrecarga por proceso. Es ciertamente un precio que vale la pena pagar para deshacerse de las complejidades de Tomcat.

(El alijo de git me permite tener algunas configuraciones no comprometidas con git que se encuentran en la producción, aunque más pereza que necesidad :-))