On Sat, Jan 04, 2014 at 12:21:30PM +0100, Manlio Perillo wrote:
> On 03/01/2014 12:50, Roberto De Ioris wrote:
> >[...]
> >provate a ridurre a 3 secondi il proxy_connect_timeout di nginx,
>
> Dato che Linux ignora l'hint sulla backlog, il parametro su cui agire è
> proxy_send_timeout.
>
> Sul wik
On 03/01/2014 12:50, Roberto De Ioris wrote:
[...]
provate a ridurre a 3 secondi il proxy_connect_timeout di nginx,
Dato che Linux ignora l'hint sulla backlog, il parametro su cui agire è
proxy_send_timeout.
Sul wiki di Nginx c'è un commento appropriato riguardo
proxy_connect_timeout:
http:/
On 03/01/2014 18:42, Alessandro Dentella wrote:
On Fri, Jan 03, 2014 at 12:45:02PM +0100, Manlio Perillo wrote:
On 03/01/2014 12:34, Alessandro Dentella wrote:
[...]
La nostra simulazione è stata fatta con 2 funzioni: is_up e blocking che usa
time.sleep()
class IsUp(tornado.web.RequestHand
On 03/01/2014 18:43, Roberto De Ioris wrote:
[...]
Io su soluzioni come gevent o microthread ho sempre questi due dubbi:
1) Usano il modello sincrono, "nascondendo" le azioni asincrone.
Questo per molti è un vantaggio, ma a me non piacciono i pattern che
ti nascondono le cose (special
2014/1/3 Manlio Perillo
>
> No, direi che è banale.
> Usi Apache + mod_wsgi e spendi tanti bei soldi in hardware :)
Ok. Quindi non riesci a farlo scalare.
>
> Vedi il fatto che su Windows hai solo l'equivalente di posix_aio ma non
> quello di epoll/kqueue. Potrei continuare all'infinito...
>
On Fri, Jan 03, 2014 at 12:50:54PM +0100, Roberto De Ioris wrote:
>
> > On Mon, Dec 30, 2013 at 05:26:57PM +0100, Roberto De Ioris wrote:
> >> > Mi pare di capire che la soluzione della listen queue che mi hai
> >> indicato
> >> > risolverebbe questo problema.
> >> >
> >>
> >>
> >> server = HTTPSe
> On 03/01/2014 18:09, Roberto De Ioris wrote:
>> [...]
>>
>> Python e' utilizzabilissimo, e' solo che devi essere "consapevole"
>> (stessa
>> cosa in ruby o in perl), poiche' ci sono diversi framework per la
>> programmazione asincrona e devi sceglierne uno (io consiglio sempre
>> gevent, ma dopo
On Fri, Jan 03, 2014 at 12:45:02PM +0100, Manlio Perillo wrote:
> On 03/01/2014 12:34, Alessandro Dentella wrote:
> >[...]
> >La nostra simulazione è stata fatta con 2 funzioni: is_up e blocking che usa
> >time.sleep()
> >
> >class IsUp(tornado.web.RequestHandler):
> >def get(self):
> >
On 03/01/2014 18:09, Roberto De Ioris wrote:
[...]
Python e' utilizzabilissimo, e' solo che devi essere "consapevole" (stessa
cosa in ruby o in perl), poiche' ci sono diversi framework per la
programmazione asincrona e devi sceglierne uno (io consiglio sempre
gevent, ma dopo averlo studiato, non
> 2014/1/3 enrico franchi
>
>>
>> 2014/1/3 Manlio Perillo
>>
>>> Per concludere, tieni conto che usare cose come Tornado è tutt'altro
>>> che
>>> banale.
>>>
>>
>> Beh, fare scalare qualcosa di non asincrono e' ancora meno banale, IMHO.
>>
>>
>>> Tutto lo stack (applicazione + framework + eventu
2014/1/3 enrico franchi
>
> 2014/1/3 Manlio Perillo
>
>> Per concludere, tieni conto che usare cose come Tornado è tutt'altro che
>> banale.
>>
>
> Beh, fare scalare qualcosa di non asincrono e' ancora meno banale, IMHO.
>
>
>> Tutto lo stack (applicazione + framework + eventuali librerie) deve
On 03/01/2014 16:41, enrico franchi wrote:
2014/1/3 Manlio Perillo mailto:manlio.peri...@gmail.com>>
Per concludere, tieni conto che usare cose come Tornado è tutt'altro
che banale.
Beh, fare scalare qualcosa di non asincrono e' ancora meno banale, IMHO.
No, direi che è banale.
Usi
Ok, grazie, stupido io non avevo fatto caso alle versioni.
Ora provo a pastrocchiare un po' mentre aspetto Alessandro :)
Luca
Il giorno 03 gennaio 2014 15:09, Roberto De Ioris ha
scritto:
>
> > nono, ho controllato
> >
> > (wall)root@wadev:/dati/wall# python -c"import greenlet;print
> > green
2014/1/3 Manlio Perillo
> Per concludere, tieni conto che usare cose come Tornado è tutt'altro che
> banale.
>
Beh, fare scalare qualcosa di non asincrono e' ancora meno banale, IMHO.
> Tutto lo stack (applicazione + framework + eventuali librerie) deve essere
> sviluppato con la programmazion
> nono, ho controllato
>
> (wall)root@wadev:/dati/wall# python -c"import greenlet;print
> greenlet.__version__"
> 0.4.1
>
Mi ero perso il pezzo in cui dicevi di aver istallato greenlet dai
pacchetti di ubuntu.
Devi usare la stessa versione di greenlet nel venv usata per compilare
uWSGI, probabil
nono, ho controllato
(wall)root@wadev:/dati/wall# python -c"import greenlet;print
greenlet.__version__"
0.4.1
2014/1/3 Roberto De Ioris
>
> > Ok, come diceva Alessandro in realtà non siamo nemmeno riusciti a fare
> > dei test con uWSGI e il plugin perchè da errori di Segmentation Fault
> > us
> Ok, come diceva Alessandro in realtà non siamo nemmeno riusciti a fare
> dei test con uWSGI e il plugin perchè da errori di Segmentation Fault
> usando --tornado 100 e --greenlet. Ma usando solo --tornado 100 da
> questo errore:
> *** DANGER *** tornado mode without coroutine/greenthread engine
Ok, come diceva Alessandro in realtà non siamo nemmeno riusciti a fare
dei test con uWSGI e il plugin perchè da errori di Segmentation Fault
usando --tornado 100 e --greenlet. Ma usando solo --tornado 100 da
questo errore:
*** DANGER *** tornado mode without coroutine/greenthread engine loaded !!!
> On Mon, Dec 30, 2013 at 05:26:57PM +0100, Roberto De Ioris wrote:
>> > Mi pare di capire che la soluzione della listen queue che mi hai
>> indicato
>> > risolverebbe questo problema.
>> >
>>
>>
>> server = HTTPServer(app)
>> server.bind(post, backlog=1)
>>
>> (prova anche con zero, su alcuni ker
On 03/01/2014 12:34, Alessandro Dentella wrote:
[...]
La nostra simulazione è stata fatta con 2 funzioni: is_up e blocking che usa
time.sleep()
class IsUp(tornado.web.RequestHandler):
def get(self):
self.write("Is Up Porta %d" ...)
self.finish()
class Blockin
On Mon, Dec 30, 2013 at 05:26:57PM +0100, Roberto De Ioris wrote:
> > Mi pare di capire che la soluzione della listen queue che mi hai indicato
> > risolverebbe questo problema.
> >
>
>
> server = HTTPServer(app)
> server.bind(post, backlog=1)
>
> (prova anche con zero, su alcuni kernel funziona
> On Tue, Dec 24, 2013 at 11:58:05AM +0100, Roberto De Ioris wrote:
>>
>>
>> >
>> > 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 passar
On Tue, Dec 24, 2013 at 11:58:05AM +0100, Roberto De Ioris wrote:
>
>
> >
> > 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
On 24/12/2013 11:58, Roberto De Ioris wrote:
[...]
L'approccio migliore (o meglio diciamo quello risolutivo) e' che i
processi usino lo stesso socket, puoi provare il plugin tornado di uWSGI:
http://uwsgi-docs.readthedocs.org/en/latest/Tornado.html
ma non e' compilato di default (per motivi alt
>
> 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.
>
>
>> aggan
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;
> >
> 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
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 vo
28 matches
Mail list logo
