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
[email protected]
http://lists.python.it/mailman/listinfo/python
