PubSub Opcje

[kpt_lucek]

Witajcie

Borykam się z pewnym problemem, mam przygotowany mechanizm PubSub (Websocket).

Opierając się o autobahn napisałem chat od strony klienta, a gosws serwer.

To z czym mam problem, bądź mi nie pasuje:
1) Serwer umiera przy dużej liczbie połączeń, cron "lata" co minutę i stara się reanimować, co w efekcie powoduje kolejne padnięcie trupem,
2) Tym mogę wyciągnąć usera, a co za tym idzie - podczas requesta, poza danymi leci również ciastko (imo nie powinno, nie do tego jest pub&sub nie?),
3) Alternatywa crossbar działa fajnie, 20k requestów/s nawet nie gryzie, aczkolwiek nie ma sharowania ciastek (przynajmniej na tym etapie dokumentacji na którym jestem, ale to nie istnotne), a poza tym i tak potrzebuję subscriber'a i publisher'a od strony php, co za tym idzie, sytuacja bardzo podobna do 1, mianowicie - dużo requestów, apka pada.

to co chcę uzyskać, to względnie wydajne narzędzie, bazujące na czymś co (najlepiej) już jest (chociażby wspomniany crossbar), możliwość względnie bezawaryjnego "słuchania" i "nadawania" do dowolnego użytkownika/grupy użytkowników na kanale, szyfrowanie to swoją drogą. Można by zapewne autoryzować użytkownika po tokenie dołączonym do payload'u, ale tutaj security fkup (tak, wiem że podwędzenie użytkownika i hasła do komputera też może się "stać").



Jakieś sugestie?

[by_ikar]

Cóż, nie może wyjść nic dobrego z puszczenia php w wieczną pętle, bez dostosowania samego serwera php do tego, dlatego to narzędzie jest raczej dowodem na to że w php też się da to zrobić, niż czymś co poleciłbym jako narzędzie produkcyjne. Nawet jeżeli użyłbyś node.js i którejś z implementacji websocketów skończyłoby się to podobnie, aczkolwiek pewnie przy większej liczbie połączeń. Jak coś ma przyjmować sporo requestów, lub utrzymywać stałe połączenia w dużej liczbie, to tego nie osiągniesz na jednej maszynie, bo prędzej czy później zwyczajnie padnie.

Pracuje nad projektem który stałych połączeń jak i samych requestów ma przyjmować ile się będzie dało, początkowo użycie socket.io wydawało się dziecinnie proste, i działało, ale przy sporej liczbie połączeń, po prostu jedno wątkowy node.js nie dawał rady, więc pierwszym wyzwaniem była komunikacja pomiędzy procesami. Bo przecież nawet jak stworzysz kilka procesów, to użytkownik podłączony do 1, nie będzie widział tego co się dzieje w 2 procesie. Do tego celu użyłem redisa który ma zaimplementowany pub/sub od wersji 2.0 (więc nawet jest dostępny na windowsie), do którego socket.io ma napisany adapter: http://socket.io/docs/using-multiple-nodes/ do tego powstały adaptery dla innych języków aby można było puścić emit z php, a użytkownicy podłączeni pod serwer napisany w node.js otrzymali by ten emit. Rozwiązanie sprawdza się o dziwo dobrze, aktualnie jestem na etapie tworzenie klastera redisa i testowania ów pub/suba w jego wykonaniu. Do tego, sesja użytkownika jest przechowywana w redisie jako string JSON'a, dzięki czemu mam szybki dostęp do takiej sesji na poziomie handshake websocketowego. PHP do redisa łączy się bez problemu, własny lekko zmodyfikowany handler sesji i gotowe, wspólna sesja, dla dwóch odrębnych usług.

[kpt_lucek]

Hmm... przeglądałem socket.io, wyglądało dość... dobrze, w praktyce, wcześniej wspomniany crossbar dałby radę, nawet przekazanie parametru celem idendyfukacji użytkownika nie było by problemem.

Problemem jest ogranie tego od strony PHP, jak to ograć, żeby serwis jednocześnie i nasłuchiwał i pushował do WS, bez zbędnej i ciężkiej logiki

[Damonsson]

Hmmm dziwne problemy. Sockety obsługiwane przez PHP na najtańszym dedyku z 1gb ram powinno spokojnie ogarnąć MILIONY połączeń. Podsumowując, coś robicie źle.
Ad 1) Nie podoba się pętla w PHP? Jest libevent.
Ad 2) Nie podoba się taka obsługa sesji? Nie używaj
Ad 3) Nie wierzę, że 20k zabija serwer, musisz robić tam coś jeszcze dziwnego.

Autoryzację użytkownika masz rozwiązaną po cookies, musisz tylko sesję obsługiwać np. w Redisie, ja osobiście tak robię i działa super, kolega by_ikar, widzę też coś takiego sobie pisze. Opis jak to zrobić, masz w dokumentacji GOSWebSocketBundle albo Ratchet.

Osobiście używam, a żeby było śmieszniej rozwijam projekt GOSWebSocketBundle, więc znam go od podszewki i działa pięknie dla milionów requestów na tanich dedykach, testowane wielokrotnie benchmarkami. Jeżeli nie piszesz w Symfony to nie potrzebny Ci GOSWebSocketBundle, wystarczy sam Ratchet, z którego korzysta GOSWebSocketBundle.

Podsumowując szukałbym przyczyny po stronie serwera, lub dziwnej implementacji websocketów. Nie wierzysz, postaw sobie gołe demo GOSWebSocketBundle i zapuść jakiś benchmark, tam w dokumentacji powinien być gdzieś przykład użycia, zobaczysz, że to działa dla dużych liczb i nic się nie wywala.

Ten post edytował Damonsson 4.11.2015, 01:51:47

[kpt_lucek]

Ad 3) Nie wierzę, że 20k zabija serwer, musisz robić tam coś jeszcze dziwnego.

Nigdzie nie napisałem, że 20k zabija serwer, wspomniałem o tym, że pętla to robi, na moje oko dzieje się za dużo magii po odebraniu requesta i raczej tam muszę popatrzeć.

Autoryzację użytkownika masz rozwiązaną po cookies, musisz tylko sesję obsługiwać np. w Redisie, ja osobiście tak robię i działa super, kolega by_ikar, widzę też coś takiego sobie pisze. Opis jak to zrobić, masz w dokumentacji GOSWebSocketBundle albo Ratchet.

Redis od samego początku trzyma sesje, dlatego mogę go (użytkownika) autoryzować po stronię apki (wspomniałem o tym )

--

To o co pytałem, tyczyło się raczej kwestii podejścia do problemu, meritum problemu jest to, że podczas pętli wszystko siedzi w pamięci, wyobraź sobie doctrine'a który ciągnie dziesiątki, setki albo i tysiące rekordów z bazy a potem ładuje to w pamięć, logicznym jest wyczyszczenie cache'u po wykonaniu akcji push (client->server i server->client). Pytanie, na ile da radę vps utrzymujący aplikację, oraz handlowanie eventów, gdzieś jest granica

[by_ikar]

Hmmm dziwne problemy. Sockety obsługiwane przez PHP na najtańszym dedyku z 1gb ram powinno spokojnie ogarnąć MILIONY połączeń. Podsumowując, coś robicie źle.

Utrzymanie miliona połączeń to dość akademickie podejście, wystarczy do takiego miliona połączeń wysłać jednego emita z playloadem 1kb i już takiej maszynie nie wystarczy pamięci na przetworzenie takiej ilości danych. Nie mówiąc już o łączu, bo przecież będzie to wysłanie prawie 1gb danych, w sekundę też się to nie wyślę. Więc hmm, takie pisanie o ogarnianiu milionów połączeń jest dość na wyrost, bo w praktyce wygląda to zupełnie inaczej.