è davvero necessario eseguire Apache come front-end per Glassfish / JBoss / Tomcat?

14

Sono principalmente uno sviluppatore Java e vengo da te con una domanda a cavallo tra la divisione tra sviluppatori e amministratori di sistema.

Anni fa, quando era una cosa nuova eseguire Tomcat come server di app, era consuetudine supportarlo con Apache. A quanto ho capito, questo è stato fatto perché:

Java era considerato "lento" ed era utile che Apache servisse direttamente il contenuto statico.
Tomcat non poteva ascoltare le porte 80/443 se non eseguito come root, il che era pericoloso.

Java non è più considerato lento e dubito che l'aggiunta di Apache al mix contribuirà effettivamente ad accelerare le cose.

Per quanto riguarda il problema delle porte, ci sono probabilmente modi più semplici per connettere i server delle app alle porte 80/443 in questi giorni.

Quindi la mia domanda è: c'è davvero qualche vantaggio nel supportare Java Webapps con Apache in questi giorni? In tal caso, Apache è ancora la strada da percorrere? Dovrei guardare Nginx? Invece di Tomcat sto usando Glassfish, se è importante.

apache-2.2 glassfish tomcat

— Coma alla caffeina
fonte

8

Molte persone diranno che hai bisogno di qualcosa di fronte a causa di file statici.

Questo è un po 'stupido perché:

Puoi configurare Tomcat per utilizzare lo stesso IO di apache con APR
Dovresti comunque utilizzare una rete CDN (Content Delivery Network).

Il vero motivo per cui hai bisogno di qualcosa di fronte a tomcat / jetty / jboss per caricare l'equilibrio e gestire il failover.

Ti consiglio di non ascoltare " ... Il motore Tomcat è il tallone d'Achille di tutta l'ecosfera ... " come sappiamo tutti che non è vero ... il tuo database e il suo pool di connessioni saranno quelli.

— Adam Gent
fonte

Adam, mi stai inseguendo da StackOverflow a Serverfault? :-) Concordo con la tua risposta. In retrospettiva, avrei dovuto formulare meglio la domanda per riflettere la situazione reale: c'è davvero molto poco contenuto statico di cui parlare, dal momento che il DB è coinvolto in quasi ogni hit di pagina. In questo momento (esplorazione di avvio molto precoce) non abbiamo bisogno di bilanciamento del carico, ma per fortuna ne avremo bisogno in futuro.

— Caffeina Coma,

@Caffeine Coma Sono nella stessa barca e sembra che stiamo usando la stessa tecnologia, quindi la serendipità di essere sugli stessi thread attraverso Stackexchanges (giuro che non sono stalking :)). A proposito stiamo usando Nginx + Tomcat.

— Adam Gent,

5

Dipende dall'ecosistema attorno all'app. In un ambiente intranet: probabilmente non hai bisogno di nulla davanti a Tomcat.

Se solo su Internet come servizio pubblico, dipende. Apache è simpatico grazie ai moduli che fornisce come mod_security. Ma se non sei informato con la configurazione di apache (o ngix), allora potresti esporti a MOLTI attacchi o punti di errore a causa di un'errata configurazione.

Apache di fronte è utile per servire le pagine di interruzione nei casi in cui è necessario aggiornare la webapp e attendere il riavvio. Ma se i riavvii sono rari o sono cronometrati correttamente, allora è un altro motivo per passare a Tomcat autonomamente.

Anche le Domande frequenti su Tomcat parlano di questo, che affronta alcuni punti aggiuntivi: http://wiki.apache.org/tomcat/FAQ/Connectors#Q3

— Tim Funk
fonte

1

Apache non è un buon candidato per servire contenuto statico a causa della sua natura multi-processo. Nginx si adatta meglio poiché utilizza l'I / O asincrono per elaborare le richieste. I Tomcat moderni possono utilizzare anche l'I / O asincrono (NIO nella terminologia Java). Ad esempio, dovresti installare il tomcat-nativepacchetto in Fedora per fare in modo che Tomcat usi l'I / O asincrono.

— alex
fonte

Non sto comunque servendo molto contenuto statico. La mia domanda è davvero: devo preoccuparmi di un front-end Apache / Nginx o semplicemente andare con Glassfish dritto? Grazie.

— Caffeina Coma,

In realtà, il problema è più ampio della semplice pubblicazione di contenuto statico perché se il tuo server non utilizza client I / O asincroni con connessioni lente, bloccherà i thread di esecuzione del server fino a quando non avranno ottenuto il contenuto completo. Quindi, avere un frontend basato su AIO è comunque un vantaggio. Ma, come ho già detto, Tomcat ha funzionalità AIO. Penso che il pacchetto stock Glassfish includa già la libreria AIO, quindi probabilmente non dovresti preoccuparti.

— Alex

apache non è necessariamente multi-processo. mpm worker è in circolazione da qualche tempo httpd.apache.org/docs/2.2/mod/worker.html e stiamo utilizzando un ambiente di produzione per un server web multi-thread.

— dialt0ne,

Bene, Apache multithread utilizza ancora l'I / O sincrono. Non vedo grandi differenze se i thread non i processi verranno bloccati su un socket da client lenti. Nginx è progettato come macchina a stati finiti a processo singolo a thread singolo (beh, non è necessario un processo singolo, il numero di processi dovrebbe essere impostato sul numero di core della CPU su un sistema multi-core).

— Alex

1

Incredibile, alcune di queste risposte - qualcuno di voi gestisce effettivamente siti Web Tomcat multi-livello e multi-server ad alte prestazioni? OP, la tua supposizione originale che Tomcat non è "lento" ... wow. Il motore Tomcat è il tallone d'Achille di tutto l'ecosfera.

Sì, vuoi che Apache sia in primo piano - fornisce innanzitutto mod_rewrite (hai già implementato UrlRewriteFilter nel tuo Tomcat?) Così come i file htaccess che rendono la protezione di un server web così importante. Apache può permetterti di bilanciare i nodi Tomcat dietro di esso, servire il tuo contenuto statico molto più velocemente e ottenere migliori prestazioni da Tomcat perché non stai sovraccaricando la sua pipe di richiesta con non Java (js / css / html / jpg / etc.) cose. Puoi scaricare il tuo SSL su Apache (se non scaricarlo su un LB hardware) con facilità e nemmeno dover affrontare quella parodia chiamata Java Keystore. Ci sono così tante vittorie: puoi sintonizzare mod_jk sui tuoi nodi di back-end per evitare di superare il povero cervello di Java perché in genere non è in grado di gestire un traffico enorme con il programmatore Java medio "

Fai attenzione a chiunque ti dica che Apache (o nginx, ecc. - ma le prestazioni di Apache supereranno comunque Tomcat, quindi non importa) non è una buona idea di fronte a Tomcat.

4

Sembri molto offeso.

— Caffeina Coma,

Sono solo disgustato dal fatto che le persone offrano consigli così negativi su ServerFault.

Fai attenzione a chiunque prenda in giro qualsiasi numero per sostenere tali richieste. Se il tuo sito è per lo più dinamico, Tomcat diretto sarà più veloce. Oggigiorno la maggior parte dei siti a traffico intenso utilizzano CDN (rete di distribuzione del contenuto) per il loro contenuto statico, quindi non c'è motivo di utilizzare Apache per pubblicare il contenuto statico. Detto questo, dovresti comunque avere qualcosa di fronte al bilanciamento del carico / ssl.

— Adam Gent,

0

Se si tratta solo di associare la porta dei privilegi senza essere root quando si utilizza Tomcat, non è necessario frontarlo con Apache httpd. Tomcat di default viene fornito con jsvcquello che devi compilare.

jsvcè un wrapper di servizi Java per avviare Tomcat come servizio. Questo servizio inizia come root ma avvia Tomcat come un normale utente. Quindi puoi associare Tomcat a porte privilegiate.

Non so Glassfish, ma assicurati che esistano soluzioni e, in caso contrario, puoi sicuramente utilizzare le tecniche di port forwarding (iptables, ecc ...)

Penso che la scelta di fronting un application server con un web server (Apache httpd per esempio) sia per il bilanciamento del carico, il clustering o servire risorse statiche solo con un web server e risorse dinamiche con un application server.

— Laurent T
fonte