[PHP & MySQL] Queries cachen met Memcache

[Trucker Her]

Ik heb geprobeert om MySQL queries te cachen op onze server met behulp van Memcache. Ik weet niet of er hier iemand is die me ermee kan helpen, maar dit is mijn test-code:

PHP:

<?php

$cache = new Memcache;
$cache->connect('localhost', 11221);
$version = $cache->getVersion();
echo "Server's version: ".$version."<br/>\n";
$Start = getTime(); 

if (!($ret = $cache->get('helloow'))){
    $cache->set('helloow',"hai.", 0 , 20);
    echo "It's set now";
}
else
{
    echo $ret;
}
$End = getTime(); 
echo "<br />Time taken = ".($End - $Start)." secs <br />"; 

echo "<br /><br />";
function getTime()
{
    list($usec, $sec) = explode(" ", microtime());
    return ((float)$usec + (float)$sec);
}   
// Database gegevens stonden hier.
mysql_connect( $DB_HOST, $DB_USER, $DB_PASS);
mysql_select_db($DB_NAME);
$Start = getTime(); 

$sql = "SELECT COUNT(*) AS `lol` FROM `advertisements`";
$res = mysql_query($sql) or die(mysql_error());
$cache->set('koekje', serialize($res), 0, 180);
$result = mysql_fetch_array($res);
echo print_r($result, true);
$End = getTime(); 
echo "Time taken = ".($End - $Start)." secs <br />Query"; 

//$result = mysql_fetch_array(unserialize($cache->get('koekje'))) or die (mysql_error());
var_dump(unserialize($cache->get('koekje')));

$End = getTime(); 
echo "Time taken = ".($End - $Start)." secs <br />Cache";

Het bovenste gedeelte van de code is wel werkend; deze zet hem in de cache, en haalt 'm eruit "helloow".
Alleen de mysql code niet; als ik hierop weer een fetch probeer uit te voeren (het gedeelte dat uit de cache komt) krijg ik een error; terwijl als ik deze rechtstreeks probeer te echoën ik deze fout krijg: Resource id #5
Iemand ideeën/suggesties?
'k Weet niet of dit een makkelijke of moeilijke is, ik kom er iniedergeval niet uit, en kan hierover eigenlijk ook niks vinden.
En dit betreft een testcode! Als dit werkende is word het op de site verwerkt; vandaar de rommeligheid van de code.

Bij voorbaat dikke dank!

[MueR]

PHP hoort in Programming.

Je kan een query resource niet cachen, net zo min als dat je een file pointer kan cachen. Caches zijn voor data (arrays, objects en die meuk).

[Y0ur1]

Ehm ben je nu niet iets aan het bouwen wat er al is?

[Manuel]

Waarom cache je niet de array die je van mysql_fetch_array terugkrijgt? En je maakt trouwens gebruik van de oude Memcache-wrapper, je kunt beter Memcached gebruiken. Zie ook: Using Memcache vs Memcached with PHP - Stack Overflow.

Zie ook: PHP: Memcached::set - Manual

[Cartman!]

Wat MueR zegt dus, een resource is alleen een pointer naar iets in je database-verbinding, zelf bevat het geen data. Je moet dus bijv. de output van fetch_assoc zelf cachen en dan werkt t prima. Kijk ook eens naar de handleiding van microtime, als je daar een paramter aan meegeeft doet ie direct wat jij ook doet in het getTime() maar dan zonder overbodige dingen

[Trucker Her]

Zoals gezegd 't is maar een testcode. Maar bedankt! Hier kan ik wat mee!

Ik probeer dit dus te cachen ivm de traagheid van de website; ik vermoed dat dit komt door de vele sql queries die worden uitgevoerd; maar als jullie kijken naar de pagina, wat vermoeden jullie dan? *snip*

[ Voor 62% gewijzigd door Creepy op 14-07-2011 14:20 . Reden: ontspammed ]

[Cartman!]

Hoe kunnen wij nou zien hoe jouw site in elkaar steekt als je een linkje plaatst? Ik zou eerst eens onderzoeken welk onderdeel de traagheid veroorzaakt en dan kun je dat gaan optimaliseren. Ik zie wel vieze Google Ads door je hele menu heen

[Y0ur1]

@Trucker Her: je realiseert je dat dit al standaard in MySQL zit? De vraag is alleen of het aanstaat en of het goed getuned is.
Zou je dit niet wat breder onderzoeken ipv deze overbodige hackish code te maken omdat je "vermoed dat het door de vele sql queries komt"? Wat zegt b.v. de MySQL slow query log?

[Gomez12]

Trucker Her schreef op donderdag 14 juli 2011 @ 13:30:
Ik probeer dit dus te cachen ivm de traagheid van de website; ik vermoed dat dit komt door de vele sql queries die worden uitgevoerd; maar als jullie kijken naar de pagina, wat vermoeden jullie dan? *snip*

Simpele suggestie : Verminder het aantal sql queries...
of benchmark de boel zodat je wel weet waar het probleem inzit ipv te vermoeden

[Verwijderd]

Je kan ook pagina's cachen met je applicatie of varnish ervoor zetten. Met varnish kan je met ESI ook delen van de pagina minder of juist langer cachen.

Met firebug en dan "net" tabje, op google speedtest of op pingdom kan je laadtijd van je pagina laten testen.

[kokx]

Ik krijg hier heel erg het gevoel bij dat je aan het optimaliseren slaagt zonder eerst te kijken waar het probleem ligt. Dat is eigenlijk erg slecht, aangezien je het misschien zelfs iets wat al erg snel is, langzamer gaat maken.

Veel beter is om eerst eens te kijken waar daadwerkelijk het probleem ligt. In php kun je dit doen door de XDebug extensie te installeren. Hierin zit een profiler ingebouwd. In combinatie met WinCacheGrind (als je op windows zit), of KCacheGrind (voor linux gebruikers - is een KDE programma), kun je dan precies zien wat er nu veel tijd kost op een pagina, en bezig gaan om dat te verkorten.

Iets wat je bijvoorbeeld wel altijd kan doen (en iets wat op productie servers eigenlijk zoiezo altijd aan zou moeten staan), is de APC extensie aanzetten in PHP. Dit cached de opcode van PHP, zodat de source code niet telkens volledig geparsed moet worden, dit scheelt vaak al redelijk wat.

[RobIII]

kokx schreef op vrijdag 15 juli 2011 @ 03:46:


Iets wat je bijvoorbeeld wel altijd kan doen (en iets wat op productie servers eigenlijk zoiezo altijd aan zou moeten staan), is de APC extensie aanzetten in PHP. Dit cached de opcode van PHP, zodat de source code niet telkens volledig geparsed moet worden, dit scheelt vaak al redelijk wat.

Meten == weten, da's een ding dat zeker is. Maar op een pagina die enkele seconden nodig heeft om uitgespuugd te worden gaan parsetijden van enkelen duizensten/honderdsten van secondes niet schelen. APC is leuk maar geen wondermiddel; daar moet TS zich wel van bewust zijn. Dus: eerst meten, dan nog eens meten en dan zagen

[Keiichi]

Is het niet een idee dat je mysql resultaten omzet naar een array/hash van objecten (mysql_fetch_object) en die in je memcache zet?

[Y0ur1]

RobIII schreef op vrijdag 15 juli 2011 @ 08:24:
[...]

Meten == weten, da's een ding dat zeker is. Maar op een pagina die enkele seconden nodig heeft om uitgespuugd te worden gaan parsetijden van enkelen duizensten/honderdsten van secondes niet schelen. APC is leuk maar geen wondermiddel; daar moet TS zich wel van bewust zijn. Dus: eerst meten, dan nog eens meten en dan zagen

Vooral als je een framework met veel classes gebruikt (Zend, Symfony..) heeft APC echt zin

@Keiichi: waarom? MySQL query cache bestaat al, waarom zou je dan het wiel opnieuw uitvinden? Wat de MySQL query cache doet is het hashen van een SELECT query en kijken of daar een bijbehorend non-stale result bij past, zo ja dan krijg je deze terug uit memory.

[Keiichi]

Y0ur1 schreef op vrijdag 15 juli 2011 @ 11:23:
[...]
@Keiichi: waarom? MySQL query cache bestaat al, waarom zou je dan het wiel opnieuw uitvinden? Wat de MySQL query cache doet is het hashen van een SELECT query en kijken of daar een bijbehorend non-stale result bij past, zo ja dan krijg je deze terug uit memory.

Ik heb gisteren een interresant gesprek gehad met iemand over het waarom van sommige dingen.

Een rede voor een dergelijke constructie kan zijn om het net wat efficienter te maken. Stel dat je een tabel hebt met gegevens die je veelvuldig moet raadplegen. Dan kan het lonen door de stappen van het maken van een connectie, het sturen van een query, het laten uitzoeken door de mysql server en het laten returnen van het resultaat, er tussenuit te halen om het net wat efficienter te maken.

Voor een gemiddelde huis-tuin-en-keuken site niet zo interresant, maar voor grote sites kan het verschil genoeg beteken om zo'n constructie lonend te maken.

[Y0ur1]

Keiichi schreef op vrijdag 15 juli 2011 @ 11:43:
[...]


Ik heb gisteren een interresant gesprek gehad met iemand over het waarom van sommige dingen.

Een rede voor een dergelijke constructie kan zijn om het net wat efficienter te maken. Stel dat je een tabel hebt met gegevens die je veelvuldig moet raadplegen. Dan kan het lonen door de stappen van het maken van een connectie, het sturen van een query, het laten uitzoeken door de mysql server en het laten returnen van het resultaat, er tussenuit te halen om het net wat efficienter te maken.

Voor een gemiddelde huis-tuin-en-keuken site niet zo interresant, maar voor grote sites kan het verschil genoeg beteken om zo'n constructie lonend te maken.

Dat is inderdaad nog een verschil, alleen denk dat dit niet de oplossing voor het probleem van de TS is, tenzij het een high-traffic site is. Ik zou eerder naar (partial) output caching kijken, dan hoef je veel minder data te cachen.

[kokx]

RobIII schreef op vrijdag 15 juli 2011 @ 08:24:
[...]

Meten == weten, da's een ding dat zeker is. Maar op een pagina die enkele seconden nodig heeft om uitgespuugd te worden gaan parsetijden van enkelen duizensten/honderdsten van secondes niet schelen. APC is leuk maar geen wondermiddel; daar moet TS zich wel van bewust zijn. Dus: eerst meten, dan nog eens meten en dan zagen

APC kan nooit kwaad om aan te zetten, en is eigenlijk een no-brainer om standaard te draaien op productieservers tegenwoordig. Ook al scheelt het maar die enkele miliseconden, het scheelt toch weer iets. Niet dat ik nu micro-optimalisaties wil aanprijzen, maar APC is 1 van de dingen die geen enkele moeite is om aan te zetten. En zeker op het moment dat je erg veel includes bij een request (bijvoorbeeld bij het gebruik van een framework) kan dit gigantisch veel schelen.

Keiichi schreef op vrijdag 15 juli 2011 @ 11:43:
[...]


Ik heb gisteren een interresant gesprek gehad met iemand over het waarom van sommige dingen.

Een rede voor een dergelijke constructie kan zijn om het net wat efficienter te maken. Stel dat je een tabel hebt met gegevens die je veelvuldig moet raadplegen. Dan kan het lonen door de stappen van het maken van een connectie, het sturen van een query, het laten uitzoeken door de mysql server en het laten returnen van het resultaat, er tussenuit te halen om het net wat efficienter te maken.

Voor een gemiddelde huis-tuin-en-keuken site niet zo interresant, maar voor grote sites kan het verschil genoeg beteken om zo'n constructie lonend te maken.

Dit kan misschien inderdaad net helpen, echter, het zou misschien ook wat anders kunnen zijn dat het probleem veroorzaakt. En dat zou betekenen dat je veel energie gaat steken in het cachen van iets wat toch al erg snel opgehaald word. Daarom kan je beter eerst gaan meten wat er zo langzaam is, en dat stukje code gaan versnellen.

[Keiichi]

kokx schreef op vrijdag 15 juli 2011 @ 15:18:
Dit kan misschien inderdaad net helpen, echter, het zou misschien ook wat anders kunnen zijn dat het probleem veroorzaakt. En dat zou betekenen dat je veel energie gaat steken in het cachen van iets wat toch al erg snel opgehaald word. Daarom kan je beter eerst gaan meten wat er zo langzaam is, en dat stukje code gaan versnellen.

Eens dat een goed ontwerp van een applicatie in eerste instantie al goed in elkaar moet steken. Hoe ik memcache eigenlijk zie is dat het een tool is om dingen nog net wat sneller te kunnen laten werken.