pagina logo jakarta instalar descargar apache tomcat glassfish

logo - ¿Por qué usar Apache Web Server frente a Glassfish o Tomcat?



tomcat logo (5)

Como todos te dieron razones para poner a Apache delante de Tomcat, déjame darte algunas razones por las que no :

  • El conector AJP no admite y no admite IO avanzado, lo que significa que no tiene Comet , Websockets , etc.
  • Si no estás usando AJP, he notado que hay una sobrecarga de proxy bastante grande al usar mod_proxy para Apache. Entonces, si buscas baja latencia, Apache no sería bueno.
  • Apache tiene una huella bastante grande en comparación con Nginx o Lighttpd, etc.

Poner a Apache en frente NO :

Lo que Apache le brinda es más complementos y le permite ejecutar diferentes tecnologías web.

Si solo necesita Tomcat, sería más adecuado usar un HAProxy o Nginx como equilibrador de carga.

¿Es una buena idea usar Apache Webserver frente a GF o Tomcat? ¿Mejora el rendimiento / seguridad?

¿O no hay ninguna razón para usar Apache Web Server con GF?


Si está ejecutando una pila LAMP, puede ejecutar PHP / Ruby cosas fuera de apache y reenviar cosas java a tomcat con mod_jk.


Tomado de http://wiki.apache.org/tomcat/FAQ/Connectors#Q3

  • Agrupación. Al utilizar Apache HTTP como interfaz, puede permitir que Apache HTTP actúe como puerta de entrada de su contenido a varias instancias de Apache Tomcat. Si uno de tus Apache Tomcats falla, Apache HTTP lo ignora y tu Sysadmin puede dormir toda la noche. Este punto podría ignorarse si utiliza un hardware loadbalancer y las capacidades de clúster de Apache Tomcat.
  • Agrupamiento / Seguridad. También puede utilizar Apache como puerta de entrada a diferentes Apache Tomcats para diferentes espacios de nombres de URL (/ app1 /, / app2 /, / app3 /, o hosts virtuales). Los Apache Tomcats pueden estar en un área protegida y, desde el punto de vista de la seguridad, solo debe preocuparse por el servidor Apache HTTP. Esencialmente, Apache se convierte en un servidor proxy inteligente.
  • Seguridad. Este tema puede influir en uno de los dos modos. Java tiene el administrador de seguridad, mientras que Apache tiene una mayor capacidad de memoria y más trucos con respecto a la seguridad. No entraré en esto con más detalle, pero deje que Google sea su amigo. Dependiendo de su escenario, uno podría ser mejor que el otro. Pero también ten en cuenta que si ejecutas Apache con Tomcat, tienes dos sistemas para defender, no uno.
  • Complementos. Agregar CGI, perl, PHP es muy natural para Apache. Es más lento y más complicado para Tomcat. Apache HTTP también tiene cientos de módulos que se pueden conectar a voluntad. Apache Tomcat puede tener esta capacidad, pero el código aún no se ha escrito.
  • Decoradores! Con Apache HTTP en frente de Apache Tomcat, puede realizar cualquier cantidad de decoradores que Apache Tomcat no admita o no tenga el soporte de código inmediato. Por ejemplo, mod_headers, mod_rewrite y mod_alias podrían escribirse para Apache Tomcat, pero ¿por qué reinventar la rueda cuando Apache HTTP lo ha hecho tan bien?
  • Velocidad. Apache HTTP es más rápido en servir contenido estático que Apache Tomcat. Pero a menos que tenga un sitio con mucho tráfico, este punto es inútil. Pero en algunos escenarios, Apache Tomcat puede ser más rápido que Apache httpd. Así que compara tu sitio. Apache Tomcat puede funcionar a velocidades httpd cuando usa el conector adecuado (APR con sendFile habilitado). La velocidad no se debe considerar un factor al elegir entre Apache httpd y Tomcat
  • Manejo del zócalo / estabilidad del sistema. Apache HTTP tiene un mejor manejo de socket con respecto a las condiciones de error que Apache Tomcat. La razón principal es que Apache Tomcat debe realizar todo su manejo de socket a través de la JVM, que debe ser multiplataforma. El problema es que la optimización del socket es una experiencia específica de la plataforma. La mayoría de las veces el código java está bien, pero cuando también se bombardea con conexiones caídas, paquetes no válidos, solicitudes no válidas de direcciones IP no válidas, Apache HTTP hace un mejor trabajo al eliminar estas condiciones de error que el programa basado en JVM. (YMMV)

Una razón para colocar a Apache frente a Tomcat sería para equilibrar la carga.
Las solicitudes llegan al servidor Apache y se distribuyen a los contenedores Tomcat de respaldo dependiendo de la carga y la disponibilidad.
Los clientes solo conocen una IP (Apache), pero las solicitudes se distribuyen en varios contenedores.
Así que esto es en el caso de que implemente un tipo de aplicación web distribuida y la necesite sólida.
Si su pregunta es acerca de una simple aplicación web, entonces vea la respuesta dbyrne


  • Escalabilidad : como señalaron Amir y user384706, puede cargar el saldo de varias instancias de su aplicación detrás de Apache. Esto le permitirá manejar más volumen y aumentar la estabilidad en caso de que una de sus instancias se caiga.

  • Seguridad : Apache, Tomcat y Glassfish son compatibles con SSL, pero si decide usar Apache, es muy probable que allí lo configure. Si desea protección adicional contra ataques (DoS, XSS, inyección de SQL, etc.) puede instalar el firewall de la aplicación web mod_security .

  • Características adicionales : Apache tiene una gran cantidad de buenos módulos disponibles para la reescritura de URL, la interfaz con otros lenguajes de programación, la autenticación y un montón de otras cosas.

  • Rendimiento : si tiene mucho contenido estático, publicarlo con Apache mejorará su rendimiento. Si la mayor parte de su contenido es dinámico, usar Tomcat o Glassfish solo será igual de rápido (probablemente más rápido). (como se señala en las respuestas a esta pregunta , esto ya no es cierto).