Vebers Posted October 3, 2007 Report Share Posted October 3, 2007 (edited) Ir nepieciešamība kešot masīvus, kas satur no datubāzes izvilktus datus. Pašlaik tas tiek darīts ar serialize un dati tiek ierakstīti failā uz cietņa. Bet ir nepieciešamība šo cache sistēmu uzlabot, lai tā darbotos maksimāli ātri. Varbūt varat padalīties pieredzē kā ir ar MySQL Query Cache, memcached, ramdisk, vēl kādiem citiem variantiem. Kurš nu ir tas labākais un kādā gadījumā tas tieši ir labākais. P.S. kas būtu ātrāk, ja šos datus glabā uz cietņa (kā agrāk tika aprakstīts) vai arī MySQL heap tabulās ? Edited October 3, 2007 by MakaTaNaw Link to comment Share on other sites More sharing options...
Delfins Posted October 3, 2007 Report Share Posted October 3, 2007 Visātrākais ir RAM-kešs. Tur citu variantu nav. Basta! Bet palīdz arī sistēmas pārprojektēšana. Iespējams sistēma sūdīgi uzprojektēta nu un tagad mēģina `savilkt galus`. Link to comment Share on other sites More sharing options...
marrtins Posted October 4, 2007 Report Share Posted October 4, 2007 Memcache izmantot ir vērts, ja ir daudzi serveri, kam jākešo vieni dati - visi slēdzas pie memcached un ņemās. Serialize un faili - ļoti slikti (serialize/unserialize relatīvi LĒNS pasākums), kaut arī uz ramdiska, jo jāseko līdzi vai divi procesi nesāk rakstīt failā. Ja to var izkontrolēt - var mēģināt. MySQL heap - arī ideāls variants, lai glabātu kādus rezultātus savilktus kopā no citām tabulām. Šajā gadījumā ideāls variants man izskatās APC (http://www.php.net/apc) - izveidojam PHP masīvu un kašā iekšā - un nolasas arī kā jau PHP masīvu bez jebkādiem overhead kā būtu ar serialize. Link to comment Share on other sites More sharing options...
Kristabs Posted October 5, 2007 Report Share Posted October 5, 2007 Ou, tas APC izskatās diezgan labi. Ir kādam pieredze jau? Pozitīva? Negatīva? Link to comment Share on other sites More sharing options...
Vebers Posted October 5, 2007 Author Report Share Posted October 5, 2007 (edited) Notestēju to APC. Rezultāti ? Negatīvi! Tests: no DB tika izvilkti ārā 3500 ieraksti un saglabāti masīvā, ja no apc izdodas izvilkt datus, tad tie tiek ielādēti no apc, bet ja ne, tad tiek izpildīts standarta SQL un visi dati ielikti masīvā un masīvs saglabāts APC. APC: Bez APC 0.022 sec; Ar APC (no cache): 0.28 sec; Ar APC (store): 0.41 sec; Memcache: Bez Memcache 0.022 sec; Ar Memcache(cache): 0.23sec; Ar Memcache(set): 0.40sec; Ramdisk: Serialize / unserialize variants: bez cache: 0.022 sec; no Db, ierakstīšana failā: 0.37 sec; no diska faila (cache content): 0.0088 sec; Parasta FileSystem: bez cache: 0.022 sec; no Db, ierakstīšana failā: 0.38 sec; no diska faila (cache content): 0.0084 sec; Un vai tad nav taa ka irksh RAM ir jaieraksta un janolasa daudz, daudz ātrāk nekā uz hdd ? So, kur ir taisnība ? Šķiet ka atbilde ir skaidra :) Edited October 8, 2007 by MakaTaNaw Link to comment Share on other sites More sharing options...
Roze Posted October 6, 2007 Report Share Posted October 6, 2007 Notestēju to APC. Rezultāti ? Negatīvi! Kaut kā izskatās neriktīgi tie tavi rezultāti.. Vari aprakstīt testa metodes vai iedot testa skriptu? Jo Memcache->get() principā nekad nevaidzētu pārsniegt 0.00x .. Jeb tie tev ir kādi 1000 geti? Loģiski vajadzētu būt ka lokālā APC storage ir visātrākā uz shared atmiņu.. (jāņem vērā ka ja testējot ar mazu konkurenci arī risinājums uz failiem varētu būt ātrs jo linux gadijumā faktiski konkrētie faili anyway būs ramā (pat speciāli neliekot uz ramdiska)). APC ar Memcachi īsti nevar salīdzināt, jo tie ir diezgan dažādi produkti kurus izmanto atšķirīgās situācijās. Otrs - nekad nevajag storēt 3500 ierakstus vienā variablī / vienā masīvā.. Sadali keshojamies objektus katru savā un izpildi multiget ar tiem elementiem kuri nepieciešami. Serialize un faili - ļoti slikti (serialize/unserialize relatīvi LĒNS pasākums), Arī Memcache variantā dati tiek serializēti.. Drīzāk par pamatu var ņemt šos testus http://www.mysqlperformanceblog.com/2006/0...nce-comparison/ protams nav ļoti svaigi un pa šo laiku testējamie produktiem ir jau citas/jaunākas versijas, tad vietu sadalijums pēc ātrdarbības varētu būt identisks.. Ņemt verā arī komentārus pie katra no testējamajiem variantiem. Link to comment Share on other sites More sharing options...
Vebers Posted October 8, 2007 Author Report Share Posted October 8, 2007 Skripts - http://paste.php.lv/6208 Otrs - nekad nevajag storēt 3500 ierakstus vienā variablī / vienā masīvā.. Sadali keshojamies objektus katru savā un izpildi multiget ar tiem elementiem kuri nepieciešami. Tie 3500 ieraksti bija lai pārbaudītu apc_store f-ju, jo pie 3500 ierakstiem to lielums bija nedaudz zem 1mb (rakstīts, ka var būt līdz 1mb). Link to comment Share on other sites More sharing options...
Delfins Posted October 8, 2007 Report Share Posted October 8, 2007 Tu nekorekti dabū izpildes laiku: Šitais būs 2x liekais darbs if(apc_fetch($key)) { $array = apc_fetch($key); Link to comment Share on other sites More sharing options...
Vebers Posted October 8, 2007 Author Report Share Posted October 8, 2007 (edited) Ok, tagad laiks nedaudz samazinājās uz: APC: Bez APC 0.022 sec; Ar APC (no cache): 0.0101 sec; Ar APC (store): 0.41 sec; Bet anyway FS ir ātrāks variants, pagaidām.. Edit: Memcache: Bez Memcache 0.022 sec; Ar Memcache(cache): 0.0095sec; Ar Memcache(set): 0.041sec; Edited October 8, 2007 by MakaTaNaw Link to comment Share on other sites More sharing options...
v3rb0 Posted October 8, 2007 Report Share Posted October 8, 2007 pamoci to testu ar ab, varbūt kaut kāda x pēc apc nebija "pamodies". Link to comment Share on other sites More sharing options...
Vebers Posted October 8, 2007 Author Report Share Posted October 8, 2007 (edited) Apache Benchmark testi: ./ab -n 10 -t 59 http://adrese apc Time per request:20.73 Complete requests: 2846 memcache Time per request:16.79 Complete requests: 3537 FS Time per request: 16.01 Complete requests: 3686 ramdisk Time per request:16.02 Complete requests: 3684 So, reāli atkal sanāk ka FS ir ātrākais variants! Edited October 8, 2007 by MakaTaNaw Link to comment Share on other sites More sharing options...
Roze Posted October 8, 2007 Report Share Posted October 8, 2007 Skripts - http://paste.php.lv/6208 Šis ir nepareizi.. Tu nedrīksti testos mērīt / lietot citas lietas.. proti mysql_* te nedrīkst būt! Lai arī varbūt izpildās ātri tas NEBŪS apc_store vai memcache_set laiks bet gan laiks kur dati nāks no MySQL servera un tad setosies. Aiz kam MySQL var ieķerties (cache cleaning / citas lietas utt utt). Tāpat īsti korekti nav lietot http/webserveri šādam benchmarkam, lai arī protams reālās dzīves gadijumos http tur būs. Iesaku patestēt nevis ar -n 10 ... bet gan ar -n 10000 un lielāku concurency (nevis noklusēti ar 1) -c 10 -c 100 -c 1000 Iesākumā: ./ab -n 10000 -c 100 http://adrese Un iesaku testiem un realitātē izmantot mazākus masīvus/objektus nekā 1Mb.. MC gadijumā tas stipri iespaido ātrdarbību, proti pie katra requesta sanāk lasīt 1Mb caur tīklu. Pēc pieredzes sanāca ķēpa kad programmētājs bija tieši šādi izdomājis ka var glabāt lielāku objektu uz Memcache un sanāca utilizēt gandrīz 1 gigabitu kad sāka gļukot tīkla interfeiss :) Tas izskatijās apmēram šādi (mērvienības MBps - megabaiti sekundē) http://roze.lv/traffic.gif Link to comment Share on other sites More sharing options...
Delfins Posted October 8, 2007 Report Share Posted October 8, 2007 Es parasti dodos no otrās puses... vai tiešām vajag glabāt visu tabulu atmiņā!? Tobiš atkārtoties!? - tabula jau ir iekš DB. Kāda ir darba specifika !? Kā ar datu integritāti !? (vai kešā == DB?) Varbūt tur saģenerēt jau gatavus HTML-us !?... Nu ar citu pieeju.. padomā.. Link to comment Share on other sites More sharing options...
Vebers Posted October 8, 2007 Author Report Share Posted October 8, 2007 Ok, pie daudz mazākiek datu apjomiem APC ieliek kloķi gan FS, gan memcache. Delfins, netiek glabāta visa tabula atmiņā, tiek glabāti tikai viens lauks no DB. pieprasijums uz DB ir apmeram tads - select properties from tabula where id = 1245. Sistema ir CMS, ja kas.. katru reizi kad tiek pieprasits kads ID vispirms skataas cache, ja termiņš nav izteceejis, tad dati tiek izvilkti no cache nevis SQL (ja SQL, tad tiek tiek serializeeti, ierakstiiti failaa un saglabati). shaadi pieprasiijumi ir salidzinoši daudz. Tada jau tiek izmantota esošā sistēma - mans uzdevums to optimizēt lai lapa ģenerējas maximāli ātri. Ja dati tiek vilkti no SQL, tad lapa uzģenerējas 4.6sec, bet ja no cache 0.56 Pie daudz apmeklētājiem lapa velkas. Cache dati pārģenerējas reizi 3 min Par gataviem HTML bija pirmais ko iedomajos, bet tur ir regjistreeto lietotaaju zona un daudz citas dinamiskas lietas, līdz ar to šis variants neies cauri :( Link to comment Share on other sites More sharing options...
Delfins Posted October 8, 2007 Report Share Posted October 8, 2007 a nafig tu serializē!? > save php-code cache > include 'cache.....php' Resp. iekš keš faila tev būs <?php $whatever->properties = Array(...); ?> Link to comment Share on other sites More sharing options...
Recommended Posts