Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: scraper 11. 09. 2018, 13:25:45
-
moje pouziti by byla vicevlaknova extrakce dat z velkeho mnozstvi webovych zdroju napr za pouziti xpath. Musi to bezet 24/7/365
V soucasnosti to mam udelane v Pythonu a nejsem spokojeny. Python doted neumi uvolnit vsechnu jiz nepouzivanou pamet zpet systemu, takze to vypada jako kdyz leakuje pamet coz neni tento pripad.
Advokati pythonu bez legrace doporucuji tyto pripady obejit pres dalsi procesy, coz mi vytvari dalsi zatez na cpu oproti threadum
muj cil je co nejnizsi cpu zatez a memory footprint
popr. muzete doporucit i jiny jazyk
-
Java
-
Rozumne sa to da v c alebo c++ (pokial ide o minimalne naroky), na pracu so sietou (ak to teda ma aplikacia sama tahat) postaci par vlakien pre polling, potom par vlakien na spracovanie. Otazka je co s vysledkami, tie sa mozu ukladat na pozadie do suboru alebo niekam posielat... Otazka je, ako xpath pokryje obsah z webu...
Obvykle sa pamat systemu nevracia, ale ak je to fakt nutne, glibc malloc a tcmalloc to vedia.
-
Nenapisem ti sice aky jazyk ano ale napisem ti preco by som do "C" nesiel.
Z mojho pohladu je C super jazyk, jasne pravidla, dostupna literatura a dobry kompilator, prehladny.. mam ho rad a denno-denne ho pouzivam. ale...
Osobne asi pred rokom(?) som sa pustil do vacsieho projektu v C (multi-thread) a ... nieje to ziadna sranda, uz len napisat dobry kod zabere cas + musis byt o krok vopred.. mno, niekedy sa sam seba pytam preco som nepouzil C++ asi to bola v tej dobe vyzva..
Asi by som siel do niecoho "vyssieho" co ponuka v libkach viac ako "C"... C++11
-
Dost možná, že Cčko, C++ se bude chovat podobně. Namapovaná paměť zůstává procesu do konce procesu - to je vlastnost glibc.
-
moje pouziti by byla vicevlaknova extrakce dat z velkeho mnozstvi webovych zdroju napr za pouziti xpath. Musi to bezet 24/7/365
V soucasnosti to mam udelane v Pythonu a nejsem spokojeny. Python doted neumi uvolnit vsechnu jiz nepouzivanou pamet zpet systemu, takze to vypada jako kdyz leakuje pamet coz neni tento pripad.
Advokati pythonu bez legrace doporucuji tyto pripady obejit pres dalsi procesy, coz mi vytvari dalsi zatez na cpu oproti threadum
muj cil je co nejnizsi cpu zatez a memory footprint
popr. muzete doporucit i jiny jazyk
Mne se na tento typ uloh osvedcil jazyk D (dlang.org), pripadne bych se nebal pouzit c++17
-
V Rustu něco podobnýho dělá někdo tady: https://www.youtube.com/watch?v=LNABJvABhos . Když se člověk Rust naučí, je podle mě určitě pohodlnější na vývoj než C++, ale naučit se Rust do hloubky trvá (to samozřejmě i C++). Jestli u toho nechceš trávit moc času, uvažoval bych o Go, to je jazyk který se naučíš za chvíli a na takovéhle úlohy je jako ušitý.
-
Java
+1
-
Java. Zkusenost z projektu kde se taha paralelne (a na vice serverech) klidne na 10k+ vlaken. Low memory footprint to nema, na cpu je to nenazrane, ale imho pro ten projekt nejlepsi volba (data jdou do rac, pak to spracovavaji dalsi stroje zase v java). Nekdo rikal ze go je idealni pro internetove veci, zkus se treba podivat. Pokud je to domaci projekt na rpi tak pouzi klidne c.
-
C? Ani náhodou! Když už tak C++.
-
Advokati pythonu bez legrace doporucuji tyto pripady obejit pres dalsi procesy, coz mi vytvari dalsi zatez na cpu oproti threadum
thready v pythonu - kdyz mas IO bound zatez
multiprocessing kdyz mas CPU bound zatez
kdyztak pouzit python 3.6+ a podivat se na async.
A ne s jakymkoliv GC se ti bude zdat ze to uvolnuje pamet pomalu. A pokud to Fakt leakuje tak tam mas nekde chybu.
BTW. skoro vsechny xml parsery jsou brany jako unsafe
-
Pokud chces maximalni vykon a npotrebujes skalovat pres vice servru najednou, tak urcite c++. Pokud potrebujes obecne skalovatelnou vec, tak to pak zalezi na frameworku ale obavam se ze v c++ nic free nenajdes.
-
Obecne skalovatelnou - myslim multi-zelezovou.
Jinak aspon c++14, idealne c++17
-
Ja osobne bych to vyuzil k tomu, ze bych se poradne naucil Go.
pak az to co umim java nebo c++17
-
Dost možná, že Cčko, C++ se bude chovat podobně. Namapovaná paměť zůstává procesu do konce procesu - to je vlastnost glibc.
Ano, je to vlastnost glibc a nikoliv samotného jazyka. C má tu výhodu, že si alokaci můžu řešit sám přesně podle potřeb aplikace. Java sice umí vracet paměť operačnímu systému, ale memory footprint bude mít násobně vyšší než ruční lowlevel implementace.
-
moje pouziti by byla vicevlaknova extrakce dat z velkeho mnozstvi webovych zdroju napr za pouziti xpath...muj cil je co nejnizsi cpu zatez a memory footprint
To jde trochu proti sobě. Nejnižší cpu zátež a memory footprint docílíš s jednoprůchodovým parserem - SAX a ne s xpathem. Ale pokud trváš na xpath, zkusil bych C++ a pugixml.
-
Pokud zpracováváš hodně dat a chceš max výkon tak C++ a k tomu nějaký Arena alokátor by mohla být dobrá kombinace. Já bych první verzi něčeho takového zbastlil v node.js - scaling je built-in a C++ addon pro nouzové případy se dá napsat snadno - těžko říct jestli bych chtěl komplet věc dělat v C++.
-
Pokud zpracováváš hodně dat a chceš max výkon tak C++ a k tomu nějaký Arena alokátor by mohla být dobrá kombinace. Já bych první verzi něčeho takového zbastlil v node.js - scaling je built-in a C++ addon pro nouzové případy se dá napsat snadno - těžko říct jestli bych chtěl komplet věc dělat v C++.
Presne proto casto preferuji dlang, programovani v nem je velmi pohodlne (pro mne i vice nez v js) a vykon shodny s C++. Ne ze bych mel neco proti kombinaci vice jazyku, ale pokud muzu tak preferuji vse napsat jen v jednom.
-
Scrapovaci aplikace v C nebo Rust? To je honirna.
Mas to jako hobby projekt, negeneruje ti to zisk ani se nechystas, tzn. mas malej budget a mas hodne casu? Jo nauc se rust, stejne to mas jako zaminku se ho naucit.
Nebo to generuje penize? Tak kup X ec2 instanci boha jeho kolik je libo.
Python neumi uvolnovat pamet? Bud ti leakuje knihovna nebo ty neumis uvolnovat pamet. Jestli mas cas tak se nejdriv nauc radsi poradne python.
Dobry by bylo sdelit jestli ti jde vic o to aby ti fungovala ta aplikace nebo abys mel duvod se neco novyho naucit a hodit si to do cv.
Nekdo tady zminoval 100000 vlaken v jave. To mas tolik jader na cpu kamo? Nauc se rozdil mezi paralelismem a konkurenci.
Na stahovani ti postaci jeden az par python procesu na hodne slaby masine s asyncio nebo jinym green threadingem. Procesovani dat pak posli do jinyho systemu, kterej pouzije tolik vlaken kolik mas jader.
-
To zní jako úloha pro Go. Jinak D(lang) nebo Rust by šli nejspíš taky, ale nejvíc se mi tam skutečně hodí to Go.
-
Jednoznacne java/C# v tychto jazykoch je to bezstarostne a bezbolestne, v C aj Rsute to bude viac trapenia.
-
Python neumi uvolnovat pamet? Bud ti leakuje knihovna nebo ty neumis uvolnovat pamet. Jestli mas cas tak se nejdriv nauc radsi poradne python.
Co jsem pochopil, tak problém je, že nevrací paměť OS (dělá se to přes madvise, myslím). Což může být trochu problém, pokud je to long-running process se špičkama a na tom stroji běží i něco jiného třeba v jiné časy. Druhá otázka je, jestli to fakt je problém a autorovi jenom nevadí číslo v "top"u.
Jinak já bych na to klidně použil Haskell... paměť OS to pokud vím vrací (akorát brk to má udělaný na 1TB, ale to ničemu nevadí), paralelismus je easy, celý se to zkompiluje do jedný binárky, která nabíhá velmi rychle. Standardem jsou green-thready běžící na OS-threadech podle počtu corů, celý to je async, ale jako programátor jsi od toho odstíněný a normálně píšeš synchronní kód. Vzhledem k tomu, že tady je typicky bottleneck síť tak budeš chtít mít jeden thread na spojení, hodně otevřených spojení.
Vůbec netuším, jak se to dneska řeší v Javě/C++/Rustu. Java pokud vím green-thready nepodporuje, C++ taky ne a Rust má nějaké futures? Python má nějaké korutiny... Nebo je dneska podpora OS na úrovni, že není potřeba o rozdílu mezi user-process threadama a OS threadam uvažovat?
-
Skusil by som C++ s tymto http://seastar.io/
-
Na tyhle typy uloh je primo delane GO.
Kazdy jednotlivy crawler do masivniho poolu gorutin (klidne 1000 palalelnich crawleru), prametry predavat input channelem, vysledky serializovat zase v output channelu.
Dokonce i ty jednotlive crawlery muzes rozparalelizovat do pipelines propojenych channely:
https://blog.golang.org/pipelines
A pokud i tohle by bylo malo, jednoduse pomoci NATS message busu to rozfrcas na vice masin, kazdy poresi balik vstupnich dat.
Ale drive nez zacnes, chce to overit, jestli v GO zvladnes ten XPATH search a podobne serepeticky, tedy nejprve jedoduchy PoC, ktery udela jede seriovy crawler, rozmlatit to do gorutin udelas pozdeji jednoduse, to je hlavni vyhoda a krasa GO.
A pokud to nepude, jako safe reseni bych zvolil Jawu, tam pude vsechno, akorat krapet systemove nenazrane, a mozna to bude i rychlejsi nez GO.
C/C++ je pro tenhle typ uloh sebevrazda, 80% casu budes resit okolostojicnosti typu hlidani threadu a memory alokaci, v GO nebo Jave nebudes resit vubec nebo jednoduseji.
-
Apropos, Oracle slibuje pridat korutiny do Jawy. Az to tam bude -> one jawa rules them all.
-
Apropos, Oracle slibuje pridat korutiny do Jawy. Az to tam bude -> one jawa rules them all.
Az clovek premysli, jak mohlo lidstvo tak dlouho zivorit bez korutin. Hrozne.
-
Apropos, Oracle slibuje pridat korutiny do Jawy. Az to tam bude -> one jawa rules them all.
Az clovek premysli, jak mohlo lidstvo tak dlouho zivorit bez korutin. Hrozne.
Ano.
Z nedostatku vitaminu C vznikaji kurdeje.
A z nedostatku korutin vzniklo Node.js
-
C C++ - presprilis
java - lepsi, ale zbytecny. nema green threading. na tyhke veci hnus
go - ma green threading, ale je staticky typovanej = jakmile pracujes s json objektama tak se z toho poblijes
python - ma green threading, ma rychly parsovani xmlek s xpath pres lxml
python asyncio je mechanismus jak pouzivat green threading v synchronnim kodu, tzn. zadny spagety a callback hell.
pro tyhle aplikace nema smysl pouzivat nic jinyho. Dobra knihovna na praci s http je aiohttp.
Nerikam ze neexistuje neco lepsiho, ale dosavadni navrhy tady ve vlaknu pochazi od lidi, co v tomhle nemaji zkusenosti.
-
u Pythonu to leakovani nemusi byt nutne diky spatnemu kodu https://doc.scrapy.org/en/latest/topics/leaks.html#leaks-without-leaks
-
muj cil je co nejnizsi cpu zatez a memory footprint [...] popr. muzete doporucit i jiny jazyk
Cokoliv s NIO a korutinami - malý memory footprint bude mít C++, Rust i Go.
-
u Pythonu to leakovani nemusi byt nutne diky spatnemu kodu https://doc.scrapy.org/en/latest/topics/leaks.html#leaks-without-leaks
Ten clanek se tyka prehistoricky verze python2.5, nebo ctu spatne?
Odkaz na python3 z tvyho linuk je z roku 2006.
Python Memory Management Part 3: The Saga is Over
[ 2006-March-25 14:52 ]