Lazy and Eager Acquisition

Prezentace na téma: "Lazy and Eager Acquisition"— Transkript prezentace:

1 Lazy and Eager Acquisition
1 1 1 1

2 Lazy (líný) vs eager (dychtivý, netrpělivý)
Lazy vs Eager Lazy (líný) vs eager (dychtivý, netrpělivý) 2

3 Lazy Acquisition 3 3 3 3

4 Příklad – Elektronická zdravotní karta
Doktor chce zkontrolovat elektronickou zdravotní kartu Jméno Adresa RT snímky, MR, CT... Tyto údaje mohou být čerpány z mnoha zdrojů pojišťovna, servery, databáze, souborový systém Pokud má pacient mnoho záznamů (např. často absolvoval RT), načtení všech jeho snímků může trvat dlouhou dobu Je docela možné, že by se doktor zajímal jen o poslední záběry (od zranění) a ty staré by byly zbytečně načtené – zbytečné čekání Potřebovali bychom systém, který nebude záviset na tom, jaká dlouhá je zdravotní karta pacienta 4

5 Příklad – Elektronická zdravotní karta (Vylepšená)
Mohli bychom si data všech objednaných pacientů na dnešek načíst ráno Nebo Během současného pacienta bychom si načetli následujícího ... Načteme jen data (např. textové) o tom, že dané snímky máme a pokud se lékař bude chtít podívat detailněji, tak se načte celý snímek v plný kvalitě 5

6 NV Lazy Acquisition – idea
Práci budeme odkládat úplně do poslední chvíle, dokud to bude možné 6

7 Kdy? Pokud řešíme problémy jako:
Získání všech prostředků na začátku není vždy nejlepší volba počáteční inicializace může trvat dlouho Není zaručeno, že všechny inicializované prostředky (plně) využijeme Je možné, že jsme některou práci dělali zbytečně 7

8 NV Lazy Acquisition – použití
Pokud v aplikaci potřebujeme zajistit vysokou propustnost a dostupnost při omezených prostředcích Tento návrhový vzor posouvá získání prostředku na nejpozdější možný okamžik, kdy již není možné posunout danou operaci 8

9 NV Lazy Acquisition – členové
Resource user – získává a používá prostředky (lékař) Resource – libovolný prostředek (RT snímek, jméno, záznam) Resource proxy – zprostředkovává získání nového prostředku nebo již získané prostředky prodává uživateli, zakrývá přímé vs lazy získání prostředku (informační systém) Resource provider – postará se o získání prostředku (načtení z databáze, serveru, file systému...) 9

10 NV Lazy Acquisition – implementace
10

11 NV Lazy Acquisition – implementace
11

12 NV Lazy Acquisition – implementace (poznámky)
Resource proxy je vytvořena na začátku při inicializaci má stejné API jako Resource 12

13 NV Lazy Acquisition – výhody
Dostupnost - systém získává pouze ty prostředky, které je třeba (nezabývá se těmi, co netřeba) Stabilita – menší pravděpodobnost zahlcení systému Optimální start systému – nezabývá se načtením dát na začátku, takže start je rychlý Transparentnost – je transparentní z hlediska uživatele Pořízení prostředku – přímé vs lazy 13

14 NV Lazy Acquisition – nevýhody
Paměť – Spotřebovaná paměť na proxy Čas – některé získání prostředku může trvat déle Nepředvídatelnost – pokud získání nějakého prostředku budou více členů nechávat na poslední chvíli a pak se vše najednou spustí, může nastat zahlcení 14

15 NV Lazy Acquisition – použití
Singleton objects (lazy instantiation) Operating systems (library loading) Haskell (lazy evaluation of expressios) JIT(Just-In-Time) překlad 15

16 Eager Acquisition 16 16 16 16

17 Příklad – Operační systém
V operačním systému potřebujeme v různých případech: Dynamicky alokovat paměť Navázat síťové spojení Spustit vlákno pro nějakou úlohu Získání takových prostředků může trvat netriviálně dlouho Během toho mohou vzniknout ještě různé výpadky, čekání Potřebujeme mechanismus, který bude připraven co nejdříve vyhovět danému požadavek ... 17

18 Příklad – Operační systém (vylepšený)
Globální proměnné pro jednotlivé prostředky Nebo Alokace na zásobníku ... Prostředky si někde připravíme v časovém rozmezí od startu po prvé použití daného prostředku 18

19 NV Eager Acquisition – idea
Práci se snažíme provést co nejdříve 19

20 Kdy? Pokud získání prostředků:
Za runtime může způsobovat netriviální zdržení aplikace Musí být rychlé a předvídavé Musí být spravedlivé k ostatním 20

21 NV Eager Acquisition – použití
Návrhový vzor popisuje, jak je možné získání prostředků optimalizovat předčasným získáním, před jejich prvním použitím Vytvoří se kontejner, do kterého se (v době od startu po jejich použití) připravují dané prostředky V případě požadavku je máme hned k dispozici 21

22 NV Eager Acquisition – členové
Resource user – získává a používá prostředky (aplikace, program) Resource – libovolný prostředek (paměť, připojení, vlákno) Provider proxy – Udržuje získané prostředky v container-u, které zprostředkovává a předává uživateli. (Thread pool, Memory pool,...) Resource provider – stará se o získání prostředku, je možné vynechat přímým použitím Resource (OS - přidělení paměti, vlákna, připojení, …) 22

23 NV Eager Acquisition – implementace
23

24 NV Eager Acquisition – implementace
24

25 NV Eager Acquisition – implementace
25

26 NV Eager Acquisition – implementace (poznámky)
ProviderProxy Je vytvořena na začátku při inicializaci má stejné API jako Resource Udržuje container daných prostředků, který se „nafukuje“ Při požadavku vrátí daný prostředek v O(1) „Nafukování“ bychom mohli zajistit i paralelně Čas, kdy proběhne nafukování, může být konkrétně určený 26

27 NV Eager Acquisition – výhody
Rychlost – získání prostředku může být konstantní Předvídavost – prostředky jsou připraveny v containeru Transparentnost – je transparentní z pohledu uživatele 27

28 NV Eager Acquisition – nevýhody
Správa získaných prostředků – uvolnění paměti, likvidace ... Statická konfigurace - počet prostředků se musí odhadnout na začátku ... Zahlcení systému Pomalejší start 28

29 NV Eager Acquisition – použití
Pooling Servery AOT (Ahead-of-time) preklad Křeček (Škrečok, Hamster, 倉鼠)  29

30 Lazy and Eager Acquisition - shrnutí
Oba vzory jsou extrémy ... Použitím těchto návrhových vzorů optimalizujeme v programech to, že získání prostředků proběhne v ten správný moment Návrhový vzor Lazy Acquisition je vhodné použít v případech, kdy získané prostředky nejsou používány ihned Návrhový vzor Eager Acquisition je vhodné použít v případech, kdy se klade důraz na čas – např. v real-time aplikacích; dříve získané prostředky se mohou ihned začít používat 30