Vlákno názorů k článku Komunikace webové aplikace se serverem pomocí WebSocket od M696 - Moc pekne oba clanky. Stavim ted aplikaci, co bude...

Moc pekne oba clanky.
Stavim ted aplikaci, co bude prijimat aktualizace dat a premyslim, zda neustale tukat do serveru treba z tisicovky aplikaci, nebo to mit pres websocket.
Zas nechci aby to upeklo server, potazmo VPSku.
Ty data se muzou menit co 1-5 sekundy.
Aktulne je to reseno Getem. Data se tak daji hodit do cache.

WebSocket riesi komunikaciu zo servera do browsera. Ak potrebujete komunikovat z browsera do servera tak to mozete robit aj cez normalne GETy. Pouzite fetch() a nastavte na nom keepalive.

WebSocket neřeší jen, nebo primárně, komunikaci ze serveru do klienta. WS je full-duplex, tzn. může přijímat i odesílat data současně (v obou směrech, klient-server i server-klient). AJAX, fetch() atp. nejsou full-duplex.

Pomocí AJAXu, fetch() a pod. nevyřešíte elegantně (bez dostatečného výkonu) třeba problematiku chatu, kdy u fetch() a současně připojených 1000+ klientech pořádně zahřejete server. Při WebSocketu se klienti připojí a jen čekají na zprávu, nenavazují co pár sekund nové spojení, které je oproti udržení otevřeného spojení mnohonásobně náročnější na výkon.

Další malý příklad, který pomocí AJAXu, fetche a pod. nelze elegantně realizovat, je přáce s GPS mnoha klientů v reálném čase. Sledují se třeba body a rádius kolem nich, zda se do daného prostoru nedostal další klient. V okamžiku, kdy to nastane, odesílají se v reálném čase zprávy ostatním klientům, kteří jsou v dané zóně (rádiusu kolem bodu).

Je hodně řešení, která díky WebSocketům neupečou server a mohou fungovat s mnoha tisíci klienty v reálném čase. AJAX a pod. bude vždy náročnější na výkon serveru, nebo podstatně pomalejší, nez WS.

11. 11. 2022, 10:52 editováno autorem komentáře

Proc by mel byt long polling radove narocnejsi nez websickety? Jedno spojeni na klienta jako jedno spojeni na klienta.

Ono v případě jednoho spojení a jedné zprávy rozdíly mezi long polling a WS v podstatě nebudou. Obojí proběhne navázáním spojení, odesláním dat, čekáním a přijetím odpovědi, když je.

Rozdíl ve výkonu přijde v okamžiku, kdy se musí posílat více zpráv, resp. v okamžiku, kdy se musí ukončit stávající a navázat nové spojení.

WebSocket díky jednomu spojení dovede odbourat opakovaná připojování, která jsou na celé komunikaci nejnáročnější. V případě posílání bajtových (stavových a pod.) hodnot dělá obsluha spojení 99% přenesených dat a spotřebovaného výkonu.

Tyhle zátěže se samozřejmě neprojeví na malém počtu připojených klientů, s pár požadavky za hodinu, ale až v řádech vyšších stovek, tisíců atp.. Je pak i otázka, co naslouchá a zpracovává data na serveru, ale to už je jiný příběh.

Budu na to muset udelat nejaky test zateze. Komunikace z 99% bude server->client. Server bude posilat aktualizovana data.
Clientu muze byt najednou 1000-10000.
Aktualne si to client aktualizuje co 5 sekund Getem. Server to moc nezere, ale je tam zatim slaby 10% provoz.

Clovece ja som pisal asynchronne aplikacie ktore online updatovali stav na burze cez Tibco rendezvous pred 20 rokmi. Dakujem za vase rady :-D.

Omlouvám se, ale nebylo to z příspěvků vůbec poznat, ba naopak. :)

Jak souvisí použití specializované messaging technologie s možnostmi Websocket vs. Ajax? Mně ten komentář přijde zcela relevantní.

Záleží na směru. Pokud ta data posíláte jen z klienta na server, tam vám WebSocket asi moc nepomůže (leda byste měřil i počet přenesených bajtů, ale je otázka, zda se s HTTP/2 nedostanete na stejná čísla). Pokud jde o opačný směr (ze serveru na klienta), k takovému typu komunikace je právě WebSocket určen – místo aby se klient co pět vteřin nebo dokonce vteřinu ptal serveru, zda je něco nového, server mu přes WebSocket pošle zprávu pokaždé, když se něco změní. Záleží ale také na frekvenci změn, pokud prakticky při každém požadavku klienta dostane nějaký seznam změn, pak může dávat smysl se jenom pravidelně ptát, protože pak dostáváte data po dávkách, což obvykle bude efektivnější.

Na tohle by se nejlepe hodilo SSE. Neni slozite ho nastavit a bude delat presne co potrebujes. WS by se na to sice hodil take, ale pokud potrebujes data predevsim ve smeru server->browser, nestalo by za to setupovat cely cirkus kolem WS.

Diky, ono to ted vypada, ze zkusim SSE. Celkem se mi zalibila moznost, ze client si vyzada vysledky a relace zustane otevrena a bude dostavat aktualizace, ktere uz nebudou nijak velke.
Kdyz se spojeni rozpoji, tak holt si klient zavola znova.