marrtins Posted October 8, 2007 Report Posted October 8, 2007 Pēc manas pieredzas APC strādā daudz stabilāk par eaccelerator (lietoju vēl no Turck laikiem - pirms kāda gada pārgāju uz APC), kā arī eaccelerator baigi reti tiek izlaistas jauna versija. Man čota arī šķiet, ka kaut kas nav tīrs ar tiem testiem - serialize ātrāks nekā APC? :o
Roze Posted October 9, 2007 Report Posted October 9, 2007 Pēc manas pieredzas APC strādā daudz stabilāk par eaccelerator (lietoju vēl no Turck laikiem - pirms kāda gada pārgāju uz APC), kā arī eaccelerator baigi reti tiek izlaistas jauna versija. Ko nozīmē stabilāk? Ja produkts strādā normāli priekš kam izlaist jaunu versiju? Prieka pēc? :) APC reāli manuprāt lietojams palika tikai vai nu no 5.0.x vai pat 5.1.x versijas. Iepriekš varēja tikai problēmas rasties (īpaši brīžos kad uz webservera tika mainīti faili). Ņem vērā arī: http://pecl.php.net/bugs/bug.php?id=11988
marrtins Posted October 9, 2007 Report Posted October 9, 2007 Tas nozīmē, ka ar Turck bija neprātīgie apache segfaulti, kas turpinājās eaccelerator sākuma versijās (par pēdējām nezinu - kā jau teicu, tagat lietoju APC) Tiesa par tām PHP versijām - uz 4.x.x APC gļukoja uz vella paraušanu, bet tākā nu jau sen sēžu uz PHP5 - nekādu (redzamu/jūtamu) problēmu nav bijis.
marrtins Posted October 9, 2007 Report Posted October 9, 2007 P.S. CGI/FastCGI man nav aktuāli (vismaz pagaidām)
Vebers Posted October 10, 2007 Author Report Posted October 10, 2007 Š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). Mēķis testējot to bija, uzzināt laiku kā tas viss izpildas kopā.. Lūks kodi gan FS testam gan APC testam, varbūt patestējiet paši un padalieties ar rezultātiem ;) FS: http://paste.php.lv/6222 APC: http://paste.php.lv/6223
Roze Posted October 10, 2007 Report Posted October 10, 2007 Mēķis testējot to bija, uzzināt laiku kā tas viss izpildas kopā.. Jā nu mērķi jau nevar vainot, bet tad nevar uzstādīt, ka šis ir kāda konkrētu risinājumu benchmarks.. tik pat labi tad varētu ielikt: <? sleep(random(10,100)); // sheit kaut ko saakam benchot ?> un teikt ka konkrētais pļurzulis galīgi nerullē.. Proti lai kaut ko mērītu precīzi ir jāizolē pārējie ietekmējošie faktori, jo tikpat labi tev bottlenecks ir DB i/o (diski) nevis teiksim APC storage ;) ie kam benchmarks jaizpilda atkārtoti (jāveido cikls / jaiztīra keshi), jo izpildot to 1x nekādus ticamus rezultātus nevar iegūt. Tas nozīmē, ka ar Turck bija neprātīgie apache segfaulti, kas turpinājās eaccelerator sākuma versijāsNekas tāds nav piedzīvots.. sāku jūzot MMCache jau hvz kad (bija krietna labāka alternatīva kā Zend Optimizeris/Suite vai Ioncube cacheris). Varbūt vaina bija citur? :) Jo vieņīgā ķeska bija ar 64bit OS parādīšanos.. bet tur tikpat liela problēma ir/bija arī pašam php.
Vebers Posted October 10, 2007 Author Report Posted October 10, 2007 Ok, vainīgs - vaidzēja izteikties skaidrāk. ie kam benchmarks jaizpilda atkārtoti (jāveido cikls / jaiztīra keshi), jo izpildot to 1x nekādus ticamus rezultātus nevar iegūt. Neesmu teicis, ka pildīju to tikai vienu reizi, tas ir tikai loģiski to darīt vairākas reizes :)
Recommended Posts