In locale sembra funzioni bene.
Qualcuno lo ha provato ?
Con che risultati ?
Per adesso ho problemi da remoto. (Non si connette. Lanciandolo del
server funziona) Da dire che sul server è attivo Tomcat porta 80 e
Webrich porta 90.
Ho dei dubbi sui parametri server.bind e scgi “host”.
Di seguito le impostazioni principali #lighttpd.conf
server.port = 3000
server.modules = (
“mod_rewrite”,
“mod_redirect”,
“mod_access”,
“mod_status”,
“mod_scgi”,
“mod_accesslog”
)
server.port = 3000
In locale sembra funzioni bene.
Qualcuno lo ha provato ?
su linux
Con che risultati ?
ottimi!
Per adesso ho problemi da remoto. (Non si connette. Lanciandolo del
server funziona) Da dire che sul server è attivo Tomcat porta 80 e
Webrich porta 90.
Ho dei dubbi sui parametri server.bind e scgi “host”.
qualche info in più su cosa ci fai girare e come lo attivi ?
In locale sembra funzioni bene.
Qualcuno lo ha provato ?
Con che risultati ?
Provato ormai quasi un anno fa (su Linux), tutto liscio almeno al
tempo, comunque prima che ci investi del tempo, tieni presente che Zed
Shaw (l’autore del modulo SCGI) sta dedicandosi quasi esclusivamente a
Mongrel e lui stesso, alla domanda “SCGI o Mongrel?”, consigliava di
usare quest’ultimo in tutti i casi salvo particolari esigenze
(necessità di clusterare e impossibilità di farlo attraverso un
proxy/frontend http).
qualche info in pi� su cosa ci fai girare e come lo attivi ?
Risolti i problemi da remoto con:
server.port = 8888 # la 80 è per tomcat #server.bind = “127.0.0.1”
qualche info in pi� su cosa ci fai girare e come lo attivi ?
Una applicazione per un centro Termale su un mio server
e una applicazione di gestione richieste assistenza per una ASL su
server dell’ASL
Tutti e due Windows 2003 server
Per adesso funziona bene.
Vorrei saperne di più su Mongrel e sui problemi che potrei avere con
Lighttpd
Ciao
e una applicazione di gestione richieste assistenza per una ASL su
server dell’ASL
Tutti e due Windows 2003 server
Per adesso funziona bene.
Vorrei saperne di più su Mongrel e sui problemi che potrei avere con
Lighttpd
Brevissimamente: il primo lo usano tutti e puoi fare debug più
semplicemente (comunica tra webserver e mongrel in plain http) il
seocndo è piccolo, veloce ed occupa pochissima memoria ma lo stanno
sviluppando (il proxy module ad esempio lo stanno riscrivendo da zero
per compere con mongrel )
Con lighty se usi fastcgi/cgi e qualcosa non va non è proprio immediato
sapere
chi è che fa casino tra applicazione e web server.
Vorrei saperne di più su Mongrel e sui problemi che potrei avere con
Lighttpd
Il mod_proxy della versione attuale di lighttpd non e’ proprio il
massimo, ma
a partire dalla prossima relese (1.4.5) sara’ completamente riscritto
e dovrebbe
diventare molto piu’ solido.
Una soluzione molto flessibile e IMHO “quasi definitiva” e’ questa:
in parole povere: Pound fa da front-end (e ssl-wrapper, se serve), e
dietro fai
girare lighttpd per i contenuti statici, Mongrel per le applicazioni
Rails, e
se serve Apache con mod_php.
in parole povere: Pound fa da front-end (e ssl-wrapper, se serve), e
dietro fai
girare lighttpd per i contenuti statici, Mongrel per le applicazioni
Rails, e
se serve Apache con mod_php.
Sembra molto lavoro quando e possibile affidare tutto ad Apache, che funziona comunque molto bene anche se non e “the new thing”.
in parole povere: Pound fa da front-end (e ssl-wrapper, se serve), e
dietro fai
girare lighttpd per i contenuti statici, Mongrel per le applicazioni
Rails, e
se serve Apache con mod_php.
Sembra molto lavoro quando e possibile affidare tutto ad Apache, che funziona comunque molto bene anche se non e “the new thing”.
Beh certo, Apache lo conoscono tutti ed e’ una sicurezza, ma:
rispetto a lighttpd ha l’agilita’ di un elefante obeso
la sua configurazione non e’ scienza, e’ arte
per servire file statici, lighttpd lo batte a occhi chiusi con una
mano
legata dietro alla schiena
Il grosso punto a favore di apache e’ che il suo mod_proxy_balancer
e’ fatto
veramente bene (ma come dicevo il proxy di lighttpd 1.5 sara’ molto
meglio
di quello attuale).
Sul blog di textdrive trovi molti articoli su lighttpd, a cominciare
da questo:
Sembra molto lavoro quando e possibile affidare tutto ad Apache, che funziona comunque molto bene anche se non e “the new thing”.
Beh certo, Apache lo conoscono tutti ed e’ una sicurezza, ma:
rispetto a lighttpd ha l’agilita’ di un elefante obeso
Non e del tutto vero. Sara piu grande, perche fa piu cose. Volendo, e possibile avere un Apache abbastanza snello se uno toglie
tutta la roba come PHP.
la sua configurazione non e’ scienza, e’ arte
per servire file statici, lighttpd lo batte a occhi chiusi con una
mano
legata dietro alla schiena
Non e esattamente/sempre cosi. Vedi questo articolo:
Io ho in produzione un’applicazione con Apache per i contenuti statici e
mod_proxy che mi gira su mongrel le richieste dinamiche.
Mongrel è facilissimo da usare e se hai server windows si installa pure
come
servizio, il che non è male.
Il test cosi’ com’e’ fatto non vale molto, come si evince anche dalle
risposte
nel secondo post (lo dice l’autore medesimo).
Il suo punto non e che il suo test e perfetto, ma che neanche quelli
di lighttpd saranno tanto attendibili…
Se gente come quelli di Textdrive, che di esperienza in fatto di
webserver ne hanno
TANTA, apprezza lighttpd, un motivo ci sara’. E io mi fido di chi ha
piu’
esperienza di me
Sono tutti e due prodotti buoni e testati da tanta gente… la mia
reazione iniziale era per il X + Y + Z + A… quando magari con
un’unica soluzione si coprono tutte le esigenze.
Comunque… sono abbastanza sicuro che piu o meno tutti qua non avrebbero problemi ne con uno ne` con l’altro, vanno tutti e due
molto bene.
Non e del tutto vero. Sara piu grande, perche fa piu cose. Volendo, e possibile avere un Apache abbastanza snello se uno toglie
tutta la roba come PHP.
Ma se togli “tutta la roba”, allora tanto vale avere qualcosa di
gia’ snello in partenza come lighttpd
Non e esattamente/sempre cosi. Vedi questo articolo:
Il test cosi’ com’e’ fatto non vale molto, come si evince anche dalle
risposte
nel secondo post (lo dice l’autore medesimo).
Se gente come quelli di Textdrive, che di esperienza in fatto di
webserver ne hanno
TANTA, apprezza lighttpd, un motivo ci sara’. E io mi fido di chi ha
piu’
esperienza di me
Il punto lento sara` in ogni caso Ruby e/o il database, non il
server web.
Il punto e’ che lighttpd richiede meno risorse per ottenere
prestazioni nel peggiore dei casi identiche
ad Apache. Non dico che e’ la soluzione a tutto, solo che in molti
casi puo’ essere
una soluzione migliore. Per non parlare di prodotti come Litespeed e
Zeus che per certi versi sono
ancora migliori (ma commerciali).
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.