Re: [Python] Rimpiazzare Orbited
On 04/01/2014 06:44 PM, Daniele Varrazzo wrote: Il problema di scalabilità che stiamo avendo è che i nostri nodi frontend fanno *tante cose* diverse, con diversi pattern di concorrenza (alcune richieste web che nascono e muoiono, alcuni greenlet a lunga durata, uno molto assetato di cpu...) Secondo me stiamo mettendo in crisi lo scheduler di greenlet con troppi lavori troppo eterogenei. Nell'ottica di suddividere i processi in oggetti più indipendenti un message broker come era orbited mi ci stava troppo bene (per esempio per mettere in un processo esterno quel greenlet assetato: potrebbe mandare i messaggi che genera direttamente alle pagine web passando per il broker e saltando il web server). Non so quanto lo scenario sia vicino al tuo, comunque ti riassumo il mio orientamento per un sistema web a cui tra un po' dovrei iniziare a lavorare. Per l'esecuzione dei task (di vario tipo e durata) da parte del backend pensavo di affidarmi a celery, mentre per il monitoraggio dei task e la pubblicazione in generale, pensavo di usare socketio lato client e gevent-socketio lato server. Se qualcuno ha suggerimenti o dritte da darmi, e' il benvenuto :) -- Marco Buttu INAF-Osservatorio Astronomico di Cagliari Via della Scienza n. 5, 09047 Selargius (CA) Phone: 070 711 80 217 Email: mbu...@oa-cagliari.inaf.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Rimpiazzare Orbited
On 2014-04-01 16:38, Roberto De Ioris wrote: Ciao, un mio collega ha avuto la brillante idea di togliere Orbited da un sistema web push che abbiamo, perchè voleva passare ai websocket. Così dall'avere N web server python che pushavano messaggi ad un singolo orbited (che non ha mai fatto pio) e i client web che li ricevevano sui loro canali siamo passati ad avere ogni client collegato con una connessione websocket persistente al server. Coincidentalmente da quel giorno abbiamo cominciato a incontrare mille problemi e il programma non scala più bene, chissà come mai... Sto provando a insistere a reintrodurre il message broker perché sono convinto che ci ha parato le chiap^W spalle per anni ma lui non vuole recedere dai websocket. Secondo me un broker ci vuole, anche per come immagino il futuro di quel sistema. Fatico a trovare un rimpiazzo drop-in di orbited su websocket: qualcosa a cui i client web si connettono su un canale e altri processi possono mandare messaggi sui canali che decidono. Sapete se esiste qualcosa del genere o se è necessario passare ad un server AMQP (RabbitMQ etc.)? Conosceta Autobahn, sapete se è promettente? Vedo che usa l'ennesimo nuovo protocollo di message passing, WAMP invece di Stomp... oddio ma quanti ne servono? Altre alternative? Scrivo qui perchè il mio collega ha letto del supporto uWSGI ai websocket ma io credo che si riferisca ad avere connessioni al server, non un message broker a sé stante. Giusto Roberto? gia', pero' combinarlo con redis e una coda pub/sub e' relativamente semplice (e soprattutto rapido). Fammi pure contattare dal tuo collega, magari ne uscite senza un bagno di sangue... La logica e' che l'app WSGI instaura la sessione websocket e resta in ascolto anche su redis, ogni volta che c'e' un messaggio sul canale websocket questo viene girato a redis, ogni volta che c'e' un messaggio su redis viene passato al websocket. E' molto efficiente, noi lo usiamo per i videogiochi dove la velocita' e' essenziale. Capisco, grazie. Il problema di scalabilità che stiamo avendo è che i nostri nodi frontend fanno *tante cose* diverse, con diversi pattern di concorrenza (alcune richieste web che nascono e muoiono, alcuni greenlet a lunga durata, uno molto assetato di cpu...) Secondo me stiamo mettendo in crisi lo scheduler di greenlet con troppi lavori troppo eterogenei. Nell'ottica di suddividere i processi in oggetti più indipendenti un message broker come era orbited mi ci stava troppo bene (per esempio per mettere in un processo esterno quel greenlet assetato: potrebbe mandare i messaggi che genera direttamente alle pagine web passando per il broker e saltando il web server). Per la cronaca, ho fatto una prova con RabbitMQ e l'adapter stomper e funziona estremamente bene: i client ci si connettono via websocket, python attraverso stomp.py. Credo che mi orienterò per questa soluzione, che non è uno stravolgimento strutturale per la nostra applicazione (almeno è quella che proverò a spingere nelle prossime discussioni). Grazie a tutti, -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Rimpiazzare Orbited
On 2014-04-01 16:30, Giovanni Porcari wrote: Daniele mi spiace ma non ho una risposta seria. Però puoi mostrare il video al tuo collega https://www.youtube.com/watch?v=fmQFRrGggLA Ma LOL :D -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Rimpiazzare Orbited
On 2014-04-01 16:39, Walter Valenti wrote: Insomma, Orbited è moribondo ma era stracomodo. Sapete come rimpiazzarlo? orbited2. gameclosure / orbited2 Next generation Orbited (putting a WebSocket in every browser.) È in beta da 4 anni, non è in produzione. Ma grazie :) -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Rimpiazzare Orbited
> Ciao, > > un mio collega ha avuto la brillante idea di togliere Orbited da un > sistema web push che abbiamo, perchè voleva passare ai websocket. Così > dall'avere N web server python che pushavano messaggi ad un singolo > orbited (che non ha mai fatto pio) e i client web che li ricevevano sui > loro canali siamo passati ad avere ogni client collegato con una > connessione websocket persistente al server. Coincidentalmente da quel > giorno abbiamo cominciato a incontrare mille problemi e il programma non > scala più bene, chissà come mai... > > Sto provando a insistere a reintrodurre il message broker perché sono > convinto che ci ha parato le chiap^W spalle per anni ma lui non vuole > recedere dai websocket. Secondo me un broker ci vuole, anche per come > immagino il futuro di quel sistema. > > Fatico a trovare un rimpiazzo drop-in di orbited su websocket: qualcosa > a cui i client web si connettono su un canale e altri processi possono > mandare messaggi sui canali che decidono. Sapete se esiste qualcosa del > genere o se è necessario passare ad un server AMQP (RabbitMQ etc.)? > Conosceta Autobahn, sapete se è promettente? Vedo che usa l'ennesimo > nuovo protocollo di message passing, WAMP invece di Stomp... oddio ma > quanti ne servono? Altre alternative? > > Scrivo qui perchè il mio collega ha letto del supporto uWSGI ai > websocket ma io credo che si riferisca ad avere connessioni al server, > non un message broker a sé stante. Giusto Roberto? > gia', pero' combinarlo con redis e una coda pub/sub e' relativamente semplice (e soprattutto rapido). Fammi pure contattare dal tuo collega, magari ne uscite senza un bagno di sangue... La logica e' che l'app WSGI instaura la sessione websocket e resta in ascolto anche su redis, ogni volta che c'e' un messaggio sul canale websocket questo viene girato a redis, ogni volta che c'e' un messaggio su redis viene passato al websocket. E' molto efficiente, noi lo usiamo per i videogiochi dove la velocita' e' essenziale. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Rimpiazzare Orbited
> > Fatico a trovare un rimpiazzo drop-in di orbited su websocket: qualcosa > a cui i client web si connettono su un canale e altri processi possono > mandare messaggi sui canali che decidono. Sapete se esiste qualcosa del > genere o se è necessario passare ad un server AMQP (RabbitMQ etc.)? > Conosceta Autobahn, sapete se è promettente? Vedo che usa l'ennesimo > nuovo protocollo di message passing, WAMP invece di Stomp... oddio ma > quanti ne servono? Altre alternative? > > Scrivo qui perchè il mio collega ha letto del supporto uWSGI ai > websocket ma io credo che si riferisca ad avere connessioni al server, > non un message broker a sé stante. Giusto Roberto? > > Insomma, Orbited è moribondo ma era stracomodo. Sapete come > rimpiazzarlo? > orbited2. gameclosure / orbited2 Next generation Orbited (putting a WebSocket in every browser.) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Rimpiazzare Orbited
Il giorno 01/apr/2014, alle ore 13:14, Daniele Varrazzo ha scritto: > Ciao, > > un mio collega ha avuto la brillante idea di togliere Orbited da un sistema > web push che abbiamo, perchè voleva passare ai websocket. Così dall'avere N > web server python che pushavano messaggi ad un singolo orbited (che non ha > mai fatto pio) e i client web che li ricevevano sui loro canali siamo passati > ad avere ogni client collegato con una connessione websocket persistente al > server. Coincidentalmente da quel giorno abbiamo cominciato a incontrare > mille problemi e il programma non scala più bene, chissà come mai... > > Sto provando a insistere a reintrodurre il message broker perché sono > convinto che ci ha parato le chiap^W spalle per anni ma lui non vuole > recedere dai websocket. Secondo me un broker ci vuole, anche per come > immagino il futuro di quel sistema. > > Fatico a trovare un rimpiazzo drop-in di orbited su websocket: qualcosa a cui > i client web si connettono su un canale e altri processi possono mandare > messaggi sui canali che decidono. Sapete se esiste qualcosa del genere o se è > necessario passare ad un server AMQP (RabbitMQ etc.)? Conosceta Autobahn, > sapete se è promettente? Vedo che usa l'ennesimo nuovo protocollo di message > passing, WAMP invece di Stomp... oddio ma quanti ne servono? Altre > alternative? > > Scrivo qui perchè il mio collega ha letto del supporto uWSGI ai websocket ma > io credo che si riferisca ad avere connessioni al server, non un message > broker a sé stante. Giusto Roberto? > > Insomma, Orbited è moribondo ma era stracomodo. Sapete come rimpiazzarlo? > > Grazie mille, > Daniele mi spiace ma non ho una risposta seria. Però puoi mostrare il video al tuo collega https://www.youtube.com/watch?v=fmQFRrGggLA G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Rimpiazzare Orbited
Ciao, un mio collega ha avuto la brillante idea di togliere Orbited da un sistema web push che abbiamo, perchè voleva passare ai websocket. Così dall'avere N web server python che pushavano messaggi ad un singolo orbited (che non ha mai fatto pio) e i client web che li ricevevano sui loro canali siamo passati ad avere ogni client collegato con una connessione websocket persistente al server. Coincidentalmente da quel giorno abbiamo cominciato a incontrare mille problemi e il programma non scala più bene, chissà come mai... Sto provando a insistere a reintrodurre il message broker perché sono convinto che ci ha parato le chiap^W spalle per anni ma lui non vuole recedere dai websocket. Secondo me un broker ci vuole, anche per come immagino il futuro di quel sistema. Fatico a trovare un rimpiazzo drop-in di orbited su websocket: qualcosa a cui i client web si connettono su un canale e altri processi possono mandare messaggi sui canali che decidono. Sapete se esiste qualcosa del genere o se è necessario passare ad un server AMQP (RabbitMQ etc.)? Conosceta Autobahn, sapete se è promettente? Vedo che usa l'ennesimo nuovo protocollo di message passing, WAMP invece di Stomp... oddio ma quanti ne servono? Altre alternative? Scrivo qui perchè il mio collega ha letto del supporto uWSGI ai websocket ma io credo che si riferisca ad avere connessioni al server, non un message broker a sé stante. Giusto Roberto? Insomma, Orbited è moribondo ma era stracomodo. Sapete come rimpiazzarlo? Grazie mille, -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
