Subsections
Siete giunti ad avere un grosso sito su cui avete speso settimane di lavoro per approntarlo.
E siete finalmente pronti per farlo usare al mondo !
Ma state ancora decidendo come utilizzarlo, il che significa: come configurarlo per le macchine di produzione.
Durante la fase di sviluppo del vostro sito, siete i soli (forse con qualche altro sviluppatore) ad accedere al sito, così non è necessario sia veloce e robusto. Ma ad un sito per la produzione accederanno molte persone (se siete fortunati). Il che comporta la scelta di una configurazione
del CherryPy appropriata in modo da provvedere un servizio veloce e costante ai vostri utenti.
Un criterio per aiutarvi a scegliere una configurazione, include:
- Cosa vi permette di fare il vostro hosting provider ? Se usate una macchina condivisa,
potreste non poter fare cosa volete.
Per esempio, potreste solo poter usare CGI, e il vostro hosting provider potrebbe solo
provvedere un hosting virtuale basato su Apache.
- Quanto traffico prevedete di avere ? Prevedete di avere solo qualche centinaio di utenti al giorno o alcune decine di migliaia ?
- Di quante macchine/processori disponete ? Se prevedete di avere molto traffico, potrebbe essere meglio usare alcune macchine/processori (che potrebbero avere un discreto costo).
- Avrete un webmaster per controllare il vostro sito ? Se non avete nessuno che controlli il vostro sito, potreste volere che il sito riparta automaticamente in caso di crash.
Notate che c'è un HowTo chiamato "Sample deployment configuration for a
real-world website" che contiene un esempio completo di configurazione raccomandato per la maggior parte dei siti.
La prima decisione da prendere è se usare CherryPy HTTP server direttamente o dietro in altro
webserver come Apache.
Ecco una lista di vantaggi per ogni metodo:
- E' più veloce e usa meno risorse (nessun processo Apache e nessuna necessità di dialogo
tra Apache e CherryPy)
- E' facile da implementare
- Potrebbe esser più veloce per contenuti statici (come immagini)
- Hosting provider potrebbe forzare l'uso di Apache
Una volta deciso se usare CherryPy direttamente o dietro un altro webserver, dovrete decidere fra alcune configurazioni...
Le sezioni che seguono vi mostreranno le diverse opzioni e i loro vantaggi/svantaggi:
Spiegazione: il CherryPy HTTP server verrà eseguito in solo thread/process. Durante l'esame di una richiesta, non ci possono essere altre connessioni.
Vantaggi:
- Velocità su ogni richiesta (nessuna necessità di creare un processo per ogni richiesta)
Svantaggi:
- Non possono essere esaminate richieste concorrenti
Conclusione: Questo è il metodo di default e funziona bene per la fase di sviluppo,
ma dovrebbe essere vietata per la produzione se avrete diversi utenti che accedono al sito nello stesso momento.
Spiegazione: il CherryPy HTTP server creerà un nuovo processo
per esaminare ogni richiesta. Dopo che è stata inviata la risposta, il processo viene distrutto.
Vantaggi:
- Possibilità di esaminare richieste multiple allo stesso tempo.
- Su una macchina multiprocessore, un forking server trarrà vantaggio dai processori multipli.
Svantaggi:
- La creazione di un processo per ogni richiesta potrebbe prendere diverse risorse (specialmente se le richieste arrivano molto velocemente)
- Forking non funziona su Windows
- Non si possono usare le sessioni in modo semplice così come non si possono facilmente condividere session data tra processi.
Conclusione: Questo metodo può essere usato su sistemi non-Windows se il traffico non è molto elevato.
Spiegazione: il CherryPy HTTP server creerà un nuovo thread per esaminare ogni richiesta. Dopo la risposta, il thread è distrutto.
Vantaggi:
- Possibilità di esaminare più richieste alla volta
- Funziona su tutte le piattaforme (incluso Windows)
Svantaggi:
- Potrebbe essere dispendioso in fatto di risorse creare un nuovo thread per ogni richiesta (benché meno dispendioso rispetto ai processi) specialmente se le richieste arrivano molto velocemente
- Su macchine multiprocessore, un threading server non trarrà vantaggio dai processori multipli ( a causa del global interpreter lock del Python)
Conclusione: Questo metodo può essere usato per siti con un traffico non molto alto.
Spiegazione: in questo caso il CherryPy HTTP server creerà un numero fissato di processi all'avvio i quali persisteranno tutto il tempo di vita del server. Se un processo è occupato ad esaminare una richiesta e ne arriva un'altra, un altro processo si prenderà in carico l'esame di questa nuova richiesta.
Vantaggi:
- Possono essere esaminte più richieste alla volta
- Veloce, dato che non c'è bisogno di creare un thread o un processo per ogni richiesta
- Trae vantaggio da macchine multiprocessore
Svantaggi:
- Non funziona sotto Windows
- Non si possono usare le sessioni in modo semplice così come non si possono facilmente condividere session data tra processi.
Conclusione: Questo metodo funziona bene su macchine non-Windows a finché non arrivano
centinaia di utenti concorrenti.
Spiegazione: questo è il caso un cui il CherryPy HTTP server creerà un numero fissato di thread all'avvio e questi rimarrano attivi per tutto il tempo di vita del server. Se un thread
è occupato ad esaminare una richiesta e arriva un'altra richiesta, questa viene presa in carico da un altro thread.
Vantaggi:
- Possono essere esaminate più richieste alla volta
- Veloce, perché non sarà creato un thread o un processo per ogni richiesta
Svantaggi:
- Non trae vantaggio da macchine multiprocessore
- Il numero dei thread non aumenta se abbiamo più utenti concorrenti
Conclusione: Questo metodo funziona molto bene ed è quello raccomandato in molti casi (finché non ci sono centinaia di utenti concorrenti).
Se avete realmente molto traffico e i metodi sin qui presentanti non sono sufficienti
o non potete usarli (se per esempio usate Windows), potete allora usare un generico load-balancing. C'è un HowTo nella documentazione che ne parla.
Tutte le configurazioni descritte nella precedente sezione sono disponibili anche utilizzando
CherryPy dietro un altro webserver. Webserver di terze parti sono generalmente
multi-thread o multi-processo. C'è un HowTo nella documentazione che spiega la configurazione
in questo caso.
Segue una lista di opzioni che sono usate per specificare come sarà utilizzato il CherryPy server. Tutte queste opzioni sono poste nella sezione [server] del file di configurazione. (confronta il capitolo "Configurare CherryPy").
- socketPort: indica su che porta il server dovrebbe essere in ascolto: Per esempio:
- socketHost: indica l'indirizzo del server (di default è localhost). Esempio:
[server]
socketHost=192.168.0.23
- socketFile: usata solo in Unix, se vogliamo usare un socket AF_UNIX invece di un
socket AF_INET. Esempio:
[server]
socketFile=/tmp/mySocket.soc
- forking: ponete questa a 1 se volete un forking server. Esempio:
[server]
socketPort=80
forking=1
- threading: ponete questa a 1 se volete un threading server. Esempio:
[server]
socketPort=80
threading=1
- processPool: ponete questa a n (n>1) se volete creare n processi all'avvio del server. Esempio:
[server]
socketPort=80
processPool=10
- threadPool: ponete questa a n (n>1) se volete creare n thread all'avvio del server. Esempio:
[server]
socketPort=80
threadPool=10
- reverseDNS: ponete questa a 1 se volete abilitare un reverse DNS (in questo modo il nome completo del dominio dei client sarà scritto nei log). Di default è 0. Esempio:
[server]
socketPort=80
reverseDNS=1
- socketQueueSize: dimensione della coda del socket (questo valore sarà passato alla funzione listen()). Il default è 5: Esempio:
[server]
socketPort=80
socketQueueSize=5
- sslKeyFile e sslCertificateFile: usate se avete un server SSL. C'è un HowTo nella documentazione per questo.
- xmlRpc: usata se avete un server XML-RPC. C'è un HowTo nella documentazione per questo.
Alcune di queste opzioni non possono ovviamente essere usate insieme altrimenti causerebbero un conflitto:
- socketFile e socketPort ovviamente entrano in conflitto una con l'altra
- threading, forking, processPool e threadPool entrano in conflitto tra loro
See About this document... for information on suggesting changes.