Vývoj náhrady za současný FileJournal

Rekl bych, ze smysl to rozhodne ma. Zda se to dostane do distribuce, to se asi uvidi, az to bude hotove, ze jo:-) Minimalne to bude alternativa. Nicmene pokud to bude tak dobre, jak rikas, tak ta pravdepodobnost, ze se to objevi primo v distribuci je celkem slusna (IMHO).

Ahoj. Dost jsem na vývoji pokročil a mám první měření rychlosti současného souborového a Sqlite žurnálu a mého založeného na B+ stromech.

100 inserts
SqliteJournal: 1.64009404182 s
FileJournal: 26.8340108395 s
BtreeFileJournal: 0.143335103989 s

Clean priority
SqliteJournal: 0.0232048034668 s
FileJournal: 0.0149970054626 s
BtreeFileJournal: 0.0244851112366 s

Clean tag
SqliteJournal: 0.00389790534973 s
FileJournal: 0.0135850906372 s
BtreeFileJournal: 0.00154900550842 s

Jak jde z výsledků vidět, vývoj je na dobré cestě. Ještě mi zbývá optimalizovat mazání podle priority a otestovat jeho chování v konkurenčním prostředí. Poté bych jej uvolnil pro širší použití a v případě, že by se vám zalíbil, mohl by snad nahradit současný souborový žurnál.

já bych řek že to cenu má, nevím kdo by si stěžoval když dostane něco rychlejšího než je současná implementace ;)

Bolo by faj to otestovat na realnom zdielanom hostingu. Ked to testujes na svojej masine, I/O je exluzivne dostupne tvojmu testu. Ked aplikacku presunies na zivy server, I/O (hrabanie disku) obsluhuje desiatky inych aplikacii a tvoj benchmark ma len malu cast v I/O queue.

No a v takejto situaci je treba spravit test aspon niekolko desiatok konkurencnych requestov na aplikaciu. Ziskas tak vysledky z ako tak realnych podmienok.

srigi: Máš pravdu, všechno jsou to syntetické testy, ovšem i tak by výsledky mého žurnálu měly být mnohem lepší než ostatních. Zkusím to otestovat na nějakém freehostingu, tam bývá zátěž dost vysoká.

To jsem zapomněl zmínit: strom se při mazání nyní vůbec nevyvažuje. Vyvažování je totiž mnohem pomalejší, než vyhledávání v nevyváženém stromě. Nějakou jednoduchou a tedy rychlou implementaci plánuji, kvůli úspoře diskového místa.

Teoreticky taková situace nastat v nejhorším případě nastat může, ovšem v reálu je to dost nepravděpodobné. Nějakou zjednodušenou formu vyvažování ovšem v budoucnu plánuji implementovat.

Jinak jsem dokončil testy na hostingu IC s následujícími výsledky:

1000 vložení
SqliteJournal: 38.4401259422
FileJournal: 75.590485096
BtreeJorunal: 2.39867806435

Smazání 400 záznamů podle priority
SqliteJournal: 0.0956561565399
FileJournal: 0.496645927429
BtreeJorunal: 0.0224220752716

Smazání 600 záznamů podle tagu
SqliteJournal: 0.265986919403
FileJournal: 0.241114854813
BtreeJorunal: 0.0310559272766

Tento týden to dám k dispozici na testování.

Dobrá práce! Tak že bych ho dal přímo do Nette? Tak se spíš otestuje.

Přikládám ještě benchmark s kompletně hotovým žurnálem:

Init
SqliteJournal: 0.047590970993 s
FileJournal: 0.000597953796387 s
BtreeFileJournal: 0.000799894332886 s

1000 inserts
SqliteJournal: 8.93768596649 s
FileJournal: 69.2337641716 s
BtreeFileJournal: 1.148884058 s

Clean all
SqliteJournal: 0.0803961753845 s
FileJournal: 0.524681806564 s
BtreeFileJournal: 0.0179469585419 s

Same 1000 inserts again
SqliteJournal: 18.481400013 s
FileJournal: 78.605672121 s
BtreeFileJournal: 0.363624095917 s

Clean priority lower then 400
SqliteJournal: 0.0780811309814 s
FileJournal: 0.597638130188 s
BtreeFileJournal: 0.0151479244232 s

Clean one tag
SqliteJournal: 0.00354504585266 s
FileJournal: 0.00116205215454 s
BtreeFileJournal: 0.000761032104492 s

Clean 3 tags
SqliteJournal: 0.00691986083984 s
FileJournal: 0.00250887870789 s
BtreeFileJournal: 0.00107407569885 s

Clean all other tags
SqliteJournal: 0.0618770122528 s
FileJournal: 0.36325097084 s
BtreeFileJournal: 0.053032875061 s

Clean All
SqliteJournal: 0.0154650211334 s
FileJournal: 0.000211000442505 s
BtreeFileJournal: 0.0049159526825 s

A ta výjimka nastala i s vypnutým debug modem? V něm to všechny nekonzistence poctivě hlásí, jinak si s nimi dokáže poradit. Ale už mám připravený patch, který by jejich výskyt měl drasticky omezit.

Udělal jsem tedy fork Nette na GitHubu, do kterého jsem přidal potřebné opravy. Že Windows načte z exkluzivně zamčeného souboru prázdný řetězec je fakt divné chování, na Mac OS i Linuxu to normálně funguje.

A k tvému druhému požadavku. Funkce file_exists je volána proto, že je rychlejší než fopen a nevidím v tom žádný problém s atomicitou. Pokud soubor neexistuje, funkce @fopen($this->handle, ‚xb‘) se jej pokusí vytvořit a pokud byl již v té době vytvořen, skončí chybou, která ovšem nevyvolá výjimku kvůli druhé kontrole pomocí funkce file_exists. Nebo se v něčem pletu?

V žurnálu se před každou operací (write nebo clean) vytváří exkluzivní zámek a tedy by v ten okamžik neměl nikdy jiný ze souboru číst nebo do něj zapisovat a soubor je odemčen až po provedení všech změn. Jediné místo, kde se četlo bez použití zámků bylo v hlavičce, protože tam na Unixu nebyl potřeba.

A jasně, mezi file_exists a fopen může dojít k vytvoření souboru, ale s tím počítám a proto volání fopen volám se zavináčem. Ale máš pravdu, přímé volání r+b bude lepší.

Ale protože do souboru zapisuje nebo z něj čte pouze FileJournal, který vždy vyžaduje exkluzivní zámek, neměly by být žádné jiné zámky potřeba.

Acci napsal(a):

Ale protože do souboru zapisuje nebo z něj čte pouze FileJournal, který vždy vyžaduje exkluzivní zámek, neměly by být žádné jiné zámky potřeba.

A FileJournalu nevadí, když čte data, která mu někdo jiný přepisuje nebo je ještě nedopsal?

Proces A začne číst data, než je přečte všechny, proces B část z nich přepíše.

anebo proces B zapisuje data, než je zapíše všechna, proces A je nekompletní přečte.

Už tomu rozumím, jediný okamžik, kdy proces čte a přitom nezapisuje, je v tom konstruktoru, takže čtecí zámek patří jen na to jedno místo. Ok.

Mam problem s FileJournal. Vyhadzuje mi to vynimku:

<?php
if (!flock($this->logHandle, LOCK_EX)) {
	throw new InvalidStateException('Cannot acquite exclusive lock on log.');
}
?>

V com moze byt problem?

gmvasek napsal(a):

Jen z tohoto ti nikdo nic nepoví. Přilož chybu z Laděnky, soubor na kterém to padá…

File: FileJournal.php

<?php
/**
 * Lock file for writing and reading and delete node cache when file has changed.
 * @return void
 */
private function lock()
{
    if ($this->handle) {
        if (!flock($this->handle, LOCK_EX)) {
            throw new InvalidStateException('Cannot acquire exclusive lock on journal.');
        }
        if ($this->lastModTime !== NULL) {
            clearstatcache();
            if ($this->lastModTime < @filemtime($this->file)) { // intentionally @
                $this->nodeCache = $this->dataNodeFreeSpace = array();
            }
        }
    }
}
?>

V ladenka vyhodi vynimku: „Cannot acquire exclusive lock on journal.“

hrach napsal(a):

piler: co si nepochopil z vety priloz ladenku? Nazev chyby si tu uz psal…

No, to je prave to, ze nechapem co mam zle. Co je potrebne nastavit, aby tato chyba nebola vyhodena.

Dik.

jasir napsal(a):

Přilož kompletní výpis laděnky, nejen ten error, kapišto?

Skusim to inak :).

Vsetko funguje OK na localhost. Ked som to uploadol live, tak sa prejavila chyba. Chyba vznika presne tu

<?php
if (!flock($this->handle, LOCK_EX)) {
?>

Takze je mozno potrebne nastavit na hostingu nieco, aby flock fungoval spravne. Je problem tam, alebo je problem v $this->handle

Ja že je to vtip, tak čakám v napätí, čo sem pošle :-).
piler: pozri si Nette\Debug

Mam niekedy pocit, ze vy uz poriadne ani neporozmyslate nad chybou, pokial to nie je pekne obalene v Ladenke.
Nechcem zobrazovat Ladenku, lebo obsahuje informacie o URL a ine informacie, ktore zatial zverenovat nechcem.

Ale skusim to inak.

Vo FileJournal.php je kod:

<?php
$this->handle = fopen($this->file, 'r+b');
echo $this->handle; // Resource id #151
?>

Nasleduje funkcia flock(), ktora podla manualu vracia TRUE, alebo FALSE.

<?php
if (!flock($this->handle, LOCK_EX)) {
	throw new Exception('...');
}
?>

A ta vracia FALSE. S ladenky sa neda nic viac vycitat, okrem tychto info co tu pisem. Problem nevidim so samotnym frameworkom, ale s flock() (lebo na localhoste mi funguje spravne). Su tam mozno nejake zavislosti spojene s touto funkciou, ktore sa snazim zistit.

Dakujem za porozumenie :).

Mikulas Dite napsal(a):

Jaký je tam filesystem? Třeba lock nepodporuje.

Neviem. Je moznost to zistit pomocou PHP?

Dik za rozumny reply :)

Zkus pustit syrový

<?php
$handle = /* test handle, nějaký foo soubor */;
var_dump(flock($handle, LOCK_EX));
?>

úplně bez nette, samotné php.

Jestli tohle selže taky, není chyba v Nette/tvojí aplikaci, ale v prostředí.