Optimalizace dělení na části

[JanPalasek]

Ahoj,

protože se nyní každé další dvě vlákna spouští až po 60 sekundách, velmi by pomohla optimalizace dělení částí. Těchto 60 sekund taky dává jakýsi interní limit, kdy má ještě cenu nastartovat další vlákno (třeba pokud bychom dle odhadu stáhli celý soubor za 50 sekund za použití 2 částí, nemá cenu jich startovat víc, i kdyby si to uživatel přál). Vypracoval jsem menší analýzu a přišel jsem na vzorec, který popisuje, jak optimálně rozdělit části.

Metoda spočívá v tom, že nechá všechna vlákna, která nastartuje, celkově stahovat stejně dlouhou dobu (tzn. všechna skončí ve stejnou chvíli). Přidělí jim tedy tak velké úseky, aby to takto vycházelo.

@setnicka Pro jednoduchou a přímočarou implementaci bude potřeba limitovat počet částí na sudá čísla (protože startujeme pokaždé dvě vlákna). To by předpokládám nebyl problém, ne? Lichá čísla by vyžadovala nějaké hackování.

Optimální dělení částí také vyžaduje znát rychlost stahování jednotlivých vláken. Toto se dle @JanPokorny liší případ od případu. Mohli bychom použít nějakou rozumnou hodnotu, třeba 200.

Přesto však by tento výpočet dělení částí měl být efektivnější než aktuální implementace, protože téměř cokoliv, co přiřadí prvním vláknům delší část pro stáhnutí je prostě lepší.

analysis.pdf

[setnicka]

Jo, nad tím jsem taky přemýšlel, ale analýzu jsem neudělal... a už vůbec mě nenapadlo ji TeXat :D

Jedno ze řešení v současném kódu je rozsekat to na vážně hodně částí, protože to v současnosti umí znovupoužívání stahovacích linků od dostahovaných částí. Takže postupně každou minutu narůstá počet stahování o 2 a pokud se velikosti částí zvolí tak, aby je to dostahovalo třeba taky za minutu, tak se využití začíná blížit optimu.

Volit různé velikosti částí je druhý způsob optimalizace toho samého. Jsem klidně pro to rozpracovat víc, protože moc velký počet částí s sebou nese zbytečný overhead.

[JanPokorny]

@setnicka To znovupoužití by nefungovalo, ten limit je na 2 nová stahování za minutu pro IP adresu, bez ohledu na link.

[setnicka]

@JanPokorny Současná verze ulozto-downloaderu to znovupoužívání dělá, recykluje linky. Dám stahovat file rozdělený na 30 částí velkých zhruba 10MB (aby stahování jedné části vyšlo zhruba na minutu):

• v první minutě stahuje part 01 a 02
• po minutě získám další dva stahovací linky a začnu stahovat 03 a 04, zároveň se mi dokončí první dvě části a jejich linky se přepoužijí na 05 a 06
• po další minutě získám nové linky na 07 a 08 a zároveň se mi přepoužijí linky od dostahovaných částí a stahuji tak i 09-12
• ... a tak dále, každou minutu mi narůstá počet stahovaných částí o 2 a přitom se mi přepoužívají linky již dostahovaných částí

Reálný pokus na

ulozto-downloader --auto-captcha --parts 30 "https://ulozto.cz/file/TKvQVDFBEhtL/debian-9-6-0-amd64-netinst-iso"

Uloz.to podporuje abys na jeden link, který vypadne po ověření CAPTCHA, poslal více range requestů. Je to podpora pro přerušená stahování.

[JanPalasek]

@setnicka @JanPokorny Dnes jsem přerušil stahování, a pro navázání jsem musel zas vyplňovat všechny captcha kódy (a čekat). Ještě to někdy ověřím.

Pokud bychom to měli splitovat na hodně malých úseků, tak si uživatel nenastavuje maximální povolenou rychlost stahování. Musel by se na toto přidat parametr maximální počet stahujících vláken v jednu chvíli. Možná by bylo dokonce lepší, abychom splitovali v takovém případě automaticky na malé části, a uživatele nechali nastavovat právě ten maximální počet vláken, aby tak limitoval rychlost.

V mé variantě zase bude potřeba možná upravit implementaci navazování stahování. Bude si nutné nějak pamatovat, jak který je který úsek dlouhý. Poslední úsek bude potenciálně delší kvůli nepřesnosti odhadu rychlosti stahování vláken, a tomu, že není stejná (rychlost) napříč vlákny. Dalo by se reusovat možná, ale asi zbytečná komplikace.

[muniv11111]

Mimochodem nedíval se někdo jak je to na free webshare.cz? Já to zkoušel v srpnu s mými chabými znalostmi upravit pro webshare a tuším jsem došel k tomu že nějak nepodporujou na serveru právě ten range výběr.. takže kdyby to udělalo i uloz.to tak tohle padá ?? může se k tomu vyjádřit někdo více znalý? :-)

[setnicka]

@JanPalasek Tady nejde o přepoužití linků mezi dvěmi nastartováními ulozto-downloaderu. To co jsem myslel je přepoužití stahovacích linků v rámci jednoho spuštění ulozto-downloaderu z částí, které se již dostahovaly.

[JanPokorny]

@setnicka Aha, chápu, ty obejdeš tu kontrolu protože se provádí jen před ověřením captcha. To zní jako optimální dynamické řešení, stačí zvolit velikost části tak aby byla přibližně na minutu (což jde i dynamicky ladit)

[JanPokorny]

@setnicka Ve Vžum jsem to implementoval podle @JanPalasek (uživatel zadá rychlost a na základě té a velikosti souboru se určí počet částí a jejich velikosti), a funguje to krásně. Konstanty pro rychlost a startovací latenci jsem změřil empiricky, vyšlo mi 180 kB/s pro rychlost jedné části a 14s nastartování jednoho vlákna. (To druhé se u tebe možná bude lišit, už jen kvůli odlišným implementacím Toru.)

[mazmar]

nebo by to slo urcovat dle velikosti dilku, nastavil bych ze chci 14MB cast, stahne to info zjisti ze to ma 7GB, tedy 500x14 tak nastavi pocet casti na 500? co vy na to?

[kkoouu]

nebo by to slo urcovat dle velikosti dilku, nastavil bych ze chci 14MB cast, stahne to info zjisti ze to ma 7GB, tedy 500x14 tak nastavi pocet casti na 500? co vy na to?

K cemu by to bylo ? Jak nekoho napadne, ze chce mit jeden dil o velikosti 14MB ?

[mazmar]

14Mb je optimalni velikost :D akorat 2min pri 170Kbit/s ja mam 1Gbit sit takze je pro mne optimalni mit co nejvic aktivnich spojeni. Ale mensi nez 14Mb uz je zbytecna rezie