[Python] Deploy con nginx e proxy_pass

[Alessandro Dentella]

On Tue, Dec 24, 2013 at 09:19:19AM +0100, Roberto De Ioris wrote:
> 
> > Ciao a tutti,
> >
> > ho bisogno di capire una configurazione di un webs server nginx di un
> > cliente che usa proxy_pass passando come destinatario
> >
> >     upstream produzione {
> >         server 127.0.0.1:8080;
> >         server 127.0.0.1:8081;
> >         ...
> >     }
> >     proxy_pass http://produzione;
> >
> >
> > Quello che vorrei capire è come funziona e se è configurabile il
> > meccanismo
> > di assegnazione della richiesta ai vari server.
> >
> > Il problema nasce dal fatto che hanno una applicazione fatta con tornado
> > ma
> > con chiamate non asincrone, ed una base di codice che si sono sviluppati
> > negli anni e che non hanno il coraggio/determinazione di cambiare.
> > il 99% delle funzioni prende meno di 1 secondo ma acunin prendono anche 10
> > secondi fino a 25 e questo è accettabile.
> >
> > Il problema nasce dal fatto che in alcuni casi sperimentano dei blocchi.
> >
> > La mia sensazione (e qui paleso la mia ignoranza in merito) è che nginx
> > faccia round robbin fra i 10 processi esistenti e non stia a guardare se
> > hanno terminato o meno la precedente richiesta. Esiste un modo di forzare
> > uno schema per cui vengano serviti solo i processi che non hanno in corso
> > una elaborazione?
> >
> > NB: non esiste un problema di troppo carico, il server è sostanzialmente
> >     sottosfruttato, il sito non ha un carico elevato
> >
> > Sono graditi anche puntatori a letture illuminanti...
> >
> > grazie
> > sandro
> > *:-)
> > _______________________________________________
> >
> 
> Nelle release > 1.3 di nginx puoi impostare il least connections come
> algoritmo:
> 
> http://nginx.org/en/docs/http/ngx_http_upstream_module.html#least_conn

grazie, leggo nella doc:

 Specifies that a group should use a load balancing method where a request is
 passed to the server with the least number of active connections, taking
 into account weights of servers. If there are several such servers, they are
 tried using a weighted round-robin balancing method.

ed immagino che le active connections siano esattamente quelle in
elaborazione. Considerando che ho 10 processi, il 99% delle richieste viene
espletato in meno di 1 secondo e ho un rate che nelle ore "di punta" arriva
a 2/secondo credo che sia molto probabile che ci sia sempre un processo
libero e che quindi questo venga scelto da questo algoritmo, se lo capisco
correttamente. 

> ma ho seri dubbi che il problema sia li', appena hai scritto "tornado con
> chiamate non asincrone", hai praticamente descritto IL problema ;)

Vero, ma questa è una eredità su cui non ho potere...  per bypassarlo avevo
modificato il codice per potere girare con svariati (10 al momento) processi
indipendenti, ora è così ed in effetti la situazione è abbastanza gestibile
con l'eccezione dei blocchi descritti sopra.

io sono convinto che se il modello resta round robbin puro, anche se
raddoppiassi i processi avrei solo dimezzato la probabilità di incapare in
una chiamata "lunga", mentre se potessi evitare di passare chiamate ad un
processo che sta lavorando eviterei proprio questa cosa.


> aggancia una strace ai processi tornado durante un blocco per vedere che
> succede. Probabilmente non ci sara' molto da fare se non aggiungere altri
> processi tornado (sempre che sia tollerabile dall'applicazione).

le chiamate lunghe non sono chiamate che a random prendono tanto tempo, sono
chiamate che "fanno molte cose" probabilmente non ottimizzate, ma sulle
quali io non ho diretto controllo (sono inizializzazioni mensili di alcune
posizioni).

Grazie per il suggeriemnto
sandro
*:-)



-- 
Sandro Dentella  *:-)
http://www.reteisi.org             Soluzioni libere per le scuole
http://sqlkit.argolinux.org        SQLkit home page - PyGTK/python/sqlalchemy




sandro
*:-)