[Python] Rimpiazzare Orbited

[Daniele Varrazzo]

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