Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Ať si to platí sami.Ano ať si to platí, ale to jim musíš říct ty a vysvětlit jim, že se s tím nebudeš drbat 10x déle jenom, aby ušetřili pár svých stokorun. Vzpomínám si na jednu reportáž jak "sběrači" kovů týden kopali měděné kabely a dostali za to 1000 Kč, pak se na ten hluboký výkop díval majitel stavební firmy a říká: "Kdyby se ti kopáči u mě nechali zaměstnat, tak si za to kopání vydělají 5000 Kč". Ale jestli tohle vše děláš kvůli učení a zkoumání, pak to beru.
Pokud se učí a zkoumá vlastnosti souborových systémů na hostingu, který neptá peníze, tak ho nechej být.Pokud jde o zkoumání a učení se, pak proti tomu nic nemám. Ale i při učení platí efektivita, např. raději koupit učebnici za 500 Kč než brouzdat po netu a učením strávit o rok déle. Pokud mu freehosting pro jeho potřeby poskytne to samé co placený, tak ať vezme free, ale podle toho co Exkalibr napsal jsem měl pocit, že ho bude limitovat a výsledkem těch limitů bude o hodně více stráveného času. Ale jak říkám pokud zkoumá a učí se, tak nic proti.
Myslím, že na Filipa útočíš neprávem. Snaží se ti slušně říct, že někdy je levnější za věci zaplatit než je mít zdarma. Až budeš starší příjdeš na to sám. Raději dát pár stovek ročně než přijít o několik víkendů kdy budeš řešit chyby v tom systému. Taky připočti častější výpadky na freehostingu ze kterého návštěvníci taky nebudou nadšeni. Existuje spousta koníčků a projektů co dělá člověk pro radost a nic na nich nevydělává.A k tomu hostingu zdarma – slušný webhosting seženete už okolo 50 Kč za měsíc. Už jenom psaním těch podivuhodných testů jste propálil tolik času, že byste za to tu aplikaci provozoval několik let.
Nedám ani korunu za web, který nevydělává, leda že by si za to návštěvníci ten hosting sami zaplatili. Ale u webu který nemá žádnou návštěvnost asi těžko. Navíc mě těmi svými blbými řečmi rozpalujete doběla. Soudíte druhé lidi podle sebe, jenže vy jste profík, můžete si dovolit strávit u počítače kolik času chcete. Vůbec jsem z těch vašich subjektivně laděných soudů znechucen. To je jak bavit se s blbým člověkem, už jsem vám říkal, že hosting placený nechci a ten neplacený má kapacitu jen 20MB. Taky jsem psal, že tu databázi použiju, ale rozhodně ne na registraci. A tento týden se databází rozhodně zabývat nebudu. To jakým tempem pracuju je moje věc, do toho vám nic není pane.
. Čau.
A jsi si jistý, že je možné správně zjistit velikost souboru, když je soubor otevřený pro zápis?Tím si jistý nejsem, to musíš vědět ty, je to tvůj domácí úkol
. Já jen vím, že zjišťování velikosti souboru, kdy do něj jiný proces zapisuje není správné, takže to vypadá, že nešlo o žádné skutečné chyby při zápisu, ale pouze jsi špatně srovnával velikost source a target souboru.
Jestli myslíš tím "selhání zápisu" tento blok:Když ti více PHP procesů zároveň provede řádek "fopen $tname" a pak jeden proces přejde na řádek flock lock_ex, tak neskončí ti náhodou zbývající procesy hláškou "Couldn't get the lock!"?Všechny chyby, které nastaly jsem už popsal, jednalo se tam o selhání zápisu nic víc. Všechny hlášky mám ošetřené. flock neselhal ani jednou, vždy byl výsledek true.
$fsize = filesize($tname);
if ($original_size>$fsize)
{
echo "; <b>WRITE FAILED, restoring</b>;";
$original_fname = "$n";
$result = copy($original_fname, $tname);
if ($result == false )
die(" <b>TOTAL FAILTURE: copy failed.</b>");
else
echo " <b>RESTORED</b>;";
}
else
...
Viděl, ale je to pro mě nepřehledné a nechce se mi v tom vrtat, ale jen tak namátkou. V tom T7 co máš na stackoverflow.com vidím zhruba toto:Teď jsem opakoval T7 jen s 6 cyklama a jen ze dvou prohlížečů a přesto došlo ke 4 kolizím. Oproti tomu T8 s 10 cyklama ze čtyř firefoxů udělal jen 1 chybu ... za bez použití file_exists. Ale taky se dívám že výsledná doba čekání u toho selhání byla poměrně malá 0.864s.Tohle testování je k ničemu. Pokud nemáš správně zámky, tak pořád testuješ nezamknuté soubory a vůbec není podstatné kolik je tam chyb. Pokud paralelní php scripty pustíš přesně ve stejný okamžik, tak tam těch chyb bude teoreticky více než když je spustíš s malým časovým odstupem - časový odstup u takového testu sníží riziko překřížení mezi jednotlivými PHP procesy.
Ale ty zámky jsou přece nastaveny správně, copak si neviděl kód?
Ano souhlasím, jen jsem narážel na to, že tady Exkalibr pořád háže nějaké čísla s počtem chyb, které mají jen tu vypovídací hodnotu, že to má špatně zamknuté. Jestli je tam 1 chyba nebo 30 chyb, tak je to jedno.Teď jsem opakoval T7 jen s 6 cyklama a jen ze dvou prohlížečů a přesto došlo ke 4 kolizím. Oproti tomu T8 s 10 cyklama ze čtyř firefoxů udělal jen 1 chybu ... za bez použití file_exists. Ale taky se dívám že výsledná doba čekání u toho selhání byla poměrně malá 0.864s.Tohle testování je k ničemu. Pokud nemáš správně zámky, tak pořád testuješ nezamknuté soubory a vůbec není podstatné kolik je tam chyb. Pokud paralelní php scripty pustíš přesně ve stejný okamžik, tak tam těch chyb bude teoreticky více než když je spustíš s malým časovým odstupem - časový odstup u takového testu sníží riziko překřížení mezi jednotlivými PHP procesy.
V testech je naopak výhodné, pokud se ty procesy co nejvíc potlučou mezi sebou - proto jsou ty časové odstupy zbytečné a kontraproduktivní.
Ano uklízení po mkdir() musíš ošetřit ručně. Nevím jak je to přesně u flock(), ale předpokládám, že i tam se ti zámek může seknout a pak musíš mít nějakou vlastní funkci, která ji natvrdo odblokuje.Myslím, že flock není atomický - https://www.reddit.com/r/PHP/comments/9ec4tz/a_locking_file_cache_in_php/e6cqg19/V podstatě tam píší jen to, že mezi voláním fopen() a flock() si ten soubor může zamknout někdo jiný. Tedy nic, co by se nedalo ošetřit testem návratové hodnoty flock().
Začíná se mi pomalu vybavovat, proč jsem se tenkrát rozhodl využít pro zamykání mkdir
Zamykání přes mkdir() má nevýhodu v tom, že když ten proces spadne, kdo to po něm uklidí?
Myslel jsem to tak, jak se píše v tom odkazu, tzn. že mezi fopen a flock se může dostat jiný proces. Spolehlivější mně připadá zapisování s file_put_contents, který může mít parametr LOCK_EX. (To samozřejmě v praxi neřeší problém čtení, kde mezi čtením a zápisem může druhý PHP proces zapsat do čteného souboru - tím dojde ke ztrátě dat z tohoto druhé PHP procesu, protože daný soubor v zápětí přepíše ten první PHP proces. Tohle si musí programátor ošetřit ručně.)Myslím, že flock není atomický - https://www.reddit.com/r/PHP/comments/9ec4tz/a_locking_file_cache_in_php/e6cqg19/Mohl byste to rozepsat? Atomicita znamená, že se daná funkce provede celá nebo vůbec a že nikdo nemůže vidět nějaký vnitřní mezistav té funkce. V případě zámků atomicita znamená, že na souboru nějaký zámek je nebo není – nemůže nastat stav, že by tam zámek byl tak trochu. Atomicita se ale samozřejmě posuzuje z hlediska jedné funkce – to, že se něco může stát před voláním flock() nemá na atomicitu funkce flock() vliv.
Teď jsem opakoval T7 jen s 6 cyklama a jen ze dvou prohlížečů a přesto došlo ke 4 kolizím. Oproti tomu T8 s 10 cyklama ze čtyř firefoxů udělal jen 1 chybu ... za bez použití file_exists. Ale taky se dívám že výsledná doba čekání u toho selhání byla poměrně malá 0.864s.Tohle testování je k ničemu. Pokud nemáš správně zámky, tak pořád testuješ nezamknuté soubory a vůbec není podstatné kolik je tam chyb. Pokud paralelní php scripty pustíš přesně ve stejný okamžik, tak tam těch chyb bude teoreticky více než když je spustíš s malým časovým odstupem - časový odstup u takového testu sníží riziko překřížení mezi jednotlivými PHP procesy.
Ta prodleva je zdrojem problémů u T8. ... V praxi stejně ke kolizi dojde málokdy a když k ní dojde tak ověřením ji mohu obnovit ze zálohy.Jestli se bavíme o situaci kdy máš soubor zamknutý, tak dokážeš ty "problémy" a "kolize" ke kterým dojde málokdy nějak jednoduše pojmenovat? Z toho co jsi psal před tím jsem to nepochopil. Jediný "problém" co mě napadá by měl být ten "maximum execution time" o kterém jsem psal. A pokud ti dochází k jiným kolizím při zamknutém souboru, tak bych řekl, že to zamykání máš špatně, např. kvůli tomu file_exists o kterém psal Kid.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.