Apache sobre Apache tomcat

El Tomcat sirve como servidor web, para despachar también contenido estático, pero no lo hace tan bien como el httpd, además que si Tomcat está corriendo tu aplicación web, lo mejor es que se dedique exclusivamente a eso, y dejar que todo el contenido estático (imágenes, hojas de estilo, páginas estáticas, archivos de javascript, etc) lo despache directamente el httpd.
Además, por seguridad, es recomendable que tengas el httpd expuesto en el puerto 80, mientras que Tomcat no sea visible desde internet (lo puedes tener incluso en otro servidor distinto). El httpd recibe TODAS las peticiones que lleguen al puerto 80, atiende las que sean válidas, y le pasa a Tomcat solamente las que son de las aplicaciones que Tomcat contiene. Y por administración también puede convenir porque alguien con amplio conocimiento del http te lo puede dejar configurado para un desempeño óptimo y con buena seguridad, etc, porque puede ser que ese httpd se dedique a despachar otros sitios web (hosts virtuales).

En resumen, es por separación de funciones que conviene tener el httpd al frente, expuesto a internet, y Tomcat atrás, en el mismo servidor o en uno distinto, solamente despachando las peticiones de sus aplicaciones.

La manera hacer esto es con un módulo de httpd llamado jk. Incluso creo que te permite hacer balanceo de cargas, para poner dos o más instancias de Tomcat (en servidores distintos) y que el httpd le pase peticiones a todas.

Todo esto tiene sentido al final ya en el deployment, no tiene caso que hagas todo ese relajo en desarrollo (solamente para cuando te pongas a probar la configuración de httpd+jk+tomcat).

Muchas gracias por la respuesta, esto me aclara más el panorama.

Entonces si pongo httpd en producción por delante de tomcat, abrirá más rápido las páginas de mi aplicación, que si lo hiciera con tomcat solito?
Apache se puede configurar como despachador de contenido estatico con cualquier servidor de aplicaciónes?

gracias por la ayuda

Pues el que abra las páginas de tu app más rápido depende de varias cosas. En realidad hay un cierto overhead para despachar las peticiones dinámicas porque primero le llegan al httpd, que debe determinar que la petición realmente es para Tomcat, entonces le pasa la petición a Tomcat, quien la vuelve a analizar, la despacha, le da la respuesta al httpd y el httpd la devuelve al cliente. Pero si pones los recursos estáticos de la aplicación, como hojas de estilo, javascript, imágenes, animaciones, etc etc bajo el httpd en vez de Tomcat, el httpd puede despacharlos mucho más rápido que Tomcat, además que puedes configurar cache en httpd para esos recursos y otras optimizaciones que permitirán acelerar la transmisión de todos esos datos que no cambian.

El desempeño no es la única ventaja, también te permite tener mayor seguridad. Por ejemplo, puedes tener un servidor dedicado con el puro httpd, expuesto a internet (con su firewall y toda la cosa). Luego pones otro servidor separado con el Tomcat, detrás de un segundo firewall, y ese Tomcat solamente acepta conexiones que lleguen del httpd. Por qué tanto relajo? porque así el Tomcat no está tan expuesto a ataques del exterior... normalmente el Tomcat va a estar corriendo aplicaciones que se conectan a base de datos y el servidor de base de datos también lo debes tener muy bien protegido, y parte de esa protección es que no haya servidores expuestos a internet que se puedan conectar directo a la base de datos. Si tu servidor con el httpd está vulnerable y te lo hackean, tu Tomcat sigue estando seguro (aunque el atacante ya está más cerca de poder atacarlo).

Esto me alcara más dudas, muchas gracias por tu tiempo en ayudarme y leerme

Entonces igual he escuchado que los servidores tomcat se conectan en paralelo y hay un balanceador de carga que dice tu vas paya y tu vas paca...
ese balanceador de cargas es httpd o tomcat?

Otra pregunta un poco fuera offtopic, qué sucede con las variables de sesion cuando se conectan servidores en paralelo? alguna vez lo has desarrollado algo que necesite conectar servidores en paralelo? cuál ha sido tu experiencia?

El balanceador de cargas debe ser httpd, porque es quien decide a cuál tomcat mandar la petición.

Desconozco qué hace jk respecto a las sesiones, lee la documentación, pero pues por lo general lo que se hace en estos casos (balanceo de cargas, con el servidor de aplicaciones que sea y el web server que sea) es que la primera petición se manda al contenedor más desocupado, y si se inicia una sesión se le pone un ID en el URL; cuando llegan peticiones con un ID, se mandan al contenedor que generó ese ID (el contenedor debe tener algun identificador propio que viene como parte del identificador de sesión), de esa forma ya ese cliente siempre se conecta al mismo contenedor.

La otra opción es ponerlos en cluster pero no sé si Tomcat tiene esa funcionalidad. JBoss sí la tiene, aunque no está muy fácil armarla, pero ya con un cluster de contenedores JBoss se pueden pasar las peticiones a cualquier JBoss sin importar que haya iniciado sesión el cliente en uno y luego se conecte a otro.

Hola ezamudio, gracias por tu pronta respuesta

Me parece que tomcat si se puede poner en cluster pero me surge otra pregunta...
En sí, cuándo es bueno poner un cluster? o bajo qué circunstancias es recomendable montarlo?

entiendo que un cluster se monta cuando la carga es muy grande para el servidor, pero cómo puedo saber esto antes de montar el sistema... hay alguna forma de calcularlo? o a qué se le llama mucha carga en el servidor, cuándo se alenta o cuando se cae? ups

tiene que ver la base de datos?

gracias

El cluster es para un ambiente de alto rendimiento, donde tienes varios servidores corriendo tomcat y httpd haciendo balanceo de cargas. Si necesitas mas poder de procesamiento, metes mas servidores al cluster. Si un servidor se muere, tal vez algunos usuarios pierdan su sesión (y luego ni eso pasa) pero la aplicación sigue corriendo.
Se usa en sistemas que tienen muchísimos usuarios concurrentes, donde un solo servidor ya no puede dar abasto a todos. No está nada fácil configurar algo así porque también necesitas replicar la base de datos y configurar muy bien a qué RDBMS se envian ciertas consultas u operaciones.

gracias por la pronta respuesta ezamudio, esto me aclara mucho el panorama.

Oye, y qué sucede con los mecanismos de sincronización de threads con java ? me refiero a que se supone que si la aplicación está en diferentes servidores pues ya no comparten la memoria y no serviría mucho ... o si?
Mi duda es qué sucede con la memoria cuando utilizas varios servidores.
gracias

No entendí bien tu duda de sincronización de threads con Java. Si tienes un web server en una máquina y el contenedor JEE en otra... qué? no entiendo qué puede crees que puede pasar con los threads.

Si te refieres al cluster, es un rollo porque tienen que compartir los datos de las sesiones abiertas si quieres que los usuarios puedan tener una sesión abierta y puedan mandar peticiones a cualquiera de los contenedores que conforman el cluster. O puedes hacer el balanceo solamente al principio y en cuanto el usuario crea una sesión, ya el httpd siempre va a mandar a ese usuario al mismo contenedor.

Que tan importante es tener las optimizaciones arriba mencionadas? Estoy casi seguro que no todos lo sitios, paginas lo tienen. Acaso se trata de darle mayor performance a la aplicación web?

No todos lo tienen. Ese no es mi problema, no hay nada que yo pueda hacer al respecto. En los proyectos donde puedo influir en el deployment, hago que se tenga un web server separado del contenedor JEE, aunque sea en el mismo equipo.

Se trata de aprovechar los recursos de la mejor manera posible. Se trata también de no exponer más funcionalidad de la necesaria. Para qué exponer todo el contenedor JEE a internet si solamente debe procesar algunas peticiones? Para qué hacer que el contenedor JEE despache recursos estáticos como páginas de HTML, imágenes, javascript, etc cosas que no cambian, si tenemos programas hechos especialmente para eso y que lo hacen muy bien y más rápido?

Recuerda que el performance es una consecuencia de muchas cosas, es el resultado de una combinación de factores: el diseño de la aplicación, el número de usuarios concurrentes, la memoria física del servidor, el número de CPU's y la velocidad, en general toda la arquitectura de hardware; hasta los discos duros y la manera en que tengas o no tengas un RAID te puede afectar en el desempeño de la aplicación. Pero una aplicación bien diseñada puede tener mal desempeño si se hace un mal deployment. Y una aplicación mal diseñada puede tener un desempeño no tan malo si se configura muy bien el ambiente donde corre.

No pues, toda via me falta mucho que aprender y gracias por compartir tus conocimientos a todos nosotros (los lectores y comunidad presente).

Si, me refiero a los clusters... Entonces entiendo que en cuanto a configuración es mas facil hacer el balanceo al principio, pero si quiero algo altamente disponible y compartir sesiones entre los nodos del cluster me tengo que meter en rollos bien pesados?
Gracias nuevamente

Montar un cluster no está fácil, pero tampoco es cosa del otro mundo. Lee por ejemplo la documentación de JBoss para ponerlo en cluster, consíguete 3 computadoras para que pongas en una el httpd y en las otras dos JBoss con la misma aplicación, y le configures lo de cluster... a lo mejor te tardas uno o dos días para tenerlo funcionando.

Tengo una aplicacion ya funcionando, sin embargo ahorita que la aplicacion esta demandado mas concurrencia, hablando de 50 usuarios no es mucha, el webserver Tomcat 5.26 comienza alentarse demasiado, hasta que se vuelve no funcional. Estoy tratando de optimizar mas las conexiones a la base de datos, optimizar con parametros de arranque del servidor, sin embargo no se ha solucionado del todo.
Tengo configurado el https y seguire el consejo de la separacion de peticiones, pero no ha sido suficiente, tendras de favor alguna otra recomendacion para este caso?

Saludos