Streamovanie odpovedi – vykon?

Ahojte, chystam sa prerabat nejake veci na streamy, takze namiesto pingovania backendu cez ajax a pod sa proste budu streamovat eventy(sse, XMLHttpRequest eventy a podobne - NIE sockety) a zaujimalo by ma ako to moze byt v realnej prevadzke s vykonom? Ak mi bezi na pozadi nejaka slucka tak skript je stale v pameti a drzi spojenie s klientom. Mate s tym niekto nejake prakticke skusenosti ze na co si dat pozor a pripadne ake su limitacie tohto pristupu?

hm, asi ti nerozumím. Měl bys v první řadě říct, co máš za backend, php?Máš tady několik možností:1) http request ve smyčce nad http 1.x - dochází k vytvoření tcp session při každém requestu v případě, kdy interval je delší než http keepalive. Pod ssl/tls se navíc ještě musí vytvořit nový handshake, výkonnově nejhorší řešení2) http long pooling - držíš jedno spojení, backend v intervalu ti posílá data a klient si je po řádkách parsuje - drží se jedno spojení, při dalších datech není potřeba znovu vytvářet tcp session a ssl/tls handshake. Je to ale obtížné na logiku a příliš problémové při proxy serverech a na síti se ztrátou paketů - mobilní připojení3) websocket - na pozadí se drží tcp spojení, šifrování se řeší řádkově, ale má ho na starosti backend, který bývá zabugovaný. Nutná podpora experimentálních modulů, v současné době deprecated4) http request ve smyčce (jako v bodu 1) ale nad http/2 - tcp ssl/tls session se drží, cena request je malá a možnost bezproblémově downgradovat na http 1.x podle podpory klienta - používá google a všechny moderní služba a v současné době nemá smysl vymýšlet jinou chujovinuSlužba v pozadí nemusí být aktivní (pokud se jedná o php), spojení s klientem může držet reverzní proxy (nginx) a ta zajišťuje i ssl/tls terminaci, při každém novém requestu (v klidně ještě drženém tcp streamu) znovu nastartuje backend (či znovupoužije nějaký nudící se třeba přes php-fpm), ten vyřídí požadavek a zase jde pryč.Základ je správně si nastavit síťování, reuse tcp portů, timeouty, zvýšit ulimit atd. atd.

Nerozumim tvemu dotazu, co bude stream text ? Nebo co konkretne bude ten "stream". Pokud mluvis o chatu a chces ho predelavat na komentu, rozhodne ti doporucuji zustat u socketu, komety nejsou rozhodne spravne reseni pro chat.

HTML5 Server-Sent EventsReact...

to se ale jedná o konkrétni implementaci nad http/2, nepodporují to všechny prohlížeče a musíš tedy psát detekci a chovat se ke každému prohlížeči jinak.Výkonnost je shodná s websocoketem. Backend v php k tomu není vhodný.

node ted se te zeptam na nekolik otazek. Duvod proc chces pouzivat react ? Duvod proc potrebujes posilat eventy ?Kazdopadne nechat bezet infinite loop v PHP jako service je sebevrazda, PHP neni na to stavene ani designovane. Takze pokud chces poslouchat v PHP na portu pomoci slucky, na to rovnou zapomen, drive ci pozdeji to crashne. Neni to stabilni reseni. Zkus trochu popsat problem ktery se snazit resit verim ze ti najdu lepsi reseni pro tuto situaci. Nez vytvaret service v PHP