est-il vraiment nécessaire d'exécuter Apache en tant que frontal pour Glassfish / JBoss / Tomcat?


14

Je suis principalement un développeur Java, et je viens à vous avec une question qui chevauche le fossé entre les développeurs et les administrateurs système.

Il y a des années, lorsque c'était une nouveauté d'exécuter Tomcat en tant que serveur d'applications, il était habituel de le gérer avec Apache. Si je comprends bien, cela a été fait parce que:

  1. Java était considéré comme "lent" et il était utile qu'Apache serve directement le contenu statique.
  2. Tomcat ne pouvait pas écouter les ports 80/443 à moins d'être exécuté en tant que root, ce qui était dangereux.

Java n'est plus considéré comme lent, et je doute que l'ajout d'Apache au mixage aidera réellement à accélérer les choses.

En ce qui concerne le problème des ports, il existe probablement des moyens plus simples de connecter les serveurs d'applications aux ports 80/443 de nos jours.

Donc ma question est- est-il vraiment avantageux de faire face à Java Webapps avec Apache ces jours-ci? Si oui, Apache est-il toujours le chemin à parcourir? Dois-je regarder Nginx? Au lieu de Tomcat, j'utilise Glassfish, si cela importe.

Réponses:


8

La plupart des gens vont dire que vous avez besoin de quelque chose à l'avant en raison de fichiers statiques.

C'est un peu stupide car:

  • Vous pouvez configurer Tomcat pour utiliser le même IO qu'apache avec APR
  • Vous devez de toute façon utiliser un CDN (Content delivery network).

La vraie raison pour laquelle vous avez besoin de quelque chose devant tomcat / jetty / jboss pour charger l'équilibre et gérer le basculement.

Je vous recommande de ne pas écouter " ... Le moteur Tomcat est le talon d'Achille de toute l'écosphère ... " car nous savons tous que ce n'est pas vrai ... votre base de données et son pool de connexions seront les mêmes.


Adam, vous me traquez de StackOverflow vers Serverfault? :-) Je suis d'accord avec votre réponse. Rétrospectivement, j'aurais dû mieux formuler la question pour refléter la situation réelle: il y a vraiment très peu de contenu statique à proprement parler, car la base de données est impliquée dans presque tous les appels de page. Pour le moment (exploration de démarrage très précoce), nous n'avons pas besoin d'équilibrage de charge, mais avec de la chance, nous en aurons besoin à l'avenir.
Caffeine Coma

@Caffeine Coma Je suis dans le même bateau et il semble que nous utilisons la même technologie, d'où la chance d'être sur les mêmes fils à travers Stackexchanges (je jure que je ne traque pas :)). BTW nous utilisons Nginx + Tomcat.
Adam Gent

5

Cela dépend de l'écosystème autour de votre application. Dans un environnement intranet - vous n'avez probablement besoin de rien devant Tomcat.

S'il est seul sur Internet en tant que service public, cela dépend. Apache est agréable à cause des modules qu'il fournit comme mod_security. Mais si vous ne connaissez pas la configuration d'apache (ou ngix) - vous pourriez vous exposer à encore PLUS d'attaques ou de points d'échec en raison d'une mauvaise configuration.

Apache en face est pratique pour servir les pages de panne dans les cas où vous devez mettre à niveau la webapp et attendre un redémarrage. Mais si les redémarrages sont rares ou s'ils sont chronométrés correctement - c'est une autre raison de devenir Tomcat autonome.

La FAQ Tomcat en parle également, qui aborde certains points supplémentaires: http://wiki.apache.org/tomcat/FAQ/Connectors#Q3


1

Apache n'est pas un bon candidat pour diffuser du contenu statique en raison de sa nature multi-processus. Nginx convient mieux car il utilise des E / S asynchrones pour traiter les demandes. Les Tomcats modernes peuvent également utiliser des E / S asynchrones (NIO dans la terminologie Java). Par exemple, vous devez installer le tomcat-nativepackage dans Fedora pour que Tomcat utilise les E / S asynchrones.


De toute façon, je ne sers pas vraiment beaucoup de contenu statique. Ma question est vraiment: dois-je me soucier d'un frontal Apache / Nginx, ou tout simplement aller avec Glassfish directement? Merci.
Caffeine Coma

En fait, le problème est plus large que de simplement servir du contenu statique, car si votre serveur n'utilise pas de clients d'E / S asynchrones avec des connexions lentes, il bloquera les threads d'exécution du serveur jusqu'à ce qu'ils obtiennent le contenu complet. Donc, avoir un frontend alimenté par AIO est un avantage dans tous les cas. Mais, comme je l'ai déjà mentionné, Tomcat a des capacités AIO. Je pense que le paquet standard Glassfish comprend déjà la bibliothèque AIO, donc vous ne devriez probablement pas vous embêter.
Alex

apache n'est pas nécessairement multi-processus. mpm worker est absent depuis un certain temps httpd.apache.org/docs/2.2/mod/worker.html et nous l'utilisons dans un environnement de production pour un serveur Web multithread.
dialt0ne

Eh bien, Apache multithread utilise toujours des E / S synchrones. Je ne vois pas de grande différence si les threads et non les processus seront bloqués sur un socket par des clients lents. Nginx est conçu comme une machine à états finis à un seul processus et à un seul thread (enfin, pas nécessaire à un seul processus, le nombre de processus doit être défini sur le nombre de cœurs de processeur sur un système multicœur).
Alex

1

Étonnantes, certaines de ces réponses - certains d'entre vous exécutent-ils réellement des sites Web multiniveaux et multi-serveurs Tomcat à hautes performances? OP, votre supposition originale que Tomcat n'est pas "lent" ... wow. Le moteur Tomcat est le talon d'Achille de toute l'écosphère.

Oui, vous voulez qu'Apache soit en tête - il fournit d'abord et avant tout mod_rewrite (avez-vous déjà implémenté UrlRewriteFilter dans votre Tomcat?) Ainsi que les fichiers htaccess qui rendent la protection d'un serveur Web si importante. Apache peut vous permettre d'équilibrer la charge des nœuds Tomcat derrière lui, de servir votre contenu statique beaucoup plus rapidement et d'obtenir de meilleures performances de Tomcat car vous ne surchargez pas son canal de demande avec des composants non Java (js / css / html / jpg / etc.) des choses. Vous pouvez décharger votre SSL sur Apache (si ce n'est pas sur un LB matériel) avec facilité et ne pas même avoir à faire face à cette parodie appelée Java Keystore. Il y a tellement de victoires - vous pouvez régler mod_jk sur vos nœuds principaux pour éviter de surcharger le pauvre petit cerveau de Java car il ne peut généralement pas gérer un trafic massif avec le codeur Java moyen ''

Méfiez-vous de toute personne qui vous dit qu'Apache (ou nginx, etc. - mais les performances d'Apache surclasseront Tomcat de toute façon, peu importe) n'est pas une bonne idée devant Tomcat.


4
Vous semblez très offensé.
Caffeine Coma

Juste dégoûté que les gens offrent de si mauvais conseils sur ServerFault.

Méfiez-vous de tous ceux qui déclament sans chiffres pour soutenir de telles réclamations. Si votre site est principalement dynamique, le tomcat direct sera plus rapide. La plupart des sites à fort trafic utilisent de nos jours CDN (réseau de diffusion de contenu) pour leur contenu statique, il n'y a donc aucune raison d'utiliser Apache pour servir votre contenu statique. Cela étant dit, vous devriez toujours avoir quelque chose en face pour l'équilibrage de charge / ssl.
Adam Gent

0

S'il s'agit simplement de lier des privilèges au port sans être root lorsque vous utilisez Tomcat, vous n'avez pas besoin de le gérer avec Apache httpd. Tomcat est livré par défaut avec ce jsvcque vous devez compiler.

jsvcest un wrapper de service java pour lancer Tomcat en tant que service. Ce service démarre en tant que root mais démarre Tomcat en tant qu'utilisateur normal. Vous pouvez donc lier votre Tomcat à des ports privilégiés.

Je ne connais pas Glassfish, mais assurez-vous qu'il existe des solutions et sinon vous pouvez sûrement utiliser des techniques de redirection de port (iptables, etc ...)

Je pense que le choix de faire face à un serveur d'applications avec un serveur Web (Apache httpd par exemple) est pour l'équilibrage de charge, le clustering ou pour servir des ressources statiques uniquement avec un serveur Web et des ressources dynamiques avec un serveur d'applications.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.