Dotaz: php concurrency

[rband]

Zdravím,

Při použití mod_php pro Apache s nějakou defaultní konfigurací: pokud dva uživatelé načtou stránku se skriptem ve stejnou chvíli, může se stát, že jsou obslouženi paralelně dvěma thready/procesy, nebo se požadavky zpracovávají jeden po druhém? Jde mi o to, jestli je potřeba např. synchronizovat zápisy do souborů, ke kterým přistupují jen ty php skripty. Uvítám odkazy na relevantní dokumentaci

---

---

Odpovědi

[H0ax]

paralelně
a pokud maj někam zapisovat, tak asi nejlíp do db pač do stejnýho souboru najednou to nebude moc gut

[l4m4]

Pokud se může někdy stát, že různé požadavky povedou k zápisu [do] stejného souboru, tak je zapotřebí zamykat/synchronizovat (nebo raději navrhnout věci tak, aby se to stávat nemohlo).

Bude-li se to dít běžně, tak se ta data nemají válet v souboru, ale být v databázi.

[rband]

Díky za odpovědi. Dostal jsem se k nějaké starší verzi systému OpenCart, který používá místo db prosté csv soubory a nepřijde mi, že by to něco zamykalo. Šťourat se v tom ale nebudu, asi jsem něco přehlédl a je to řešené jinak... doufám

[rband]

(pardon, není to OpenCart ale QuickCart od OpenSolution)

[Ivan]

Je to trochu prasarna, ale pokud ti nic jineho nezbyva, tak si ten soubor zamkni pomoci fcntl(flock). Dulezite je, aby ten soubor byl zamceny po co nejkratsi dobu. Jinak se ti zablokuji worker procesy apache a nejsis tim zablokujes vsechny virtualy na serveru.

[Josef Kufner]

Pokud můžeš, tak se tomu produktu vyhni. Sice jsem ho v životě neviděl, ale to co píšeš, je celkem dobrá nápověda, že to není moc dobře udělané.

Jinak na zamykání souboru stačí udělat flock() na otevřený soubor a souběžné požadavky se v tom místě seřadí a počkají na sebe.

[Kit]

Ve chvíli, kdy pomyslím na flock(), znamená to, že jdu špatnou cestou.

Pokud potřebuji jen append, nic zamykat nemusím, pouze výstup udělám ve formě jediného řetězce < 8 KiB.

Přepisování uvnitř souborů nebo delší řetězce s radostí přenechávám databázím. Umí to lépe než já a hlavně přitom nespadnou do deadlocku. A také vím, že ten záznam tam buď bude nebo nebude, ale data se mi po neúplném zápisu nerozbijí. Je to pohodlnější, rychlejší a spolehlivější řešení.

[Josef Kufner]

A jsi si jistý, že si to mezitím neškytne, systémové volání write() neselže s chybou -EAGAIN (nebo něčím podobným) a mezitím se tam nevloudí kus jiných dat? A co když je potřeba zapsat o pár byte více než 8KB? Celkem běžně vídám v logu překřížené výpisy. Sice ne dost často na to, aby to vadilo, ale dost na to, abych tomu nevěřil.

[Kit]

Ano, jsem a budu si tím jist, dokud mi to někdo nevyvrátí. Pokud je potřeba zapsat delší řetězec, jiné vlákno se tam vloudit může a dokonce je to velmi pravděpodobné.

Překřížené výpisy v logu mohou vzniknout velmi snadno, pokud je výstup proveden více než jedním příkazem. Příkaz

echo $datum,$ip,$text;

je interpretován jako 3 příkazy. Jiné echo se do toho vloudit může.

Nějak si nedovedu představit situaci, při které bych potřeboval zapsat blok dat > 8 KiB a nebyla by výhodnější databáze, která se o potřebné zámky postará sama.

[Josef Kufner]

Dokumentace PHP říká, že:

If handle was fopen()ed in append mode, fwrite()s are atomic (unless the size of string exceeds the filesystem's block size, on some platforms, and as long as the file is on a local filesystem).

Než se spolehneš na atomicitu zápisu, musíš se přesvědčit, že souborový systém má bloky větší než je potřeba zapsat dat a že ten souborový systém je lokální. Nikde není ani slovo o 8KB, i když to nejspíš bude hodnota, kterou obvykle vrátí fstat(). Navíc jsi se ani nezmínil o tom, že se musí jednat o lokální soubor. Tvé tvrzení je tedy nepravdivé, byť za určitých podmínek to může fungovat.

[Kit]

Lokální soubor jsem bral jako základní podmínku. Zřejmě až moc samozřejmě. Na síťových úložištích takové opičky nedělám.

fstat() mi tvrdí, že mám velikost bloku 4096 B, což souhlasí s tím, co jsem věděl předtím.

Při experimentech s konkurenčním zápisem docházelo k mixování až při > 8192 B, což souhlasilo s některým z parametrů php.ini . Při zvýšení hodnoty toho parametru se zvýšil i limit pro mixování. Už nevím, který to byl. Nepotřebuji ho. Používám databáze.

[Ivan]

fwrite mozna atomicky je(za urcitych okolnosti). sekvence "fopen, fseek, fwrite" ovsem atomicka neni.

Jedniny FS na linuxu, ktery podporuje "bezpecny" append bez zamykani je nejaky FS od google, ktery je na to primo delany. POSIX IMHO neobsahuje nic co by vas uvedomilo o tom, ze na konec souboru bylo neco pripsano.

[Kit]

O fseek() nediskutujeme, u něj je snad jasné, že se na to spolehnout nedá. V režimu append mě nemusí zajímat, že mezi otevřením souboru a zápisem do něj se ten soubor prodloužil.

Řešíme otázku, do jaké míry je spolehlivý zápis do souboru otevřeného v režimu append bez použití funkce flock(), což je typické pro zápis do logů.

Testoval jsem to tuším na ReiserFS. Můžu zkusit ještě Ext3, Ext4 a XFS. Případně i FAT

[AraxoN]

Celkem běžně vídám v logu překřížené výpisy.

Používaj funkciu error_log() s parametrom $message_type=3. Za 10 rokov som ešte skrížené záznamy v logu nevidel. Samozrejme, celý záznam musíš zapísať na jedno volanie. Ak skladáš záznam z viacerých častí, najprv si ich pospájaj do jedného stringu a až potom volaj error_log().

[mektige]

Pokud se zapisuje jen jeden řetězec, je uložen vcelku, pokud jeho délka nepřekročí 8192 B. Hodnota se dá změnit v php.ini. To umožňuje například vytvářet logy.

Pro echo s parametry oddělenými čárkou už to neplatí, protože interpretr to už bere jako více příkazů pro výstup. Může se mezi ně vloudit výstup z jiného vlákna.

A jak už psali ostatní: Používej raději DB.

[rADOn]

• Na zamykání nespoléhej. Nikdy nevíš že apačovi z nějakýho důvodu neumře děťátko a zámek zůstane viset. PHP interpet dokonce může sám předčasně ukončit skript kterému se zavřel socket (záleží na nastavení).
• Nepostradatelnost databáze je mýtus. Atomický zápis jde realizovat i bez databáze a dokonce to ani není těžký. Včetně toho nákupního košíku v csv Ale je pravda že databáze je dnes na každým rohu a každej s tím umí zacházet, takže ve výsledku je to většinou nejjednodušší řešení.

[Kit]

Nákupní košík se dá snadno realizovat jak v souboru, tak i v databázi. Ovšem v té databázi je to jaksi pohodlnější a při správném výběru databáze i rychlejší.

[Josef Kufner]

Pokud děťátko umře, tak se soubor uzavře a s tím zmizí i zámek.

[Kit]

Bohužel záleží na druhu zámku. Pokud je ten zámek realizován souborem, tak může zůstat viset i po úmrtí děťátka... Nemám rád takové zámky.

[rADOn]

Přesně tak. Flock i posixové zámky se samozřejmě při pádu odemknou, ale dotaz je na zamykání obecně a třeba synchronizace přes semafory (a přes sdílenou paměť vůbec) to nezajišťuje. Navíc je řeč o php, tedy z principu masivně paralelní úloha kde zamykání může tvořit úzké hrdlo nebo vyhladovět zdroje (zámků nemůžu vzít nekonečno). Ergo je lepší se zámkům vyhýbat jak to je jde. Třeba zmíněný nákupní košík v csv by šlo realizovat pomocí read-copy-update, zapsat změněný soubor někam bokem a přesunout ho na místo původního (rename je atomická operace).