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 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
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.
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ší.