Intendo utilizzare un singolo VPS per distribuire più app CherryPy a basso traffico come sottodirectory; es example.com/app1, example.com/app2ecc

Dopo aver effettuato ricerche sulla distribuzione WSGI, sembra che il metodo preferito per distribuire app sia utilizzare un server WSGI (Gunicorn, uWSGI, ecc.) E NGinx in una configurazione proxy inverso. Sembra eccessivo usare due webserver in tandem - specialmente perché la mia app CherryPy è essa stessa un server web - ma non voglio respingere l'idea come appare ovunque . Non sono certo un esperto, quindi mi piacerebbe discuterne.

Vedo tre opzioni:

• Distribuisci CherryPy da solo.
• Distribuisci sotto Gunicorn o un altro server WSGI.
• Distribuisci sotto un server WSGI e esegui il reverse-proxy su NGinx, che sembra essere la soluzione di tutti.

Le mie domande:

• Qual è la ragione principale per cui vedo questo schema ovunque? Nginx è solo che bene?
• Per le app a basso traffico, il server CherryPy nativo è abbastanza buono o non dovrei nemmeno provare?

Ogni consiglio è apprezzato, grazie.

Il motivo per cui tutti mettono nginx (o un altro server come Apache) davanti ai loro server di app è che tutti hanno contenuti statici come immagini, CSS e JavaScript e strani requisiti unici per la loro applicazione.

Il server delle app (CherryPy, gunicorn, qualunque cosa) è ottimizzato per eseguire l'app e pubblicarne l'output. Sebbene il server app possa anche servire contenuto statico, non sono quasi mai ottimizzati per questa attività, poiché è secondario rispetto allo scopo principale del server app. (Alcuni server di app aiuteranno anche minimizzando e comprimendo CSS e JS, in modo che il server Web di fronte possa servire queste risorse ancora più velocemente.)

Inoltre, l'attuale server Web può fare molto di più rispetto alla pubblicazione di contenuti ad alte prestazioni. Cose come la memorizzazione nella cache, la manipolazione delle intestazioni, la riscrittura degli URL, la geolocalizzazione e molte altre funzionalità che non farebbero altro che gonfiare il server delle app senza un buon scopo.

In genere si esegue l'app server da solo solo quando si sviluppa l'applicazione, quando si è l'unico utente e le prestazioni non sono un problema. Anche se il tuo sito è a basso traffico, vorresti che fosse più veloce, giusto? I siti a basso traffico che sono lenti generalmente non crescono in siti ad alto traffico ...

Perché le persone mettono Nginx in primo piano?

1. Nginx è un server Web asincrono. Significa che non dedica un thread o un processo per connessione. Utilizza invece la libreria di polling socket preferita del sistema operativo ed è quindi in grado di gestire centinaia di migliaia di connessioni. Perché dovresti occuparti, come sviluppatore di applicazioni? Perché Nginx memorizza nel buffer le connessioni e passa la richiesta all'istanza di CherryPy upstream solo quando la richiesta è stata completamente letta. Lo stesso per le risposte. In questo modo l'applicazione CherryPy, che è un server threaded, dietro Nginx in molti sensi, diventa asincrona. In particolare, si fa un cenno a un problema client lento e attacchi loris DOS lenti.
2. Nginx ha un limite di velocità di connessione pronto all'uso. Dì, non voglio più di 8 connessioni simultanee dallo stesso IP.
3. CherryPy ha un problema SSL . Nginx no.
4. Python può inviare byte avanti e indietro quasi quanto C C. Python zlibè solo un wrapper per la libreria C. Ma poiché Nginx gestisce la connessione in modo efficace, è una buona idea alleviare i thread del lavoratore CherryPy dal servire contenuto statico in produzione e dedicarsi solo al contenuto dinamico.
5. Multiplexing di più istanze CherryPy sulla stessa porta, dominio, percorso, ecc. Flessibilità generalmente aggiuntiva di un altro livello di configurazione.

È sicuro usare CherryPy da solo?

Secondo uno degli autori originali, sì . La maggior parte delle cose rilevanti per il web che puoi fare con CherryPy da solo.

CherryPy ha un'idea di un'applicazione e puoi servire diverse applicazioni con un'istanza CherryPy. CherryPy può anche servire altre applicazioni WSGI .

Distribuzione di CherryPy

In una distribuzione tradizionale in stile * nix scrivi script di script, demonizza i tuoi processi, elimina i suoi privilegi, scrivi il suo PID, ecc. Non è un grosso problema quando hai un paio di istanze CherryPy. Quando hai dozzine, diventa noioso e ha senso trasferire la gestione dei processi a Gunicorn o uWGSI e cambiare le tue istanze CherryPy da HTTP a WSGI.

Ho scritto uno scheletro tutorial / progetto, cherrypy-webapp-skeleton , il cui obiettivo era colmare le lacune per la distribuzione (tradizionale) di un'applicazione CherryPy reale su Debian per uno sviluppatore web.

Incartare

1. Traffico ridotto, nessun requisito speciale → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. Requisiti speciali per traffico elevato → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Dozzine di istanze CherryPy separate sullo stesso server, desiderose di sovraccaricare la soluzione di tutti → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.