Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: ondra.novacisko.cz 02. 10. 2010, 19:58:00
-
Zdravím.
Napadá někoho řešení subj.? Potřebuju rozběhat push server, na kterém by viselo mnoho (statisíce až miliony) spojení, které ale po většinu času nekomunikují, pouze jsou otevřená pro případnou zprávu. Je mi jasné, že sem tam se bude muset odeslat nějaké to keep alive (a při tolika spojení to bude docela slušný síťový provoz), ale omezení vidím většinou v možnostech operačního systému (linux).
Neznáte někdo nějaké řešení (knihovnu, ovladač do linuxu), kde by se něco takového řešilo? Pokud bych musel sáhnout po UDP, bylo by to bez problémů. Ale zadání je TCP protokol
-
Je nejaka cast http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-2/ uzitecna?
-
Napadají mně dva možné přístupy: buď pomocí NPTL vytvořit pro správu každého spojení thread (nebojte se spousty threadů, NPTL je velmi efektivní), nebo použít menší množství threadů (možná i procesů) kde každý bude obsluhovat více spojení pomocí epoll. Já bych se tedy od takových low-level záležitostí oprostil programováním v Javě kde JVM jak NPTL thready tak epoll vyřeší za mě, ale to už je věc osobního vkusu...
-
V prvni rade je nutna poradna sitovka, dale nastaveni mbufs (slab na Linuxu nebo jak to je), podle toho taky RAM, neit nepotrebne veci v systemu atd.
-
Diky, o NPTL jsem netusil, je to docela zajimave az "brutalni".
In tests, NPTL succeeded in starting 100,000 threads on a IA-32 in two seconds. In comparison, this test under a Linux kernel without NPTL would have taken around 15 minutes.
Napadají mně dva možné přístupy: buď pomocí NPTL vytvořit pro správu každého spojení thread (nebojte se spousty threadů, NPTL je velmi efektivní), nebo použít menší množství threadů (možná i procesů) kde každý bude obsluhovat více spojení pomocí epoll. Já bych se tedy od takových low-level záležitostí oprostil programováním v Javě kde JVM jak NPTL thready tak epoll vyřeší za mě, ale to už je věc osobního vkusu...
-
ja bych pouzil spis mene threadu/procesu a epoll - rozhodne to bude mit mensi narocnost na pamet a pro pouziti jako cekajici spojeni to je vyhovujici.. tech 1M spojeni ma byt na jednom PC? To pri nejake akci bude mit lag minimalne 0.5sec (kdyz vezmeme 64B minimal payload na eth * 8 = 512 mbit dat). Takze pozor i na to co prenasime - v pripade 640B http head + body to je jiz 5 sec v idealnim pripade!
-
riesim podobny problem, nakoniec na win, .net 4.0, SocketAsyncEventArgs
Tiez chcem obyst http, overhead by bol niekolkonasobny.
-
ja bych pouzil spis mene threadu/procesu a epoll - rozhodne to bude mit mensi narocnost na pamet a pro pouziti jako cekajici spojeni to je vyhovujici.. tech 1M spojeni ma byt na jednom PC? To pri nejake akci bude mit lag minimalne 0.5sec (kdyz vezmeme 64B minimal payload na eth * 8 = 512 mbit dat). Takze pozor i na to co prenasime - v pripade 640B http head + body to je jiz 5 sec v idealnim pripade!
No nebude to HTTP, chtěl jsem původně redukovat množství PC na minimum. Účelem je mít ta spojení otevřená, 99.9999% tam nebude žádný provoz. Ale jde o to, že uživatel má po cestě všechny proxy, naty a buh ví jaký balast otevřený, takže mu mohu poslat zprávu kdykoliv, jako by uživatel sám byl aktiv... nemusí dělat pooling.
Příklad případu užití. Notifikátor došlé pošty... který informuje v okamžiku, kdy pošta dorazí do schránky, a nikoliv za nějakých X minut. Tím se mimojiné redukuje datový provoz, protože pooling je rozhodně náročnější na data a na výkon server, než push.
-
Ja vim, ze programovani naprosto nerozumim, nevim jak se jmenuju a nevim proc co jak kdy ... Ale vo tom U - Nix - U jsem cetl v jedny knizce.
Co to udelat vobracene?
Co napsat do toho klienta, aby se dotazoval? Ne udrzovat ty spojeni votevreny ;o)
-
David Strejc: a vyhody ? pripojit sa a odpojit je celkom slusny overhead.
-
No, vzhledem k tomu, že se bude muset posílat každejch pět minut keepalive paket na milion serverů a přitom v 99.99999% nebudou potřeba posílat žádný data, tak je polling jednoznačně míň náročnej na zátěž linky....
Jen udržování spojení stojí 1M počet spojení * 40B minimální velikost paketu * 2 odpověď = 80MB každejch pět minut). To je přes 20GB denně...Samozřejmě, pokud by v těch samejch intervalech probíhal polling, tak je to lepší, ale jestli to je např. kvůli updatům aplikace, tak je taková četnost zbytečná...
-
Jasne, zalezi od toho ci sa po linke bude posielat nieco 2x za den alebo kazdych par desiatok sec. Proste zalezi od vyuzitia. Pokial keepalive bude zasadne viac ako samotne data, straca to skoro zmysel.
-
Napadá někoho řešení subj.? Potřebuju rozběhat push server, na kterém by viselo mnoho (statisíce až miliony) spojení, které ale po většinu času nekomunikují, pouze jsou otevřená pro případnou zprávu. Je mi jasné, že sem tam se bude muset odeslat nějaké to keep alive (a při tolika spojení to bude docela slušný síťový provoz), ale omezení vidím většinou v možnostech operačního systému (linux).
Neznáte někdo nějaké řešení (knihovnu, ovladač do linuxu), kde by se něco takového řešilo? Pokud bych musel sáhnout po UDP, bylo by to bez problémů. Ale zadání je TCP protokol
Já se vrátím na začátek - v čem konkrétně je problém a "ty omezení operačního systému (linux)" ? Udělal jste si aspoň nějaké benchmarky a testy, abyste lokalizoval potencionální slabá místa?
S miliónem spojení Linuxový kernel problémy mít nebude (samozřejmě předpokládám, že máte k dispozici adekvátní HW), zbytek je aplikační návrh. Takže za prvé první odstavec a následně zkuste být konkrétnější.
-
No pokud to půjde přes kernelový IP stack, tak např. limit počtu deskriptorů, pak limit paměti kernelu, dále je to čas procházení seznamu spojení (je to už přes hash nebo ne?) atd.
Zadání "TCP spojení"... Nedá se s tím zadáním něco dělat? To má být z mobilů? To bych kvůli baterii využil raději existujících standardních funkčních řešení (jak pro iP4 tak Android).
-
To je přes 20GB denně...Samozřejmě, pokud by v těch samejch intervalech probíhal polling, tak je to lepší, ale jestli to je např. kvůli updatům aplikace, tak je taková četnost zbytečná...
Nepocitam, ze pojde o updaty, skor o IM alebo podobnu interaktivnu komunikaciu; 20GB denne nikoho nezabije, aj ked v mnohom zalezi na houserovi / providerovi - niektori v pohode zvladaju aj 30krat viac, u inych by som si za to asi poriadne zaplatil.
-
pri milionech klientu ten milion mesicne na konektivitu snad i vyzebrate :) a pokud ne, tak porad existuji reseni (... p2p)
-
No pokud to půjde přes kernelový IP stack, tak např. limit počtu deskriptorů, pak limit paměti kernelu, dále je to čas procházení seznamu spojení (je to už přes hash nebo ne?) atd.
Zadání "TCP spojení"... Nedá se s tím zadáním něco dělat? To má být z mobilů? To bych kvůli baterii využil raději existujících standardních funkčních řešení (jak pro iP4 tak Android).
Preco by malo byt TCP spojenie energeticky neusporne ? Neusporne je na niektorych telefonoch stale spojenie cez 3G modul. Ale samo o sebe, vlastny protokol nad TCP sa moze tiez odpajat po predani info, napr na zaklade pripojenia na baterku/elektriku.
-
Preco by malo byt TCP spojenie energeticky neusporne ? Neusporne je na niektorych telefonoch stale spojenie cez 3G modul. Ale samo o sebe, vlastny protokol nad TCP sa moze tiez odpajat po predani info, napr na zaklade pripojenia na baterku/elektriku.
TCP spojení jako takové ne (to je pro baterii určitě úspornější než UDP), ale určitě je úspornější mít jednu push notifikační službu, než aby si to implementovala každá aplikace zvlášť a udržovalo se těch spojení víc. Vývojáři mobil aplikací - začátečníci - často zapomínají, že ta jejich není jediná, co běží na telefonu.
-
Pokud neni podminka Linux, tak mozna Solaris a zkusil bych pouzit:
http://developers.sun.com/solaris/articles/event_completion.html (http://developers.sun.com/solaris/articles/event_completion.html).
Podobne komplexni vec mi na Linuxu chybi, i kdyz na nej prechazime kvuli Oracle. Tam je tusim jen epoll, ale i ten by mozna stacil. Nevim jaky sitovy provoz a pocet spojeni to snese, navic je urcite potreba si pohrat s nastavenim systemu, at uz Linux nebo Solaris, co se tyce poctu otevrenych spojeni atd.
-
Na mobil to být nemá. Měl by to být ale "jediný push server" na desktopy. Umožňoval by hlavně rychlou reakci na vzniklou událost. Třeba když přijde e-mail do schránky, tak se o tom uživatel hned dozví, ne až za pět minut, což je interval pollingu (nebo se to hodí na notifikace o nových updatech, ať již software, nebo novinkách na webovkách, atd).
Keepalive overhead mi nevadí. Polling je náročnější hlavně na servery, než na síť. Musí třeba e-mailovou schránku vyhledat. Neustále jsou servery zatěžovány dotazy na to, zda existuje nový e-mail. Použitím push serveru znamená, že se jich nebude ptát nikdo, a až nějaký mail dojde, tak event předá na push server, což je rozhodně méně náročné, než obráceneně.
Uvědomte si, že na desktopech neexistuje žádný oficiální push server. Když to půjde, podaří se mi něco takového zprovoznit aspoň pro produkty firmy, ve které pracuju :-) a možná zájemce o technologii z vnějšího prostředí :-)
No zatím to vypadá, že použiju kombinaci UDP + TCP. UDP tam kde to půjde, TCP tam kde jsou proxy a různá další omezení. Tolik zákazníků s TCP zas nebude, aby to nezvládla běžná linuxová mašina.
-
No tak konkretne u toho emailu, uz ta push notifikace funguje nejaky ten patek pres IMAP.
-
No tak konkretne u toho emailu, uz ta push notifikace funguje nejaky ten patek pres IMAP.
Akorát je to trošku kanón na vrabce. A navíc je určen právě jen pro e-mail
-
Nesla by pouzit CouchDB + replikace? tam to preci funguje ja push, ne?
-
No zatím to vypadá, že použiju kombinaci UDP + TCP. UDP tam kde to půjde, TCP tam kde jsou proxy a různá další omezení. Tolik zákazníků s TCP zas nebude, aby to nezvládla běžná linuxová mašina.
C500K ... http://bit.ly/barcub
Mochiweb ... http://bit.ly/9yA0Jo
Pak existují user space implementace TCP.. Ale určitě bych zvážil použití jiného OS (Solaris, *BSD) jako nejmenší zlo.
-
C500K ... http://bit.ly/barcub
Mochiweb ... http://bit.ly/9yA0Jo
Pak existují user space implementace TCP.. Ale určitě bych zvážil použití jiného OS (Solaris, *BSD) jako nejmenší zlo.
Každopádně díky za TIPy. Jiný OS nepřipadá moc v úvahu, všichni tu jedou na debianu, znamenalo by to významný zásah do interních postupů (ono i to UDP je už dost odvaha :-)
Nějaký projekt "user space implementace TCP"?
-
Krom googlu víc asi neporadím. Nemám praktickou zkušenost.
-
A jinak mě jako docela zajímavý přišel ten návrh Daniela udělat to přes P2P. Na takové notifikace, ani nepotřebujete kdovíjaké QoS.
BTW objeví se výsledek (aspoň ve formě zápisu zkušeností) na vašem blogu?