Vlákno názorů k článku
Kometa přináší web v reálném čase

Teda nevim, ale kdyz chci, aby mi server porad neco posilal, tak ho proste nenecham zavrit spojeni a pokud spojeni spadne, tak ho obnovim. Proc kolem toho delat takovou vedu?

Kolik takových otevřených spojení dokáže váš server držet?

Tenhle argument sem moc nepochopil. Pro server je mnohem mensi zatez drzet otevrena neaktivni spojeni, nez neustale otevirat a zavirat spojeni kvuli heartbeatu…

Tak zkuste odpovědět na otázku: „Kolik otevřených spojení dokáže Váš webserver držet?“
Běžný Apache blahé paměti na každé spojení potřeboval jednoho potomka a ten potřeboval nějaké megabajty paměti (odhadněme třeba 8 MB, a to při několika zapnutém PHP spíš podceňuju). Pokud máte server, který má 1024 MB RAM, tak mi to vychází na 128 otevřených spojení, což může být proklatě málo i pro lokální intranet.
Jaká je situace s Apachem dnes, tak to netuším.
Stačí tak?

Nevim, kolik otevrenych spojeni dokaze muj webserver drzet. Nikdy sem na ten limit nenarazil…
Proc se bavime o pametove nenazranosti Apache? Ostatne pokud nekdo chce vykon nepouzije PHP, ale aplikacni server bud samostatnej nebo komunikujici pres fcgi…

A co shared memory? Apache nikdy nebyl takhle nenazrany.

IMHO je to právě naopak.

V pripade vysokych narokov na pocet pripojeni nebude clovek predsa pouzivat apache alebo nginx, ktore na nieco take proste nie su stavane.
Osobne by som pouzil erlang, ktory nema problem spawnnut 300k threadov za sekundu s minimom pamate. Vid napr
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1/

To nemá, ale s otevřením 300k socketů už má problém na úrovni OS. Jak s množstvím, portů, tak s množstvím otevřených „souborů“.

Pri takovym poctu aktivnich uzivatelu, ale uz nikdo nebude pouzivat pouze jeden server. Ostatne typickym prikladem servisu s milionama otevrenych spojeni jsou IM servery jako ICQ, ktery sou tu uz pres deset let…

Nic ve zlém, ale proč s tím nepřišls dřív, že je to tak jednoduché. klukům v americe by to ušetřilo dost práce. Teď, když tím zabili tolik času, tak asi budou mrzutí.
A to se jich tím zabývá dost (třeba vývojáři glassfishu) a žádného to nenapadlo :-))

Na to má odpověď Vladimír Renčín

Ehm, co z toho, ze tohle pouziva ICQ uz 14 let si nepochopil? :)

Nepoužívá, resp ne erlang. Clustery samozřejmě ano. Na počet obsloužitelných spojení v ejabberd se můžete zeptat Pinkyho, má s tím na jabbim celkem zajímavé zkušenosti :)

Ale článek je o Comet a tam je to malinko o něčem jiném, protože klient neudržuje pořád jediné TCP spojení jako u IM. Posílá na rozdíl od IM mnoho požadavků a potřebuje hodně pomocných Comet spojení s tím, že bude zachovaný session tracking.

První (a jediný) mně známý web framework (a zrovna postavený na erlangu), který umí pracovat plně distribuovaně bez inteligence v load balanceru, je Nitrogen (nitrogenprojec­t.com) a bez hacků to umí až od verze 2, která je stará maximálně pár měsíců. A interně používá právě již zmíněný mochiweb nebo Yaws.

Každopádně se celkem těším na web sockets, už se objevují první vlaštovky.. bude snad konec kometám.

Ja mluvil obecne o velkym mnozstvi dlouho otevrenych TCP spojeni. Jedinej rozdil mezi „RT webem“ jak je popsanej v clanku a mezi ICQ je, ze komunikace ICQ je obousmerna po tom jednom spojeni, kdezto u „RT webu“ je komunikace po dlouhodobym spojeni pouze od serveru ke klientu a na opacnej smer se pouzivaj klasicky kratky HTTP requesty.