Non c'è molta documentazione su come distribuire un progetto Django con Spawning eppure le persone lo raccomandano su apache/mod_wsgi.Come distribuire Django con spawning
In another similar question, altri utenti SO mi hanno suggerito di aprire una nuova domanda specifica per lo spawning, quindi speriamo che anche altri possano condividere le loro esperienze.
Sarei interessato a vedere il cui Spawning consiglia vivamente su Apache e mod_python o mod_wsgi.
A giudicare dal fatto che questa domanda è ora il risultato n. 4 in Google per "django spawning", direi che è molto presto. :) Se stai mettendo qualcosa di serio in produzione, per ora rimani con Apache/mod_wsgi.
Eric Florenzo ha fatto un po 'di basic testing of spawning. Assicurati di leggere tutti i commenti e il post principale.
Personalmente mi piace sempre indagare su questo tipo di soluzioni, ma in questo caso non riesco nemmeno ad arrivare ad una fase di benchmarking. Ci sono troppe funzioni importanti di cui ho bisogno in Apache (ssl client certs, esegui server mongrel sotto fastcgi, django sotto wsgi, php gasp, file statici serviti direttamente, ssl per ogni indirizzo ip, dozzine di host virtuali su più indirizzi IP, eccetera.).
cd nella directory settings.py del tuo django.
Ecco la riga di comando per servire la vostra applicazione Django
spawn --factory=spawning.django_factory.config_factory settings --port 80
Questo dovrebbe essere fatto di nuovo se il server è stato riavviato? –
Sì, potrei consigliare di utilizzare la deposizione delle uova nel corso di installazione apache/WSGI.
Due motivi essenzialmente: utilizzo 1) Memoria (si risparmia qualche MB di deposizione delle uova) 2) codice dinamico di ricarica (in nessun punto del tempo, del vostro utente vedrà una pagina 404 o 500)
Questo deriva dall'esperienza, sto eseguendo http://tunesdiary.com su spawning + nginx in questa configurazione:
nginx gestisce tutto il carico in entrata che ha una ulteriore connessione proxy allo spawning che sta ascoltando su una porta non privilegiata (significa spawning in esecuzione come utente diverso da il web-server) Lo spawning genera 4 processi con 2 thread per processo. (funziona per il carico corrente).
Mentre spingo qualsiasi codice sul server, vengono gestite le richieste precedenti e quindi il nuovo codice inizia a servire le nuove richieste.
Questo ha lavorato molto bene fino ad ora (sto facendo funzionare questo da circa 6 mesi)
quello che ho osservato, Django con WSGI mod + apache (che ho usato per alcuni giorni prima) stava prendendo su 70 MB di RAM dopo l'avvio (processo singolo) e questa configurazione utilizza 45 MB per processo o giù di lì. Inoltre, ho anche avuto questo con lighttpd + modfcgi che consuma anche quasi la stessa quantità di memoria di spwaning.
(I potrebbe avere sbagliato i calcoli perché in apache, l'utilizzo della memoria del server web è anche incluso)
Potete contare su di deposizione delle uova, per quanto posso dire, ma se se non si ha realmente spingere spesso, non sarà di grande utilità
+1. Ho visto alcune persone parlare di giocare con Spawning, ma devo ancora sapere di un singolo serio sito di produzione che lo sta usando (per non dire che non ce n'è uno). AFAICT lo slancio è ancora con Apache/mod_wsgi. –
lighttpd e nginx sono più gravi – user20955
Ho fatto una domanda relativa all'overhead di Apache quando uso mod_wsgi e ho avuto un po 'di voti per le persone che hanno generato ... http://stackoverflow.com/questions/488864/django-deployment -cutting-apaches-overhead –