ugrás a tartalomhoz

AdoDB-t cache miatt érdemes használni?

Anonymous · 2006. Jún. 14. (Sze), 21.58
Az AdoDB-t mikor érdemes használni? Ezt olvastam a Wikipédián:

* Native PHP MySQL Commands: 93.20 pages per second
* ADOdb Lite: 54.62 pages per second
* ADOdb: 17.40 pages per second

Ez találatokat jelent, sorokat? Ha cachelni szeretnék, mást nem - tehát csak a cache miatt kellene az AdoDB -, akkor jó választás ez? Vagy írjak magamnak cache-t?

Köszi a választ!
‹ Két adatbázis tábla használata szűretlen adatok kezelésére Szótöredék egyezésének vizsgálata ›
 ■
1

Cache szempontjából talán mindegy

Török Gábor · 2006. Jún. 14. (Sze), 22.22
AdoDB többek között azért lehet jó választás (ahogy más régeteknél is), mert hordozható lesz a kódod, majdnem mindegy, hogy PgSql az adatbázismotorod vagy egy MsSQL kiszolgálóhoz csatlakozol. Természetesen ennek költsége jelentkezik a tejlesítményben. Az AdoDB nagyon sokrétű, érdemes átbogarásznod a projekt lapját. Számos esetben tudásának igen kis százalékára van szükség, ezért is született egy "könnyebb" változata Lite néven. Ez - ahogy te is idézted - teljesítményben jobb lehet. Ha tudod, hogy az alkalmazásod (észszerű időintervallumban ~ soha) nem kerül át más adatbázis motorra, használhatod szerintem nyugodtan a MySQL natív függvényeket. A gyorstárazást valamennyi lehetőség biztosítja (AdoDB Cache, MySQL SELECT CACHE) inkább az a kérdés, hogy melyik eszköz a megfelelőbb neked más szempontok szerint.
2

ehh

Anonymous · 2006. Jún. 14. (Sze), 23.24
Lefutattam a következőt:

SHOW STATUS LIKE '%qcache%'
Qcache_free_blocks  	0
Qcache_free_memory 	0
Qcache_hits 	0
Qcache_inserts 	0
Qcache_lowmem_prunes 	0
Qcache_not_cached 	0
Qcache_queries_in_cache 	0
Qcache_total_blocks 	0
Ez azt jelenti, hogy nem tudok cachelni MySQL-ben? :( Vagy ez ettől független? 
SELECT SQL_CACHE id, name FROM customer;
SELECT SQL_NO_CACHE id, name FROM customer;
3

MySQL dokumentáció

Török Gábor · 2006. Jún. 15. (Cs), 14.15
Olvasd el a MySQL dokumentáció idevágó fejezetét Query Cache Configuration címmel.