Configurazione del server più pulita e veloce per Django [chiuso]

StackOverflow https://stackoverflow.com/questions/26025

  •  09-06-2019
  •  | 
  •  

Domanda

Sto per implementare un sito di medie dimensioni basato su Django.Ho un server Ubuntu dedicato.

Sono davvero confuso su quale software server utilizzare.Quindi ho pensato tra me:perché non chiedere a StackOverflow.

Quello che sto cercando è:

  • Facile da configurare
  • Veloce e facile da usare con le risorse
  • Può servire file multimediali
  • In grado di servire più djangosites sullo stesso server
  • Preferirei non installare PHP o qualsiasi altra cosa che risucchia risorse e di cui non so che farsene.

Ho sentito parlare di mod_wsgi e mod_python su Apache, nginx e lighty.Quali sono i pro e i contro di questi e mi è mancato qualcuno?

@Barry:In qualche modo ho la sensazione che Apache sia troppo gonfio per me.E le alternative?

@BrianLy:Ok, controllerò ancora un po' mod_wsgi.Ma perché ho bisogno di Apache se servo file statici con Lighty?Sono anche riuscito a servire l'app Django stessa con lighty.E' comunque una cosa brutta?Scusa se sono stato così stupido :-)

AGGIORNAMENTO:Che dire di lighty e nginx: quali sono i casi d'uso in cui questi sono la scelta perfetta?

È stato utile?

Soluzione

Poiché stavo cercando risposte più approfondite, ho deciso di approfondire personalmente la questione.Per favore fatemi sapere se ho frainteso qualcosa.

Alcune raccomandazioni generali riguardano l'utilizzo di un server Web separato per la gestione dei contenuti multimediali.Per separato intendo un server web su cui non è in esecuzione Django.Questo server può essere ad esempio:

  • Leggerotpd (Leggero)
  • Nginx (EngineX)
  • O qualche altro server leggero

Quindi, per Django, puoi percorrere strade diverse.Puoi:

  • Servi Django tramite Apache E:

    • mod_python

      Questo è il modo stabile e consigliato/ben documentato.Contro:utilizza molta memoria.

    • mod_wsgi

      Da quello che ho capito, mod_wsgi è un'alternativa più recente.Sembra essere più veloce e più facile da usare in termini di risorse.

    • mod_fastcgi

      Quando usi FastCGI stai delegando la fornitura di Django a un altro processo.Poiché mod_python include un interprete Python in ogni richiesta, utilizza molta memoria.Questo è un modo per aggirare il problema.Inoltre ci sono alcuni problemi di sicurezza.

      Quello che fai è avviare il tuo server Django FastCGI in un processo separato e quindi configurare Apache tramite riscritture per chiamare questo processo quando necessario.

O puoi:

  • Servi Django senza usare Apache ma con un altro server che supporta nativamente FastCGI:

    (La documentazione menziona che puoi farlo se non hai esigenze specifiche di Apache.Immagino che il motivo debba essere quello di risparmiare memoria.)

    • Lighttpd

    Questo è il server che esegue Youtube.Sembra veloce e facile da usare, tuttavia ho visto segnalazioni di perdite di memoria.

    • nginx

    Ho visto benchmark che affermano che questo server è persino più veloce di lighttpd.Tuttavia è per lo più documentato in russo.

Un'altra cosa, a causa delle limitazioni di Python, il tuo server dovrebbe essere eseguito in modalità fork, non thread.

Quindi questa è la mia ricerca attuale, ma voglio più opinioni ed esperienze.

Altri suggerimenti

sto usando Cherokee.

Secondo i loro parametri di riferimento (granello di sale con loro), gestisce il carico meglio sia di Lighttpd che di nginx...Ma non è per questo che lo uso.

Lo uso perché se digiti cherokee-admin, avvia un nuovo server a cui puoi accedere (con una password monouso) e configurare l'intero server tramite un webmin ben fatto.Questa è una caratteristica killer.Mi ha già salvato a quantità di tempo.E sta facendo risparmiare molte risorse al mio server!

Per quanto riguarda Django, lo sto eseguendo come processo SCGI con thread.Funziona bene.Anche Cherokee può mantenerlo in funzione.Ancora una volta, caratteristica molto bella.

L'attuale versione del repository di Ubuntu è molto vecchia, quindi ti consiglio di utilizzarla il loro PPA.Buona fortuna.

Come ha detto @Barry, la documentazione utilizza mod_python.Non ho usato Ubuntu come server, ma ho avuto una buona esperienza con mod_wsgi su Solaris.Puoi trovare la documentazione per mod_wsgi e Django sul mod_wsgi luogo.

Un rapido esame delle tue esigenze:

  • Facile da configurare Ho trovato Apache 2.2 abbastanza facile da costruire e installare.
  • Veloce e facile da usare con le risorse Direi che questo dipende dal tuo utilizzo e dal traffico.* Potresti non voler server tutti i file utilizzando Apache e utilizzare TPD leggero (leggero) ai file statici del server.
  • Può servire file multimediali Presumo che intendi immagini, file flash?Apache può farlo.
  • Più siti sullo stesso server Hosting di server virtuale su Apache.
  • Piuttosto non installare altre estensioni Commenta tutto ciò che non desideri nella configurazione di Apache.

Il modo ufficialmente consigliato per distribuire un progetto Django è utilizzare mod_python con apache.Questo è descritto in la documentazione. Il vantaggio principale è che si tratta del modo di distribuzione meglio documentato, più supportato e più comune.Lo svantaggio è che probabilmente non è il più veloce.

La migliore configurazione non è così conosciuta, credo.Ma ecco:

  1. Utilizza nginx per servire le richieste (da dinamica all'app, direttamente dal contenuto statico).
  2. Utilizza il server Web Python per fornire contenuti dinamici.

Le due soluzioni più veloci per il server Web basato su Python sono:

Devi cercare su Google per trovare la migliore configurazione attuale per Django (ancora in sviluppo).

Sto usando nginx (0.6.32 tratto da Sid) con mod_wsgi.Funziona molto bene, anche se non posso dire se sia migliore delle alternative perché non ne ho mai provato nessuna.Nginx ha memcached supporto integrato, che può forse interagire con il middleware di caching di Django (in realtà non lo uso, invece riempio manualmente la cache usando python-memcache e lo invalido quando vengono apportate modifiche), quindi i risultati della cache ignorano completamente Django (il mio sviluppo la macchina può servire circa 3000 richieste al secondo).

Un avvertimento:nginx' mod_wsgi detesta fortemente le posizioni con nome (cerca di trasmetterle SCRIPT_NAME), quindi l'ovvio "error_page 404 = @djangocauserà numerosi errori oscuri.Ho dovuto patchare il codice sorgente mod_wsgi per risolvere il problema.

Anche io faccio fatica a capire tutte le opzioni.In questo post del blog Ho trovato spiegati alcuni vantaggi di mod_wsgi rispetto a mod_python.

Più siti a basso traffico su un piccolo VPS rendono il consumo di RAM la preoccupazione principale e mod_python sembra una pessima opzione in questo caso.Utilizzando lighttpd e FastCGI, sono riuscito a ottenere l'utilizzo minimo della memoria di un semplice sito Django fino a 58 MiB virtuali e 6,5 MiB residenti (dopo aver riavviato e servito una singola richiesta non pesante di RAM).

Ho notato che l'aggiornamento da Python 2.4 a 2.5 su Debian Etch ha aumentato di una piccola percentuale l'impronta di memoria minima dei processi Python.D'altra parte, la migliore gestione della memoria della versione 2.5 potrebbe avere un effetto opposto maggiore sui processi di lunga durata.

Mantienilo semplice: Django consiglia Apache e mod_wsgi (o mod_python).Se servire file multimediali rappresenta una parte molto importante del tuo servizio, prendi in considerazione Amazon S3 o Rackspace CloudFiles.

Secondo me lo stack migliore/più veloce è paint-nginx-uwsgi-django.E lo sto usando con successo.

Se usi lighthttpd, puoi anche usare FastCGI per servire Django.Non sono sicuro di come la velocità sia paragonabile a mod_wsgi, ma se la memoria funziona correttamente, ottieni un paio dei vantaggi che otterresti con mod_wsgi che non otterresti con mod_python.Il principale è che puoi assegnare a ciascuna applicazione il proprio processo (il che è davvero utile per mantenere separata la memoria di diverse app e per sfruttare i computer multi-core.

Modificare:Giusto per aggiungere riguardo al tuo aggiornamento su nginix, se la memoria funziona di nuovo correttamente, nginix utilizza "greenlet" per gestire la concorrenza.Ciò significa che potrebbe essere necessario essere un po' più attenti per assicurarsi che un'app non consumi tutto il tempo del server.

Utilizziamo nginx e FastCGI per tutte le nostre implementazioni Django.Ciò è dovuto principalmente al fatto che di solito distribuiamo su Slicehost e non vogliamo donare tutta la nostra memoria ad Apache.Immagino che questo sarebbe il nostro "caso d'uso".

Per quanto riguarda le osservazioni sulla documentazione prevalentemente in russo, ho trovato la maggior parte delle informazioni sul file Wiki inglese essere molto utile e preciso.Questo sito ha anche configurazioni di esempio per Django, da cui puoi modificare la tua configurazione nginx.

Esistono molti modi per farlo. Per questo motivo, consiglio di leggere attentamente l'articolo relativo al processo di distribuzione su DjangoAdvent.com:Eric Florenzano - Distribuzione di Django con FastCGI: http://djangoadvent.com/1.2/deploying-django-site-using-fastcgi/ Leggi anche:Mike Malone - Scaling di Django StochasTeChnologies Blog:Il Blog perfetto Django Setup Mikkel Hoegh:35% Miglioramento del tempo di risposta-commutazione-uwsgi-nginx

Saluti

Ho un avvertimento per l'utilizzo di Cherokee.Quando apporti modifiche a Django Cherokee mantiene il VECCHIO processo, invece di terminarlo e iniziarne uno nuovo.

Su Apache consiglio vivamente questo articolo.

http://www.djangofoo.com/17/django-mod_wsgi-deploy-exampl

È facile da configurare, facile da eliminare o ripristinare dopo aver apportato modifiche.

Basta digitare il terminale

sudo /etc/init.d/apache2 restart

e i cambiamenti si vedono immediatamente.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top