Zdravim, kdyz uz jsme u tech navrhovych vzoru a best practices, mam taky jednu lahudku, kterou v techto dnech resim. A protoze se mi vsechny me napady zdaji prilis komplikovane,obracim se na vas, jestli me treba nenakopnete nejakym smerem. Anebo si jen utridim myslenky...
Delam program, ktery bude (silne zjednodusene) delat neustale dve veci dokola: a) Pripojit se socketem k serverum b) Poslat HTTP request a stahnout data Jsou zde tri problemy: *) Tech serveru je cca 1000 a requesty by mely byt vyslany v co nejmensim casovem rozestupu (idealne soucasne nebo s rozestupem par sekund). *) Nejedna se o klasicke socketove spojeni, to navazovani kazdeho spojeni ma mnoho stavu (cca 5), ktere nejsou v pevne definovanem sledu. Tj. nekdy se spojeni zdari, nekdy jsou problemy, takze dochazi k vetveni (napriklad 3x pokus o pripojeni, nasledne ignorace spojeni v tomto cyklu + zapis do binlogu, ze se spojeni nepovedlo, pro dalsi analyzu). *) Navic knihovna realizujici spojeni je programovana asynchronne (coz muze byt vyhoda, ale take komplikace) a informace o stavu mi jsou vraceny pomoci callbackovych funkci, ktere ale bezi v prostredi vlakna te knihovny. Takze ikdyz bych se rad vyhnul thread programmingu, v pripade zpracovavani tech callbacku musim vyuzit nejake zamky apod. Vidim zde nasledujici varianty reseni: 1) Jednovlaknovy proces, postupne vytvori spojeni (tj. synchronni bridge te asynchronni knihovny) a postupne posle pozadavky. Vyhody: Velmi jednuduche ba trivialni. Nevyhody: Zpracovani jednoho pozadavku cca 5-10 sekund,tj. casovy rozestup od prvniho a posledniho requestu 1 - 3 hodiny. Neprijatelne. 2) Kazdy server bude mit sve vlakno, tj. 1000x jednoducha operace spojeni + requestu. Pred samotnym vyslanim requestu by vlakna cekaly na nejaky spolecny signal, kvuli synchronizaci. Vyhody: Jednoduche, requesty okamzite (jedine omezeni je cca 100Mbit linka serveru, tj. ocekavam vyrizeni behem max 30 sekund). Nevyhody: Nemam tuseni, jak se bude tvarit proces s 1000 vlakny, co to udela se serverem.Navic se bojim managementu vlaken, deadlocku apod....Navic ciste dlouhodobe muze pocet serveru/vlaken rust do nekonecna. 3) Zcela asynchronni proces. Velmi elegantni reseni jednim vlaknem. Vytvareni okruhu a samotne requesty by kvuli jednoduchosti byly separatni kroky (tj. metoda startujici stahovani by se spoustela az po vytvoreni vsech spojeni, resp. po dostatecnem poctu odmitnuti nekterych spojeni). Problem je,ze v obou krocich se jedna o stavove stroje s mnoha stavy. S riziky asynchronnich procesu a s navrhem takovych uloh nemam zadne zkusenosti. Tj. v jakych datovych strukturach udrzovat jake informace o jednotlivych requestech apod. A vas se ptam - prehlednul jsem neco, co by cely proces zjednodusilo, doporucili byste mi neco jineho nebo mate zkusenosti s navrhem asynchronnich procesu? Diky, Marek
_______________________________________________ Python mailing list [email protected] http://www.py.cz/mailman/listinfo/python
