Autor Zpráva
G3n3sis19
Profil
Zdravím.

Dost mě poslední dobou zaujmulo styl, jakým FB "aktualizuje" a komunikuje, a došel jsem přes google až k informacím, že FB používá long-polling ajax.
Říkám si, když to používá FB, tak v tom něco bude a začal jsem to zkoumat. Zkusil jsem si udělat takový malý přídavek do své browser hry, aktualizace vesnice přes long-polling ajax. Problém je, a to mě nenapadlo, že ten skript který běží a čeká na nové data, drží mysql spojení a neměl bych tak šanci jich mít otevřených 1000. Jak myslíte, že to facebook má? Zavírají pokaždé spojení a otevírají ho po 5 sekundách? nebo mají někde kontrolní soubory (vytváření při vložení chat zprávy), a pokud skript zjistí, že tam soubor je, otevře spojení?
(To, že FB není na jednom serveru vím, ale stejně, 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

Opravdu mě to zajímá a budu rád za každý SMYSUPLNÝ názor.

Díky
jenikkozak
Profil
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í.
G3n3sis19
Profil
Dobře. Ale i tak, pokud je online přes 20 000 000 lidí, tak i tak by to bylo těžký, povolit na každým serveru 1000 spojení (1000 * 30000) pokryje 30 000 000 lidí ale nedokážu si představit tu zátěž a využití ramky+procesoru

Na další otázku odpověď nikdo nemá ?
DuCk
Profil *
Docela by mě tohle také zajímalo, aktuálně to řeším.
DJ Miky
Profil
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.
Aokomo
Profil *
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.
JackieJack
Profil *
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...

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: