FaceBook chat, a long-polling celkově

G3n3sis19:
„to by těch serverů muselo bejt přes 20 000 aby si mohli dovolit mít všechny spojení otevřený přes 50s“
Nevím, jak dlouho mají otevřená spojení, ale 20 000 serverů pro ně problém není.

Docela by mě tohle také zajímalo, aktuálně to řeším.

Netuším, jak to má Facebook realizované, ale nepřipadá mi nereálné držet tolik spojení. Neřekl bych, že pro každé spojení budou mít aktivní PHP skript a spojení do databáze. Může tam být využit nějaký systém založený na událostech, tedy všechna spojení se pouze drží otevřená a spí, nějaká událost (přijetí zprávy od protistrany) je probudí a pošle data. Nemusí to být ani realizováno pomocí PHP. Nicméně v případě, že většina spojení se pouze drží otevřená a nic nedělá, nebude zátěž pro jedno spojení nijak výrazná. CPU nebude dělat téměř nic (jenom při události) a v paměti může být jenom nějaká menší datová struktura v řádu kilobajtů. Třeba pro 8 KB na každé spojení vychází využití paměti na 1 GB pro 125.000 spojení, a to dnešní servery mívají klidně i stovky gigabajtů paměti. Jeden server desítky milionů lidí nezvládne, ale nečekal bych, že bude potřeba více než řádově desítky strojů. Facebook sice má desítky tisíc serverů, ale většina podle mě padne na úložnou kapacitu (fotky, videa apod.) a databáze (myšleno jako model, tedy i s všemožnými výpočty), v menší míře pak na frontend servery generující samotné stránky.

pánové, jdete na to ze špatné strany, předpokládáte, že facebook má podobnou architekturu jako obyčejné webové stránky. Má to mnohem složitější, tak jen krátce.

Každý node obsahuje plnohodnotnou aplikaci (tj. šablony, modely atd.), dotazy do databáze/uložišť probíhají kumulovaně a jednotlivé nody se nepřipojují přímo na konkrétní databázi, ale k nejbližší "datové bráně" (nenapadá mě lepší český překlad), která zajistí výběr nevhodnější databáze a na ní vznese dotaz. Spojení na databáze se na bráně polují a není tedy nutné pro každý požadavek vytvářet nové.

Long polling a další zlepšováky nejsou problém pokud máš pod kontrolou technologie. Nemusí v tom být z hlediska nároků tak obrovský rozdíl oproti socket spojení nebo tcp "keep-alive" :).

Český lze pár informací načerpat z loňské přednášky od Jakuba http://sprednasky.cz/zkusenosti-z-vyvoje-facebooku/.

V php nemám praktické zkušenosti z provozu long-polling, používáme na to jiné jazyky. Implementace, ale nebude složitá, stačí se lazy na db připojit před komunikací s db a po načtení dat se zase odpojit a hodit sleep. Tohle je možné opakovat dokud prohlížeč spojení nezavře, poté stačí hodit nový request s prohlížeče...

Ak.

Základní myšlenka celého long-pollingu je ze se skript uspí - např. sleep, usleep (viz PHP manuál), důležité je také zavolat
session_write_close = "Zapiš session data a zavři session" - což je - pokud máte přihlášeného uživatele přes session a podle nej taháte chat zprávy - poměrně reálná záležitost.
Skript tedy v tomto nastavení udělá vždy jeden trigger-zeptá se databáze- v cyklu a uspí se (např. na 1-5sekund a pak se znovu zeptá, takhle se ptá treba 20sekund - pokud něco našel, ukončí se(resp. odešle odpověď ajaxu), pokud vypršel timeout, tak je dobré aby dal ajaxu taky vědět.

Pokud skript spí, mělo by to znamenat, že v podstatě nevužívá výkonové systémové prostředky.

To zní sice moc krásně ale v praxi sme narazili na problém - např. na wedosu je povolen maximální paralelní počet spuštěných skriptů 5-10.
Co z toho plyne? Extrémní lagy, protože další skripty čekají naprvní. Takže pokud tohle chce někdo realizovat, je potřeba - mít vlastní kontrolu nad nastavením Apache/PHP + mít pokud možno nějakou detekci DDoS útoku...