PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
@Exkalibr: Pokud k tomu grafu nemáš žádné vyhodnocení, tak proč si nám ho sem dal? K čemu nám je užitečný?

Proč by měl řešit, zda je nám ten graf k užitku? Zhodnotit si ho může každý, stejně jako ho každý může ignorovat dle své volby.


@Exkalibr: Pokud k tomu grafu nemáš žádné vyhodnocení, tak proč si nám ho sem dal? K čemu nám je užitečný?
Proč by měl řešit, zda je nám ten graf k užitku? Zhodnotit si ho může každý, stejně jako ho každý může ignorovat dle své volby.
Ano, může si ho každý z nás zhodnotit tak, že bude 2 dny zkoumat zdrojáky a zjišťovat co v tom grafu vlastně je. Proč by tím měl trávit čas každý z nás když to může pár větami shrnout Exkalibr, který tomu ty 2 dny už věnoval.

@Exkalibr: Pokud k tomu grafu nemáš žádné vyhodnocení, tak proč si nám ho sem dal? K čemu nám je užitečný?

Domnívám se, že ten graf mluví za vše, já jsem ho ale okomentoval slovy:

Citace
Jak vidíte, zkopírování 2MB souboru + čtení a zápis v originále už začíná být znát. Nejvyšší čas (v poměru k velikosti souboru) je 2.7 MB.

Zajimavé pro mě je do kdy je užitečné pracovat s jak velkými soubory. S větším souborem nad 2MB se to už přestává vyplácet časově a hypoteticky by se mohlo zvýšit riziko kolize. Zajimavé je, že i když jsem soubor navíc ještě kopíroval u souborů menších než 2MB se to vleze a vyrovná se to křivce T8. T8 byl ten test kde se uplatnil mkdir na hlavní proces (čtení/zápis). Takže výsledky pod 2MB považuji za skvělé. Přece si pamatujete, že T8 hlásilo chyby atomicity.

T10 je řešením pro mě, protože i když kopírování zabírá čas na víc, povedlo se vyloučit chybu atomicity v hlavním bloku (w/r).

Toto řešení alespoň pro mě představuje větší spolehlivost než @mkdir v hlavním bloku.

@Exkalibr: Pokud k tomu grafu nemáš žádné vyhodnocení, tak proč si nám ho sem dal? K čemu nám je užitečný?
Proč by měl řešit, zda je nám ten graf k užitku? Zhodnotit si ho může každý, stejně jako ho každý může ignorovat dle své volby.
Ano, může si ho každý z nás zhodnotit tak, že bude 2 dny zkoumat zdrojáky a zjišťovat co v tom grafu vlastně je. Proč by tím měl trávit čas každý z nás když to může pár větami shrnout Exkalibr, který tomu ty 2 dny už věnoval.

Jenže bez přečtení diskuse se prostě neobejdeš. Jak jinak se dozvíš co je T8? Proč bych to měl opakovat? Ty si přece u toho byl a sám si navrhl T8 @mkdir jako tu pojistku proti přepisům, vlastně si mi taky poradil jak odstranit tu chybu, že kontrola filesize je zbytečná a nespolehlivá. Mě pak došlo, že nemohu rozdělovat proces čtení a proces zápisu na dva bloky, ale musí se vše udělat v jednom.

Hlavní úspěch
je především v tom, že se mi povedlo vyloučit ty selhání zápisu a selhání atomicity, takže T10 je první test s validními výsledky.

Graf pak slouží hlavně pro orientaci v tom, že vidíš jaké jsou zdržení při zápisu na disk když běží 4 procesy ve smyčce bez prodlevy ... a potom jak se ten čas mění, když tam uměle strčíš prodlevu kvůli čekání na uvolnění directory lock.

Ty si přece u toho byl a sám si navrhl T8 @mkdir jako tu pojistku proti přepisům, vlastně si mi taky poradil jak odstranit tu chybu, že kontrola filesize je zbytečná a nespolehlivá.
No právě, byl jsem u toho a ani já se v tom nevyznám. Těch úprav, kódu, grafů a popisů chyb bylo tolik. Každého asi první budou zajímat ty nejrychlejší časy T3-T4 u kterých ses obával nespolehlivosti kvůli bufferování, tak jsem myslel, že to nějak okomentuješ.

Hlavní úspěch je především v tom, že se mi povedlo vyloučit ty selhání zápisu a selhání atomicity, takže T10 je první test s validními výsledky.
Jo i to, že všechny ostatní způsoby kromě T10 jsou špatné jsou výsledek. Pak ale nechápu k čemu jsou ty křivky T2-T8b v grafu když u nich dochází k selhání. K čemu je důležité znát rychlost v sekundách když při tom dochází k selhání?

Graf pak slouží hlavně pro orientaci v tom, že vidíš jaké jsou zdržení při zápisu na disk když běží 4 procesy ve smyčce bez prodlevy ... a potom jak se ten čas mění, když tam uměle strčíš prodlevu kvůli čekání na uvolnění directory lock.
A u kterých T je strčená ta prodleva? Možná jsi to psal na stackoverflow.com a možná je to někde na těch 10 stránách této diskuze. Mám dojem, že u T7 jsi psal o 50 microsekundové prodlevě o které jsi prohlásil, že nemá na měření vliv, ale teď myslíš asi jinou prodlevu.
Už je to jedno, jen jsem myslel, že když jsi tomu věnoval tolik času, že z toho uděláš nějaký výcuc, aby člověk mrkl na graf na popis pod ním a během minuty by pochopil o co jde.


PRODLEVY

T2-T6 mají 50 mikrosekundové prodlevy, které nemají vliv na výsledný čas, ale mají vliv na to jestli dochází k selháním. Protože čím větší je prodleva smyčky, tím větší je pravděpodobnost kolize.

T7 nemá žádnou prodlevu

T8  nemá žádnou prodlevu přímo v hlavním bloku pro čtení a zápis, ale je tam ta prodleva, která se vytváří čekáním na uvolnění zámku vytvořeného přes @mkdir. Tato prodleva je jasně vidět na grafu, protože prodlužuje čas zpracování asi o 1/3 oproti T2 (žlutá čára) a o max. 25-50ms oproti T7.

T8a - (tmavězelenomodrá čára s černými čtverci) je bez korekce
T8b - (bílá čára) po odečtení toho 50 mikrosekundového zpoždění po každém zápisu.

T10 - tam je taky directory lock jako u T8, ale ještě před hlavním blokem (r/w), takže tento hlavní blok se vykoná úplně vždy.

T3 a T4 - bufferování file_get_contents() a file_put_contents()

Ty testy jsem začal dělat proto, že jsem se chtěl bufferování vyhnout. Chtěl jsem najít způsob jak přečíst a zapsat data bezpečně do souboru, aniž bych se musel bát, že když je pozměním, změny nebudou uloženy. Proto mě ty funkce file_get(put)_contents nezajímají, jsou pro mě nepoužítelné.
« Poslední změna: 16. 10. 2019, 21:05:35 od exkalibr »

Pak ale nechápu k čemu jsou ty křivky T2-T8b v grafu když u nich dochází k selhání. K čemu je důležité znát rychlost v sekundách když při tom dochází k selhání?

Protože vidíš, jak by trvala operace, kdyby tam nebyl ten @mkdir s prodlevou na uvolnění zámku. Uděláš si představu, jak rychlý je ten algoritmus i když ho pro toto řešení nevyužiješ.

Z předchozích výsledků například vyplynulo, že když zapisuješ přes file_put_contents do toho samého souboru, ze kterého pak zase čteš a furt dokola, je to rychlejší než když to zapisuješ do jiného souboru.
« Poslední změna: 16. 10. 2019, 21:23:43 od exkalibr »

T3 a T4 - bufferování file_get_contents() a file_put_contents()

Ty testy jsem začal dělat proto, že jsem se chtěl bufferování vyhnout. Chtěl jsem najít způsob jak přečíst a zapsat data bezpečně do souboru, aniž bych se musel bát, že když je pozměním, změny nebudou uloženy. Proto mě ty funkce file_get(put)_contents nezajímají, jsou pro mě nepoužítelné.
No tohle je třeba jedna z věcí co nechápu. file_put_contents má parametr LOCK_EX, takže pokud to budeš mít dobře nastavené, tak se daný soubor zamkne a nic neselže. To, že se to bufferuje je právě výhoda, protože to je nejrychlejší a jak ti Kid hned na začátku diskuze vysvětlil, tak to buferování si hlídá filesystém a nevídím důvod proč bys tuto funkci neměl používat. Nebo místo parametru LOCK_EX můžeš použít mkdir.

Taky jsem počítal odchylky od průměru v testech T2 až T7.


Odchylky od průměru ještě z jiné strany.

Větší soubory v původní velikosti si můžete zobrazit či stáhnout na mém blogu.

https://it-pomocnik.blogspot.com/2019/10/php-results-of-test-atomicity.html
« Poslední změna: 17. 10. 2019, 06:42:41 od exkalibr »

Na blogu jsem updatoval ten poslední obrázek. Ten připojený je vadný (v tom připojeném stejně je prd vidět).

Z odchylek jsem si uvědomil jednu věc, která přesně reflektuje skutečná čísla. Jelikož ten poslední graf čtu zprava doleva, na rozhraní každého nového bloku je vidět velký nárůst odchylky. Vysvětlení je v tom, že nový soubor trvá déle načíst a zapsat. Člověk by očekával mezi jednotlivými testy podobné odchylky, jenže T2 je trochu jiné - vypadá to, jako by se skoková odchylka oproti T6/T7 opozdila o několik cyklů. Na druhou stranu T7 má odchylku ještě před 4495 a 6758, člověk by očekával, že větší odchylka bude na začátku bloku, tak jako u těch menších bloků...

Jenom bych upřesnil, že neustále píšete, že selhávají funkce flock() a file_put_contents() atd., ale ve skutečnosti selhává váš kód. Ty funkce fungují správně, chyby jsou ve vašem kódu.

Jenom bych upřesnil, že neustále píšete, že selhávají funkce flock() a file_put_contents() atd., ale ve skutečnosti selhává váš kód. Ty funkce fungují správně, chyby jsou ve vašem kódu.
Přesně tak. Já jsem myslel, že teď když si Exkalibr ten test doladil, že ho spustil celý znovu a všechny výsledky v grafu jsou SPOLEHLIVÉ zápisy dat, ale vypadá to, že se pořád plácáme v dolaďování testovacího scriptu. Jakýkoliv graf v tuhle chvíli ztrácí smysl. Jediná správná věc je všechno zahodit, napsat znovu test pečlivě (slovy pečlivě) a odprezentovat jediný graf s jasným sdělením. Takhle to vypadá, že cílem bylo pochlubit se uměním vytvářet grafy a testovací script posloužil jen jako generátor náhodných dat.

Jenom bych upřesnil, že neustále píšete, že selhávají funkce flock() a file_put_contents() atd., ale ve skutečnosti selhává váš kód. Ty funkce fungují správně, chyby jsou ve vašem kódu.
Přesně tak. Já jsem myslel, že teď když si Exkalibr ten test doladil, že ho spustil celý znovu a všechny výsledky v grafu jsou SPOLEHLIVÉ zápisy dat, ale vypadá to, že se pořád plácáme v dolaďování testovacího scriptu. Jakýkoliv graf v tuhle chvíli ztrácí smysl. Jediná správná věc je všechno zahodit, napsat znovu test pečlivě (slovy pečlivě) a odprezentovat jediný graf s jasným sdělením. Takhle to vypadá, že cílem bylo pochlubit se uměním vytvářet grafy a testovací script posloužil jen jako generátor náhodných dat.

Blbost. Tady už není co dolaďovat napsal jsem snad jasně, že T10 je dokončený a bez chyb. Není co dolaďovat. K ostatním testům se vracet nebudu, nelze je opravit, když obsahují chyby. Jediné v čem se plácáme dokonala je tvá nechápavost. Psal jsem to už několikrát a nebaví mě to opakovat, že ten graf odráží rychlosti čtení a zápisu a chyby v tom nehrají roli. Když došlo k údajnému selhání fwrite, soubor byl přece načten a zkopírován pomocí copy(). Takže ty časy jsou spolehlivé a věruhodné. Nechápu co to tu furt plácáš.

Jenom bych upřesnil, že neustále píšete, že selhávají funkce flock() a file_put_contents() atd., ale ve skutečnosti selhává váš kód. Ty funkce fungují správně, chyby jsou ve vašem kódu.

Nic jiného netvrdím. Záleží přece na tom jakým způsobem ty funkce použijete a to jsem psal, že já hledám funkci, která umožňuje přístup k souboru více uživateli, načíst soubor, změnit soubor, zapsat soubor. V mých testech není ta změna.