[PHP] - Optimalisatie van PHP code

[gvanh]

Laatste tijd heb ik mij vooral op optimalisatie van websites gestort met betrekking tot MySQL-queries. Daar heb ik veel tijdwinst mee gehaald, da's dus prettig.

Inmiddels ben ik de boel van de andere kant aan het bekijken en ben ik mijn CMS aan het optimaliseren van de kant van de PHP code. Ik gebruik nu apache's ab2 tool om statistieken te bekijken en te bezien in hoeverre een optimalisatie zin heeft gehad.

Nu vind ik het alleen moeilijk inschatten in hoeverre mijn systeem voldoet aan redelijke verwachtingen. Ik zit nu voor 1000 requests (30 concurring requests) op 9.15 requests per seconde. Dat lijkt mij nog niet heel snel ... maar ik kan het niet heel goed inschatten.

Overigens ben ik er inmiddels ook achter, dat het grootste deel van de execution time gaat zitten in het laden van alle onderdelen van het systeem (de include file, zeg maar). Het uiteindelijke gebruik van de classes en objecten neemt een veel kleiner aandeel in beslag. Om die reden ben ik ook al overgestapt op een andere DB abstration layer (van adodb naar adodb_lite).

De vraag is nu of je iets kunt zeggen over redelijke waardes voor het aantal requests dat per seconde afgewerkt moet kunnen worden om spits-uur op een site enigszins te kunnen overleven en of je nog andere tips hebt met betrekking tot optimalisatie aan de kant van de PHP-code.

Template engine is overigens van eigen makelijk en neemt een mini-deel van de execution-time voor z'n rekening. Overstappen naar een andere template engine is dus ongewenst. Het gaat meer om optimalisatie op interessante vlakken die ikzelf wellicht niet zo snel zou bedenken.

Alvast veel dank voor het meedenken!

[Daspeed]

(output) caching?

[GlowMouse]

9.15/s is niet zoveel, maar het hangt natuurlijk van het aantal bezoekers af of het de moeite waard is om dit te optimaliseren.
Hoeveel kB aan PHP-files heb je trouwens, dat het laden ervan zoveel tijd bestrijkt?

[gvanh]

- Output caching is (helaas) geen optie omdat iedere bezoeker potentieel een unieke gebruiker met een unieke rol en dus unieke rechten heeft. Je zou dan dus voor iedere gebruiker zijn eigen html-cache-bestanden moeten maken. Een systeem voor SQL-caching is er al en heeft in dit geval geen zin omdat het alleen maar extra overhead geeft (heb ik getest).

- De website bevat een inschrijvingsprocedure waar op gezette tijden inschrijvingen worden geaccepteerd. Vantevoren worden die tijden aangegeven en op die tijden is de site mega-druk. Vandaar de hang naar optimalisatie.

- Het is niet helemaal direct in te schatten hoeveel kB php-files er geladen wordt omdat er een hoop dynamisch wordt geladen op het moment dat het nodig is (op vrijwel geen enkel moment wordt AL het mogelijke geladen) Maar dat is het hem ook een beetje ... volgens mij is het niet schrikbarend veel. Maar ik weet wel dat voor er nog maar echt iets uit de database gehaald is of geparsed wordt, het aantal requests/sec. op 15 staat. Dat is dus wanneer ik na includen van de main include file en het initialiseren van de belangrijkste (hoofd) modules een exit geef.

Natte-vinger-werkend zou ik zeggen dat de geladen .PHP files bij elkaar zo'n 400-500 kB beslaan.

[ Voor 5% gewijzigd door gvanh op 22-01-2008 21:59 ]

[mithras]

Ik vind 400-500KB toch nog best wat veel, maar blijf daar niet alleen op focussen.

Je kan met een aantal php benchmark functies prima laten zien waar er dingen mis gaan. Met memory_get_usage() krijg je het huidige geheugengebruik terug
Kijk verder nog naar grote for(each) of while loops. Bij grote bestanden en vele (her)calculaties is dat ook een belangrijke factor.
Tot slot moet je toch kijken naar je SQL executie tijd. Hoeveel tijd kost dat? Haal je bijvoorbeeld de groepen van gebruikers op en ga je met php de boom opbouwen (een veel gebruikte optie), dan kost je dat veel overhead. Kijk dan eens naar een MPTT oplossing, dat zou al grote stukken moeten helpen.

[orf]

__autoload gebruik je al begrijp ik?
Daarnaaste kun je kijken naar compilatie: Zend / ionCube.

[Megamind]

Je kan ook eens kijken aar phpaccelerator of eaccelerator. Die hebben voor mij de load een laadtijd sterk verbeterd.

[ Voor 24% gewijzigd door Megamind op 22-01-2008 23:43 ]

[flowerp]

gvanh schreef op dinsdag 22 januari 2008 @ 21:58:
- De website bevat een inschrijvingsprocedure waar op gezette tijden inschrijvingen worden geaccepteerd. Vantevoren worden die tijden aangegeven en op die tijden is de site mega-druk. Vandaar de hang naar optimalisatie.

Zomaar in het wilde weg wat gaan optimaliseren helpt zelden, of het moeten echt hele obvious dingen zijn.

Het beste is om gewoon de code te profilen. De profiler geeft je dan een break-down over je gehele executie path (voor b.v. 1 request) en vertelt in welke gedeeltes het meeste CPU en/of geheugen verbruik gaat zitten. Die delen kun je dan gericht optimaliseren.

[FragFrog]

In mijn ervaring is toch vaak 60% ~ 70% van executiontime kwijt aan SQL meuk waar goed op te bezuinigen valt. Een erg mooie oplossing daarvoor is memcache, heb er laatst nog wat over geschreven en ook al eens ter sprake gebracht in een ander topic hier, voor een bepaalde site scheelt het makkelijk de helft aan execution time

Een ander grappig struikelblok: veel content werd dynamisch geladen, en dan is het niet alleen de site die lang duurt maar ook alle plaatjes, CSS dingen, etc, tot we die zo herschreven hadden dat ze direct van de fileserver kwamen. Aardig leuke snelheidswinst die je dan ineens ziet

Wat hierboven trouwens gezegd werd: __autoload is een held. 500kb is een aardige lap code om te laden (en compilen, alhoewel je daar caching engines voor kan kopen), minimaliseren daarvan zal ongetwijfeld veel schelen. Gerelateerd: abstract werken. Collega's van me willen het nog wel eens presteren classes van 500, 600 regels te schrijven, als ik eenmaal uitgehuild ben en niet zelden klaar ben met herschrijven en je een serie losse classes overhoudt van 40, 50 regels per stuk max waarvan maar een enkele geladen hoeft te worden scheelt dat ook aardig - zeker als je het overal consistent doet

[Voutloos]

Flowerp heeft het beste, meest complete en altijd juiste antwoord gegeven: meten is weten. Je kan wel heel lang kletsen over een micro-optimalisatie als single quotes om strings ipv dubbele, maar als dat maar bij een handjevol echo statements gebeurd, valt dat in het niet bij wat echt kan uitmaken, zoals bijvoorbeeld de body van een loop welke heel vaak geitereerd wordt. Of zoals vaak gezegd: de 20% van je code waar 80% van de executietijd in gaat zitten (afhankelijk van welke guru aan het woord is kan dat ook 10/90 zijn ).

Sql queries zijn ook vaak genoeg de boosdoener, maar die moet je ook gewoon eerst middels explain (of query analyzer etc.) analyseren. Het explainen van queries valt ook meer onder profiling dan 'natte vinger werk'.

[gvanh]

Dank voor alle antwoorden en tips tot zover.

MySQL heb ik al geoptimaliseerd voor zover ik mijn vermogen ligt. Ik heb een paar weken terug een logging functie gemaakt, die op een aantal punten in de code aangeeft hoeveel de total executie-tijd tot dat punt is geweest. Bovendien schrijft hij in het logbestand weg hoeveel iedere MySQL query die gedaan wordt aan tijd in beslag genomen heeft. Door vervolgens alle MySQL queries te optimaliseren heb ik daar al heel veel tijdwinst mee geboekt.

Met betrekking tot pre-compilation: ik gebruik ionCube voor het coderen van de meeste PHP, maar volgens mij is er niet veel verschil in laadtijd tussen de wel en niet gecompileerde versie. Voor zover ik begreep is ionCube ook alleen een compiler en niet een optimizer. Maar van de gratis encoder van ionCube (PHP Encoder) lijkt de ontwikkeling te zijn gestopt. Het laatste nieuwsbericht over ondersteuning voor PHP 4.4 is van juli 2005. eAccelerator heb ik gisteren geprobeerd te installeren op mijn Linuxbox, maar dat is niet gelukt, bij compilen kreeg ik allemaal vreemd foutmeldingen waar ik geen oplossing voor het kunnen vinden. Misschien dat de Zend optimizer wel te installeren is, ik zal daar eens naar kijken.

Wat overigens wellicht nog even te noemen valt, dat zijn de laadtijden de ik uit het LOG bestand haal. Wanneer ik de tijden voor de MySQL queries bekijk tijdens de AB2 stresstest, dan lopen de executie-tijden per query ook enorm op, ongeveer x 10. Is dat normaal omdat de totale server zwaarder wordt belast? Of betekent dat toch nog dat de queries te zwaar zijn?

[LuCarD]

flowerp schreef op woensdag 23 januari 2008 @ 00:13:
[...]


Zomaar in het wilde weg wat gaan optimaliseren helpt zelden, of het moeten echt hele obvious dingen zijn.

Het beste is om gewoon de code te profilen. De profiler geeft je dan een break-down over je gehele executie path (voor b.v. 1 request) en vertelt in welke gedeeltes het meeste CPU en/of geheugen verbruik gaat zitten. Die delen kun je dan gericht optimaliseren.

100% mee eens....

Je kan een trail downloaden van Zend Platform, daar kan je perfect mee meten waar je de bottleneck zit. Je kan ook trage queries mee vinden, onnodige executies en dergelijke.

Verder kijk hier eens voor diverse preformance tips:
http://www.scribd.com/doc/351490/PHP-and-Performance

[Bluestorm]

Bij ons heeft installatie van APC iig goed geholpen om de tijd die gespendeerd werd in de includes van veel code te verminderen. (Ik zelf gebruik momenteel APD voor de profiling)

Zorg wel dat je realistische data in je DB hebt zitten tijdens het benchmarken. Er zijn veel SQL queries die opeens veel trager worden met veel data.

[Verwijderd]

Ik moet je toch aanraden om eens te kijken naar een template systeem als smarty. Smarty komt met een ingebouwde cache compiler.

Ik neem aan dat je btw dit niet aan het benchen bent op een pentium 1?

[RAJH]

LuCarD schreef op woensdag 23 januari 2008 @ 10:20:
[...]

100% mee eens....

Je kan een trail downloaden van Zend Platform, daar kan je perfect mee meten waar je de bottleneck zit. Je kan ook trage queries mee vinden, onnodige executies en dergelijke.

Verder kijk hier eens voor diverse preformance tips:
http://www.scribd.com/doc/351490/PHP-and-Performance

Waarom een trail downloaden terwijl je met Xdebug in combinatie met wincachegrind het zelfde kan?

[Voutloos]

j.ostie, zonder goede profiling in 1x de hele templating omgooien is geen goed plan. Ten tweede maakt het niet eens zo heel veel uit als het een P1 is, want je wil het relatief zwaarste deel aanpakken.

[LuCarD]

RAJH schreef op woensdag 23 januari 2008 @ 14:08:
[...]


Waarom een trail downloaden terwijl je met Xdebug in combinatie met wincachegrind het zelfde kan?

De complete interface die er bij krijgt is gewoon geil

En voor developers is hij ook gratis te krijgen

Al hoewel die wincachgrind er wel goed uit ziet...

[ Voor 6% gewijzigd door LuCarD op 23-01-2008 14:16 ]

[AtleX]

* AtleX wijst eens subtiel naar zijn tweakblog.

In principe kan je er vanuit gaan dat je DB related code (queries, verbinding maken, etc.) het traagste is, tenzij je heel gekke PHP constructies gebruikt. Disk I/O is natuurlijk ook traag, maar als je zeg maar 100 losse files die elke request geladen worden samenvoegt tot 1 groot bestand heb je dat probleem al aardig getackeld. Ook doet een beetje server OS (zoals Linux) gewoon aan disk caching, waardoor disk I/O voor 90% van de sites gewoon nooit een probleem is.

Ik weet niet precies wat voor load je hebt of verwacht voor die site? Meet trouwens ook niet alleen met AB, maar zoek een profiler of maak zelf een eenvoudige. Dan kan je stukken code meten qua execution time en memory usage, dat levert vaak nuttiger informatie op dan de informatie die AB geeft.

Houd ook in je achterhoofd dat hardware goedkoper kan zijn dan devtijd. Als jij 3 dagen bezig bent voor 5% performance winst ben je niet zo slim bezig. Dan kan je voor dat geld beter een snellere CPU en meer geheugen kopen.

[ Voor 11% gewijzigd door AtleX op 23-01-2008 14:17 ]

[gvanh]

Zojuist heb ik Zend Optimizer geinstalleerd op m'n test-server. Voor en na installatie heb ik weer de ab2 tool gerund om de performance te checken.

Na installatie van de Zend Optimizer is er geen enkel verschil in de performance. In de phpinfo() output staat de Zend Optimizer keurig genoemd, dus dat kan het probleem niet zijn.

Betekent dit dat de bottleneck niet bij de PHP zit? Of zijn hier uberhaupt geen conclusies uit te trekken?

Ik zal ook nog eens met profiling aan de slag gaan. In mijn IDE (phpEd) zit een profiler, alleen snap ik die niet ... volgens mij komt dat doordat mijn website gebruik maakt van ModRewrite, waardoor de scripts nooit helemaal gerund worden. Ik zal eens een van de gesuggereerde tools gebruiken.

[ Voor 25% gewijzigd door gvanh op 24-01-2008 09:33 ]

[SchizoDuckie]

Oke, dan zit de bottleneck dus waarschijnlijk nog in het laatste gedeelte van je database toegang/queries. Als de PHP processing time niet versneld kan worden dan kun je dat nog proberen te optimaliseren. Ik weet niet of je veel write operaties doet, maar ik heb gister toevallig iets geschreven wat heel simpel allerlei read operaties op de db kan cachen, voor unieke queries. Dat kan je er super simpel tusssen hangen en uitproberen:
Wat ik zelf heel lomp doe is zodra er een insert/edit/update/delete query komt de complete cache leeg pleuren, zo hoef je ook niet na te denken over welk deel van de cache het wel of niet doet

PHP:

<?

/** Universal cache class **
 * 
 * By SchizoDuckie 
 * Usage:
 * 
 * $hash = md5($somequeryyouwanttodo); (MD5, SHA1, or any hash function you want)
 * if(QueryCache::isCached($hash)) { return QueryCache::useCache($hash) 
 * 
 * after(youdidsomethinwith($somequeryyouwanttodo))
 * {
 *   QueryCache::cacheResult($result));
 * }    
 * 
 * If you get an update/delete query on the datbase just call QueryCache::emptyCache and everything will start over. 
 *
 */

class QueryCache
{

    public static function isCached($hash) 
    {
        $currentAge = time();
        $maxAge = time() - 3600;
        $filename  = './querycache/'.$hash.'.cache';
        if(file_exists($filename))
        {
            clearstatcache();
            $time = filemtime($filename);
            if($maxAge > $time) 
            {
                @unlink($filename); 
                return false;   
            }
            return true;
        }
    }

    public static function useCache($hash) 
    {
        return(unserialize(file_get_contents('./querycache/'.$hash.'.cache')));
    }


    public static function cacheResult($hash, $result) 
    {
        file_put_contents('./querycache/'.$hash.'.cache', serialize($result));
    }

    public static function emptyCache() 
    {
        $cachedfiles = glob('./querycache/*.*');
        foreach($cachedfiles as $file) @unlink($file);
    }

}

vergeet niet even een querycache mapje aan te maken en die te chmodden als 777755

[ Voor 7% gewijzigd door SchizoDuckie op 24-01-2008 10:51 ]

[AtleX]

Hoezo 777? Ga je ook executen vanuit die map? Read + write rechten lijkt me voldoende voor de www user, de owner houdt natuurlijk wel 7.

[gvanh]

Zoiets had ik zelf ook al gemaakt. Alleen maakt mijn query-cache gebruik van een database tabel. Idee is volgens mij hetzelfde. Query-cache heb ik net aangezet voor deze website, dat verbetert de performance iets, maar niet heel veel. (van 8,5 requests per seconde naar 10,08 requests per seconde). De queries zijn nu wel allemaal < 0,05 sec (in totaal ongeveer 10 per pagina).

Verder heb ik nog wat verschillende eikpunten in het script gezet, om te kijken waar de meeste execution time in gaat zitten. Dat levert de verrassing op dat tijdens de stress-test vooral de fase van file-inclusion, waarin dus hoofdbestanden worden geladen (en database-verbinding wordt gemaakt), enorm fluctueert. Ongeveer 9/10 keer wordt de fase in < 0,3s afgerond, maar in sommige gevallen duurt het ineens meer dan 5 seconde, tot soms wel 15/16/17 seconde.

Da's wel heel vreemd. Ik ga 'ns kijken of dat zit op het punt van het verbinden met de database ... misschien dat die een beperkt aantal connecties heeft of zo ...

[LuCarD]

SchizoDuckie schreef op donderdag 24 januari 2008 @ 09:55:
Oke, dan zit de bottleneck dus waarschijnlijk nog in het laatste gedeelte van je database toegang/queries. Als de PHP processing time niet versneld kan worden dan kun je dat nog proberen te optimaliseren. Ik weet niet of je veel write operaties doet, maar ik heb gister toevallig iets geschreven wat heel simpel allerlei read operaties op de db kan cachen, voor unieke queries. Dat kan je er super simpel tusssen hangen en uitproberen:
Wat ik zelf heel lomp doe is zodra er een insert/edit/update/delete query komt de complete cache leeg pleuren, zo hoef je ook niet na te denken over welk deel van de cache het wel of niet doet

<SNIP NETTE CODE>
vergeet niet even een querycache mapje aan te maken en die te chmodden als 777

Allemaal wel leuk en aardig, maar is de Query Cache van de database niet efficienter? Of gebruik je SQLLite of zo iets?

[ Voor 39% gewijzigd door LuCarD op 24-01-2008 10:30 ]

[SchizoDuckie]

AtleX schreef op donderdag 24 januari 2008 @ 10:10:
Hoezo 777? Ga je ook executen vanuit die map? Read + write rechten lijkt me voldoende voor de www user, de owner houdt natuurlijk wel 7.

eh daar heb je gelijk idd

LuCarD schreef op donderdag 24 januari 2008 @ 10:29:
[...]


Allemaal wel leuk en aardig, maar is de Query Cache van de database niet efficienter? Of gebruik je SQLLite of zo iets?

Nou, eigenlijk is dit zo universeel dat het niet uit maakt of je hier nou complete queries mee cached of al pre-filled O/R mapped objecten Waar ik het zelf dus gebruik is om de Find() functie van mn dbObject (zie sig) heen, op die manier hoeft ie niet eens de database aan te spreken, of überhaupt de verbinding te bezetten:

PHP: class.dbObject.php

/** Snip uit m'n dbObject class, de gepatchte find functie */

    public function Find($className, $filters=array(), $extra=array(), $justThese=array()) 
    {
        $originalClassName = ($className instanceof dbObject) ? get_class($className) : $className;
        $class = new $originalClassName();
        if($originalClassName != get_class($this) && $this->ID != false) {
            $filters["ID"] = $this->ID;
            $filters = array(get_class($this) => $filters); 
        }
        $hash = sha1(serialize(Array($originalClassName, $filters, $extra, $justThese)));
        // serialize de array van parameters, en hash die weer, en voila, daar is je unieke searchquery voor ie bij de SQL builder uitkomt.
        if(QueryCache::isCached($hash)) // als die hash dan al bestaat, deze gebruiken en returnen
        {
            return QueryCache::useCache($hash);
        }
        else
        {
            $builder = new QueryBuilder($originalClassName, $filters, $extra, $justThese);
            $input = dbConnection::getInstance()->fetchAll($builder->buildQuery(), 'mysql_fetch_assoc');
            $objects = dbObject::importArray($originalClassName, $input);
            // zodra dan de nieuwe data binnengehaald is, deze even cachen a.d.h.v. de hash die al bekend is.
            QueryCache::cacheResult($hash, $objects);
            return($objects);
        }
    }

Aan de hand van de sha1 hash over de searchquery weet hij dat hij exact diezelfde gegevens binnen gaat krijgen (let wel, ik clear de gehele cache bij een insert/edit/update/delete) Dit lapje code zorgt er bij mij bijvoorbeeld voor dat er op een bepaalde site in nog maar 6 plaats van 58 queries uitgevoerd worden, en de parseexecutiontime gaat op mijn dev bak van 8 seconden naar 1.8 (op productie respectievelijk van 0.8 naar 0.1 )

[ Voor 48% gewijzigd door SchizoDuckie op 24-01-2008 10:53 . Reden: Rustig typen duckie, dan snap je later zelf nog wat je geschreven hebt. ]

[Japius]

gvanh schreef op donderdag 24 januari 2008 @ 10:20:
... Query-cache heb ik net aangezet voor deze website, dat verbetert de performance iets, maar niet heel veel. (van 8,5 requests per seconde naar 10,08 requests per seconde). ...

Niet dat die 10.08 veel is, maar in vergelijking met de 8.5 toch een stijging van ruim 18%.

[ACM]

Als je echt wilt weten of je code langzaam is of de database: haal alle db-code eruit en zorg er voor dat op plekken waar je normaliter een query uitvoert je nu gewoon een geschikte array heb met data...

Mocht dan blijken dat je code langzaam is, dan kan je in eerste instantie toch weer es kijken naar opcode-cachers (zend optimiser is dat niet), zoals APC, eAccelerator, xcache, etc.

Mocht daarna nog steeds je code traag zijn, dan zit het blijkbaar niet in de laadtijden maar doe je onhandige php-constructies. In dat geval kan je xdebug gebruiken om je code te tracen en/of te profilen. Let er wel op dat je je code niet gaat benchmarken met xdebug geladen, want xdebug introduceert zelf aardig wat overhead en om die reden moet je ook weer niet te veel vertrouwen op de cijfers van een xdebug. Met xdebug's profiling kan je cachegrind.out's genereren die je met WinCachegrind kan bekijken (of kcachegrind in linux).

Mocht bij deze stappen je code wel snel gebleken zijn of voldoende geoptimaliseerd, dan kan je je queries weer laten uitvoeren. Je zou MySQL nog in kunnen stellen om de queries die geen index gebruiken te loggen etc.

Ik ga er hier trouwens wel bij van uit dat je de verschillen tussen MyISAM en InnoDB begrijpt en de juiste voor je tabellen hebt gekozen ivm de gebruikte concurrency e.d. en dat je dus niet tegen de table-locking van MyISAM aanloopt...
En dat als je zegt dat je queries goed geoptimaliseerd zijn dat je er liefst geen filesorts in uitvoert en dat je zoveel mogelijk 'using index' in je simpelste queries terug ziet.

[ Voor 5% gewijzigd door ACM op 24-01-2008 10:53 ]

[gvanh]

quote: gvanh

Ongeveer 9/10 keer wordt de fase in < 0,3s afgerond, maar in sommige gevallen duurt het ineens meer dan 5 seconde, tot soms wel 15/16/17 seconde.

Da's wel heel vreemd. Ik ga 'ns kijken of dat zit op het punt van het verbinden met de database ... misschien dat die een beperkt aantal connecties heeft of zo ...

Wat ik al vermoedde ... wanneer in de aanloop tijd veel tijd gaat zitten (in sommige gevallen 17 seconde!!!), dan wordt die tijd volledig besteed aan het opzetten van de database-verbinding. Iemand een idee hoe dat kan?

[LuCarD]

SchizoDuckie schreef op donderdag 24 januari 2008 @ 10:36:
[...]

eh daar heb je gelijk idd


[...]

Nou, eigenlijk is dit zo universeel dat het niet uit maakt of je hier nou complete queries mee cached of al pre-filled O/R mapped objecten Waar ik het zelf dus gebruik is om de Find() functie van mn dbObject (zie sig) heen, op die manier hoeft ie niet eens de database aan te spreken, of überhaupt de verbinding te bezetten:

PHP: class.dbObject.php

/** Snip uit m'n dbObject class, de gepatchte find functie */

    public function Find($className, $filters=array(), $extra=array(), $justThese=array()) 
    {
        $originalClassName = ($className instanceof dbObject) ? get_class($className) : $className;
        $class = new $originalClassName();
        if($originalClassName != get_class($this) && $this->ID != false) {
            $filters["ID"] = $this->ID;
            $filters = array(get_class($this) => $filters); 
        }
        $hash = sha1(serialize(Array($originalClassName, $filters, $extra, $justThese)));
        // serialize de array van parameters, en hash die weer, en voila, daar is je unieke searchquery voor ie bij de SQL builder uitkomt.
        if(QueryCache::isCached($hash)) // als die hash dan al bestaat, deze gebruiken en returnen
        {
            return QueryCache::useCache($hash);
        }
        else
        {
            $builder = new QueryBuilder($originalClassName, $filters, $extra, $justThese);
            $input = dbConnection::getInstance()->fetchAll($builder->buildQuery(), 'mysql_fetch_assoc');
            $objects = dbObject::importArray($originalClassName, $input);
            // zodra dan de nieuwe data binnengehaald is, deze even cachen a.d.h.v. de hash die al bekend is.
            QueryCache::cacheResult($hash, $objects);
            return($objects);
        }
    }

Aan de hand van de sha1 hash over de searchquery weet hij dat hij exact diezelfde gegevens binnen gaat krijgen Dit lapje code zorgt er bij mij bijvoorbeeld voor dat er op een bepaalde site in nog maar 6 plaats van 58 queries uitgevoerd worden, en de parseexecutiontime gaat op mijn dev bak van 8 seconden naar 1.8 (op productie respectievelijk van 0.8 naar 0.1 )

Ahh oke, hier cache niet alleen database results maar ook logica van je O/R mapper. Het scheelt kennelijk best wel. Maar de winst haal je uit het cachen van de logica en meerdere queries in een keer. Voor "normale" queries zal de snelheids winst minimaal of zelfs minder zijn dan de Query cache van de database.

[AtleX]

gvanh schreef op donderdag 24 januari 2008 @ 10:53:
[...]


Wat ik al vermoedde ... wanneer in de aanloop tijd veel tijd gaat zitten (in sommige gevallen 17 seconde!!!), dan wordt die tijd volledig besteed aan het opzetten van de database-verbinding. Iemand een idee hoe dat kan?

Kijk eens naar de verschillende MySQL optimalisatie guides op internet, dan kan je zien hoe je MySQL tuned met onder andere de maximale hoeveelheid connecties. Ook is het slim om zelf de connectie te sluiten als je 'm niet meer nodig hebt, de PHP documentatie beweert wel dat de connectie automatisch gesloten wordt aan het einde van je script, maar volgens mij sluiten ze 'm niet maar wordt hij gewoon opgeruimd.

[Kettrick]

gvanh schreef op donderdag 24 januari 2008 @ 10:53:
[...]


Wat ik al vermoedde ... wanneer in de aanloop tijd veel tijd gaat zitten (in sommige gevallen 17 seconde!!!), dan wordt die tijd volledig besteed aan het opzetten van de database-verbinding. Iemand een idee hoe dat kan?

Dit kan te maken hebben met table locking of een maximaal aantal connecties, dit kan je makkelijk debuggen door te kijken of het fout gaat tijdens de connect() of execute() methode.

[storeman]

Ik vind het ook leuk om af en toe eens naar optimalisatie te kijken. Ik kwam onlangs tot de volgende, vreemde conclusie:

Ik was dus eea aan het testen, hieruit komt het volgende naar voren:

Total requests: 80
Ordered by time (fastest above)
URL Total Req. time AVG Req time Index
http://localhost/_Research/performance/includecompressedlib.php 1.33074402809 s 0.0166343003511 s 100
http://localhost/_Research/performance/includemuchlibs.php 1.64647603035 s 0.0205809503794 s 123.725975514
http://localhost/_Research/performance/includeonelib.php 7.72132706642 s 0.0965165883303 s 580.226317265


Wat waarschijnlijk niet erg leesbaar is en ook niet zal worden, daarom de samenvatting.

De gecomprimeerde bibliotheek (zonder commentaar, witregels) wordt het snelste geinclude (0,016s), deze file is 528KB groot. Daarna volgen alle losse bestanden (niet gecomprimeerd) geinclude. Dit gebeurd in gemiddeld 0.021s. Maar dan, de niet gecomprimeerde file (wat dus gelijk staat aan de 64 losse bestanden), doet er maar liefst 0.09s over (huh, tis nog geen 10e, dus boeiuh??). Nee, dat boeit wel, dit duurt bijna 6 maal!! zo lang als bij één gecomprimeerde file (met dus exact dezelfde classes, er wordt géén code uitgevoerd!).

Heeft iemand hier een verklaring voor. Overigens geldt dit ook bij een require! Het gaat puur om de include, dus absoluut geen uitvoering van enige code, hoogstens een enkele constante. De code is uiteindelijk exact gelijk (muv commentaar en witregels).

Is iedereen net zo verbaast als ik? Ik had verwacht dat allemaal losse bestanden includen véél langer zou duren.

De bibliotheek bestaat uit alleen maar classes (al dan niet gebruikt voor een specifieke pagina).

[gvanh]

storeman schreef op donderdag 24 januari 2008 @ 20:59:
Ik vind het ook leuk om af en toe eens naar optimalisatie te kijken. Ik kwam onlangs tot de volgende, vreemde conclusie:

[...]

De bibliotheek bestaat uit alleen maar classes (al dan niet gebruikt voor een specifieke pagina).

Als ik het goed begrijp, is je gecomprimeerde library dus één PHP bestand met daarin de totale code die geïnclude moet worden, waarbij zoveel mogelijk alle commentaar en exces-whitespace is weggehaald? Gecomprimeerd betekent in deze dus niet dat er een gzip o.i.d. overheen gegaan is?

Is er een tool die dat eventueel voor me kan doen, bestanden combineren op deze manier? Dan kan ik hier eens testen of het voor mijn systeem wat uitmaakt.

[YopY]

Als ik het goed begrijp, is je gecomprimeerde library dus één PHP bestand met daarin de totale code die geïnclude moet worden, waarbij zoveel mogelijk alle commentaar en exces-whitespace is weggehaald? Gecomprimeerd betekent in deze dus niet dat er een gzip o.i.d. overheen gegaan is?

Is er een tool die dat eventueel voor me kan doen, bestanden combineren op deze manier? Dan kan ik hier eens testen of het voor mijn systeem wat uitmaakt.

Nee, dat maakt weinig tot niks uit. Het bij elkaar zetten van alle code zou misschien wat uitmaken (minder includes nodig), maar aan de andere kant krijg je dan dat PHP bij elk request je hele project inleest / uitvoert / na moet kijken. Het verwijderen van commentaar en whitespace maakt qua performance niks uit - aangezien ze beide genegeerd worden. De eventuele overhead die dat veroorzaakt mbt bestanden inladen is ook te verwaarlozen. Een beetje optimizer (en volgens mij PHP zelf ook (al)) vertaalt je PHP bestanden naar een interne representatie (compiled, zeg maar), waardoor dingen als bestanden inlezen en includes niks meer uitmaken, aangezien je hele programma dan in het geheugen geladen is.

[FragFrog]

Erm, hoe verklaar je dan storeman's ervaring?

* FragFrog was er ook wel nieuwschierig naar

[gvanh]

FragFrog schreef op vrijdag 25 januari 2008 @ 09:32:
Erm, hoe verklaar je dan storeman's ervaring?

Ja, precies.
Wat ik me kan voorstellen is dat het verwijderen van commentaren - ofwel ervoor zorgen dat de bestanden zo klein mogelijk zijn - de boel optimaliseert doordat er minder harddisk activiteit nodig is. Als er 30 keer tegelijk (30 concurrent requests) een willekeurig bestand van de harde schijf gelezen moet worden (wellicht op fysiek uiteenlopende plaatsen), dan kan het zijn dat de harde schijf het op een gegeven moment niet meer bijhoudt. Of dat boven een bepaalde grens de harddisk buffer (cache) het net niet kan bijhouden.

In dat geval zou het dus niet zozeer gaan om het verwerken van de PHP bestanden door de zend-engine, maar meer om eventuele bottle-neck bij het inlezen van de PHP bestanden. Iedere byte die je dan bespaart op de grootte van een bestand kan dan tijdwinst opleveren.

Dan nog even iets heel anders. Zojuist heb ik - ter lering en vermaak - TYPO3 geïnstalleerd om eens te zien hoe daar dingen aangepakt zijn. Eerste indruk: wat een draak van een beheer-interface. Maar dat terzijde. Ik heb één testpagina aangemaakt. Vervolgens heb ik dezelfde apache benchmark over die Typo3 pagina heen gehaald. Resultaat: maximaal 9,3 requests per seconde. Wat dat betreft is Typo3 (met caching aan) dus nog langzamer dan de inmiddels geoptimaliseerde versie van mijn eigen systeem (inmiddels zit ik op zo'n 13,50 requests per seconde).

[ Voor 5% gewijzigd door gvanh op 25-01-2008 10:00 ]

[FragFrog]

gvanh schreef op vrijdag 25 januari 2008 @ 09:59:
Wat dat betreft is Typo3 (met caching aan) dus nog langzamer dan de inmiddels geoptimaliseerde versie van mijn eigen systeem

offtopic:
Had je anders verwacht dan?

* FragFrog heeft ooit nog eens een baan aangeboden gekregen om Typo3 te gaan implementeren, nee bedankt

[gvanh]

FragFrog schreef op vrijdag 25 januari 2008 @ 10:15:
Had je anders verwacht dan?

Nou ... moet heel eerlijk zeggen dat ik niet zo veel weet van TYPO3. Maar met de grootte van de userbase van een dergelijk systeem en gezien het aantal mensen dat actief met de ontwikkeling bezig is, zou ik verwachten dat het beter geoptimaliseerd is dan mijn eigen CMS. Bovendien doen de referenties (waaronder de TROS, Konica Minolta en General Motors) vermoeden dat het een erg schaalbare oplossing is. Blijkbaar dus niet

[ Voor 3% gewijzigd door gvanh op 25-01-2008 10:27 ]

[Toolskyn]

storeman schreef op donderdag 24 januari 2008 @ 20:59:
Ik vind het ook leuk om af en toe eens naar optimalisatie te kijken. Ik kwam onlangs tot de volgende, vreemde conclusie:

[...]


De bibliotheek bestaat uit alleen maar classes (al dan niet gebruikt voor een specifieke pagina).

Zou ook wel eens interessant zijn om te kijken hoe in dat opzicht php archieven (phars) het doen, het zou iig een iets overzichtelijkere manier zijn.

[Equator]

Vraagje, mede uit eigen interesse..
Indien je veel gebruik maakt van sessie objecten is het dan niet interessanter om dit memory -based te doen in plaats van de (standaard meen ik ) file-based sessies in PHP. Of doe je dat al

Zie ook: http://devzone.zend.com/node/view/id/141

[ Voor 15% gewijzigd door Equator op 25-01-2008 11:00 ]

[gvanh]

Zelf maak ik gebruik van een database-gebaseerde (eigen geschreven) session handler. Of een memory-based session handler veel tijd scheelt weet ik niet. Ik zou er eens moeten in duiken. Ik heb de MM module nu niet geladen in PHP op mijn testbak.

[FragFrog]

Equator schreef op vrijdag 25 januari 2008 @ 10:59:
Vraagje, mede uit eigen interesse..
Indien je veel gebruik maakt van sessie objecten is het dan niet interessanter om dit memory -based te doen in plaats van de (standaard meen ik ) file-based sessies in PHP. Of doe je dat al

Zie ook: http://devzone.zend.com/node/view/id/141

Dat gaat weinig uitmaken, als je weet hoe sessie's werken: data van de vorige request wordt 1 keer ingelezen (zodra je session_start aanroept) en 1 keer weggeschreven (als het request al afgelopen is). Alle aanpassingen aan je sessie daartussenin vinden al plaats in je servers' geheugen. Aangezien mensen niet hoeven te wachten op het wegschrijven is het enkel een fileread die je daarmee bespaart, de overhead daarvan is te verwaarlozen.

Desalnietemin is het wel interessant je eigen sessionhandler te schrijven, maar ik zou dan eerder voor een database-based oplossing gedaan. Laatst zelf nog geschreven, ideaal als je met een loadbalanced cluster werkt of sessies direct wil kunnen koppelen aan userId's (om het aantal ingelogde gebruikers te tellen bijvoorbeeld) om maar iets te noemen

//edit
Memcache kan trouwens hetzelfde als die MM module zo te zien (ook instelbaar als custom session handler) en is daarnaast ook erg handig als je andere dingen in je servers' geheugen wilt stoppen. Zie ook de memcache site of mijn gezeur erover hier

[ Voor 12% gewijzigd door FragFrog op 25-01-2008 11:14 ]

[Equator]

Maar wanneer je 10.000 unieke bezoekers hebt, dis 5 verschillende pagina's moeten doorlopen, dan zijn dat nog altijd 50.000 lees en schrijf bewerkingen.. Ik heb werkelijk geen idee of dat heel veel uitmaakt, maar zoals ik al zei, pure interesse

[FragFrog]

Equator schreef op vrijdag 25 januari 2008 @ 11:14:
Maar wanneer je 10.000 unieke bezoekers hebt, dis 5 verschillende pagina's moeten doorlopen, dan zijn dat nog altijd 50.000 lees en schrijf bewerkingen.. Ik heb werkelijk geen idee of dat heel veel uitmaakt, maar zoals ik al zei, pure interesse

Tja, als je bedenkt dat een sessie bestand doorgaans niet meer dan een paar honderd bytes is en voor elke pageview in een beetje webapp tientallen PHP files geladen moeten worden van niet zelden duizenden bytes dan lijkt het me relatief heel erg weinig uitmaken. Meten is weten natuurlijk, maar ik heb in ieder geval nog nooit de sessionhandler hoog in onze profilers zien staan

Of laat ik het zo zeggen: onze custom sessionhandler is uit m'n hoofd iets van 100 lines. Dat zijn 100 lines code die nu extra geladen en geparsed moeten worden. Het bespaart ons 1 fileread die veel kleiner is. Het enige wat ervoor spreekt is dat het bestand in je filesystem cache staat, maar then again, dat staat dat sessie bestandje ook wel na een paar requests. Ik betwijfel ten zeerste of het performancewise ook maar iets uitmaakt

* FragFrog vermoedt dat het in dezelfde orde van grootte valt als enkele quotes ipv dubbele gebruiken

[ Voor 27% gewijzigd door FragFrog op 25-01-2008 11:25 ]

[Janoz]

Ja, maar enkele tientallen dezelfde bestanden die 10.000 keer nodig zijn, zijn door het filesystem natuurlijk heel makkelijk te cachen. Dat is heel wat anders dan 10.000 verschillende kleine bestandjes.

Ik zeg niet dat je ongelijk hebt, ik zeg alleen dat je gegeven argumentatie hierboven niet helemaal op gaat.

[Webgnome]

gvanh schreef op vrijdag 25 januari 2008 @ 09:59:
[...]


Ja, precies.
Wat ik me kan voorstellen is dat het verwijderen van commentaren - ofwel ervoor zorgen dat de bestanden zo klein mogelijk zijn - de boel optimaliseert doordat er minder harddisk activiteit nodig is. Als er 30 keer tegelijk (30 concurrent requests) een willekeurig bestand van de harde schijf gelezen moet worden (wellicht op fysiek uiteenlopende plaatsen), dan kan het zijn dat de harde schijf het op een gegeven moment niet meer bijhoudt. Of dat boven een bepaalde grens de harddisk buffer (cache) het net niet kan bijhouden.

In dat geval zou het dus niet zozeer gaan om het verwerken van de PHP bestanden door de zend-engine, maar meer om eventuele bottle-neck bij het inlezen van de PHP bestanden. Iedere byte die je dan bespaart op de grootte van een bestand kan dan tijdwinst opleveren.

Dan nog even iets heel anders. Zojuist heb ik - ter lering en vermaak - TYPO3 geïnstalleerd om eens te zien hoe daar dingen aangepakt zijn. Eerste indruk: wat een draak van een beheer-interface. Maar dat terzijde. Ik heb één testpagina aangemaakt. Vervolgens heb ik dezelfde apache benchmark over die Typo3 pagina heen gehaald. Resultaat: maximaal 9,3 requests per seconde. Wat dat betreft is Typo3 (met caching aan) dus nog langzamer dan de inmiddels geoptimaliseerde versie van mijn eigen systeem (inmiddels zit ik op zo'n 13,50 requests per seconde).

Muizen zijn ook een stuk sneller dan olifanten...

[FragFrog]

Janoz schreef op vrijdag 25 januari 2008 @ 11:31:
Ja, maar enkele tientallen dezelfde bestanden die 10.000 keer nodig zijn, zijn door het filesystem natuurlijk heel makkelijk te cachen. Dat is heel wat anders dan 10.000 verschillende kleine bestandjes.

Ik zeg niet dat je ongelijk hebt, ik zeg alleen dat je gegeven argumentatie hierboven niet helemaal op gaat.

Natuurlijk Janoz, ik impliceerde zelf ook al dat het minder bestanden zijn die makkelijker te cachen zijn, maar het project waar ik nu aan werk bijvoorbeeld zit ook al op een kleine 1500 bestanden - het duurt wel even voor je in die orde van grootte zit qua bezoekers

Daarnaast heb ik eerlijk gezegd geen idee hoe de verschilende file-caches / disk-caches werken - voor hetzelfde geld zijn die wel net zo goed in 10.000 kleine bestanden als 100 grote, dat zou een I/O expert beter kunnen vertellen

[gvanh]

Webgnome schreef op vrijdag 25 januari 2008 @ 11:35:
Muizen zijn ook een stuk sneller dan olifanten...

Ik snap niet helemaal wat je bedoelt ... dat TYPO veel groter en logger is dan mijn systeem en daarom minder snel? Lijkt me niet per sé waar. Helemaal in de basis-installatie die ik van TYPO heb neergezet, zou hij nog best lean en mean kunnen zijn, als aanvullende opties niet geladen worden wanneer ze niet nodig zijn.

[_Gekkie_]

Hmmm... Interessante discussie. Je zou ook eens moeten kijken naar je geheugen gebruik om te kijken wat het verschil is in het inladen van 1 bestand met al je classes en functies of alles op commando in te laten.. Het is dus niet altijd een keuze om zomaar álles op snelheid in te laden of juist op 'lean'-heid.

Verder zijn de meeste OPcode cache systemen zo gebouwd dat ze intern nog een filecache hebben waarmee IO's sowieso tot een minimum beperkt worden. Vaak zijn het de interne PHP calls binnen je vele bestanden die ervoor zorgen dat iets snel of langzaam werkt.

Daarnaast heb je buiten je IO ook te maken met je webserver zelf (hoeveel statische pagina's kan ie uberhaupt per sec aan?) probeer alle externe factoren écht uit te schakelen voordat je op minimale optimalisaties gaat richten...

(een van de grootste mythes is het weghalen van whitespace en commentaar om snelheidswinst te behalen...)

[storeman]

Om even terug te komen

gvanh schreef op vrijdag 25 januari 2008 @ 08:44:
[...]


Als ik het goed begrijp, is je gecomprimeerde library dus één PHP bestand met daarin de totale code die geïnclude moet worden, waarbij zoveel mogelijk alle commentaar en exces-whitespace is weggehaald? Gecomprimeerd betekent in deze dus niet dat er een gzip o.i.d. overheen gegaan is?

Is er een tool die dat eventueel voor me kan doen, bestanden combineren op deze manier? Dan kan ik hier eens testen of het voor mijn systeem wat uitmaakt.

YopY schreef op vrijdag 25 januari 2008 @ 09:20:
[...]


Nee, dat maakt weinig tot niks uit. Het bij elkaar zetten van alle code zou misschien wat uitmaken (minder includes nodig), maar aan de andere kant krijg je dan dat PHP bij elk request je hele project inleest / uitvoert / na moet kijken. Het verwijderen van commentaar en whitespace maakt qua performance niks uit - aangezien ze beide genegeerd worden. De eventuele overhead die dat veroorzaakt mbt bestanden inladen is ook te verwaarlozen. Een beetje optimizer (en volgens mij PHP zelf ook (al)) vertaalt je PHP bestanden naar een interne representatie (compiled, zeg maar), waardoor dingen als bestanden inlezen en includes niks meer uitmaken, aangezien je hele programma dan in het geheugen geladen is.

Ik heb zelf een tool geschreven die een bepaalde map comprimeert tot één grote lib file, ik vind het ook nog steeds een opvallende en ongeloofwaardige conclusie, maar ik heb de tests een aantal keren gedaan, verschillende volgordes etc, toch bleeft de conclusie hetzelfde.

Eén bestand waar alle whitespace en comments zijn gestript is veruit het snelste, daarna komen alle losse includes (70 includes, vanuit dezelfde map, file01.php, file02.php, in een loop) dit is 30 tot 50% trager. Daarna komt pas de grote lib file (dus nog met alle comments en whitespace), op 200-600%.

Ik heb nog de ambitie om de tool intelligenter te maken en op basis van require en includes een lib file te parsen.

YopY, het verbaasde mij ook, maar de conclusie is niet anders....

Voor mensen die willen testen met gestripte files, ik heb een formuliertje gemaakt die code voor je comprimeert, te vinden op:
http://tuincentrum.dyndns.info/compressor/

[ Voor 3% gewijzigd door storeman op 26-01-2008 00:34 . Reden: compressor toegevoegd ]

[Voutloos]

storeman schreef op zaterdag 26 januari 2008 @ 00:05:
Voor mensen die willen testen met gestripte files, ik heb een formuliertje gemaakt die code voor je comprimeert, te vinden op:
http://tuincentrum.dyndns.info/compressor/

Ik weet niet hoeveel moeite jij hebt gedaan, maar er is een php_strip_whitespace() functie (en commandline arg).

[storeman]

Ah, sheisse. Ik heb er inderdaad heel wat moeite voor gedaan, maar er is dus iemand geweest met hetzelfde idee. Het was wel leerzaam . Die functie kende ik dus niet...

[AtleX]

Gewoon tokenizen en dan T_COMMENT & T_WHITESPACE strippen. Tenminste, zo werkt mijn tool want in PHP4 bestond de functie van Voutloos nog niet.

[Voutloos]

Volgens mij is het commandline argument al langer aanwezig, dus een simpele `php -w -f __FILE__`; doet hetzelfde en is niet eens meer typwerk.

Maar goed, ik zeg het juist omdat ik hele volkstammen zelf zie aanklooien.

[storeman]

Zijn er nog mensen die een mogelijke verklaring hebben voor mijn conclusie, of is dit gewoon koffiedik kijken?

[Voutloos]

Conclusie is dat het nut kan hebben, maar dat het een vervelende extra stap is, eentje welke met een leuke opcode cache/server config niet/amper nodig hoeft te zijn.

[Fiander]

storeman schreef op zondag 27 januari 2008 @ 15:36:
Zijn er nog mensen die een mogelijke verklaring hebben voor mijn conclusie, of is dit gewoon koffiedik kijken?

Het enige wat ik kan bedenken, is dat bij de vele kleine bestanden, er door het os meerdere bestanden parallel gelezen kunnen worden.

Had je bij die test de meerdere kleine bestanden ook ontdaan van comentaar, of was dat alleen bij de grote includefile ?

[AtleX]

Fiander schreef op zondag 27 januari 2008 @ 16:31:
[...]

Het enige wat ik kan bedenken, is dat bij de vele kleine bestanden, er door het os meerdere bestanden parallel gelezen kunnen worden.

Je OS kan op z'n hoogst I/O opdrachten queuen, of van meerdere disks tegelijk lezen als ze niet in RAID staan. Een harde schijf kan immers maar op 1 positie tegelijk lezen.

[storeman]

Ik had dat ene bestand opgesplitst in allemaal kleine bestanden, deze kleinere bestanden bevatten ook het commentaar, net zoals het grootste bestand. Ik heb echter ook geprobeerd om alle losse bestanden te strippen, dit was iets sneller dan met commentaar, maar haalde het nog steeds niet bij het grote gestripte bestand.

Mensen die beweren dat commentaar geen invloed heeft op je performance wil ik graag met een tegenargument zien komen, mijn experiment wijst namelijk uit dat het wel degelijk het geval is. Het ik ook logisch (commentaar moet toch genegeerd worden, dus ook herkent worden, dus zal het een fractie processorkracht kosten).

Overigens is het niet erg realistisch om te gaan verwachten dat commentaarloze files een stuk sneller zullen zijn. Het experiment dat ik heb uitgevoerd kijkt puur naar de include-time en niet naar de snelheid van de code zelf. Daar zal het commentaar geen enkel effect op hebben.

[ACM]

storeman schreef op zondag 27 januari 2008 @ 20:31:
Mensen die beweren dat commentaar geen invloed heeft op je performance wil ik graag met een tegenargument zien komen.

Die mensen zijn doorgaans van mening dat een marginale performancewinst niet opweegt tegen sterk verminderde onderhoudbaarheid van de code. En allerlei trucken uithalen om de code tijdens het deployen te strippen van whitespace is tamelijk zinloos als je toch al een opcodecacher gebruikt.

En dat heeft sowieso meer effect, want het bespaard een hele zwik parsingstappen extra.

[storeman]

ACM schreef op zondag 27 januari 2008 @ 20:46:
[...]

Die mensen zijn doorgaans van mening dat een marginale performancewinst niet opweegt tegen sterk verminderde onderhoudbaarheid van de code. En allerlei trucken uithalen om de code tijdens het deployen te strippen van whitespace is tamelijk zinloos als je toch al een opcodecacher gebruikt.

En dat heeft sowieso meer effect, want het bespaard een hele zwik parsingstappen extra.

Voor de helderheid, ik ben zeker niet voor commentaarloze code! Goed commentaar is vaak net zo nuttig als de code zelf, echter moet er wel naar self-explaining code gestreefd worden.

offtopic:
(laat de discussie aub niet deze kant op drijven)

[SchizoDuckie]

storeman schreef op zondag 27 januari 2008 @ 20:59:
[...]


Voor de helderheid, ik ben zeker niet voor commentaarloze code! Goed commentaar is vaak net zo nuttig als de code zelf, echter moet er wel naar self-explaining code gestreefd worden.

offtopic:
(laat de discussie aub niet deze kant op drijven)

Waarom doe je ingodesnaam zoveel moeite eigenlijk voor dit soort micro optimalisaties?
Als je ech meer performance nodig hebt kun je beter gaan kijken naar een bytecode compiler voor php of naar een dikkere server config. Voordeel daarvan is dat je nog eens een hotfix op je code kunt uitvoeren en die code gewoon kunt doorlezen met een text-editor via een ssh sessie.

De tests die jij gedaan hebt zijn allang eerder gedaan en je conclusies zijn ook echt niet nieuw (en ook heel logisch) Punt is gewoon dat een extra server in het rack en een load balancer ertussen (of wat mij betreft een simpel scriptje wat aan de hand van een countertje telkens de request naar een van de beide servers redirect) vanuit een management inzicht veel goedkoper en efficienter is dan wat jij hier allemaal aan het prutsen bent.

Onderhoudbaarheid van code is in de 'real world' gewoon veel belangrijker dan een paar micro optimalisaties (uit dezelfde hoek als het hele loze " vs ' verhaal). Als je dit doet vanuit het oogpunt om zo veel mogelijk requests per seconde door je server heen te kunnen stampen kun je ook beter op voorhand een extra server erbij kopen, want de eerste de beste keer dat je dan een beetje media aandacht krijgt en boven de door jou bedachte limieten uitkomt gaat de hele boel op zn gat.

Mijn advies dus: Voeg slimme caching mechanismes toe waar je daar ook echt merkbaar voordeel uit kan halen, maar ga niet het hele idee van een interpreted programmeer/script taal proberen onderuit te halen, dan kan je net zo goed naar een (bytecode-)compiled taal kijken

[ Voor 10% gewijzigd door SchizoDuckie op 27-01-2008 21:47 ]

[storeman]

SchizoDuckie schreef op zondag 27 januari 2008 @ 21:44:
[...]


...

Ik ben het met je eens, Zend heeft leukere tools geschreven om eea sneller te draaien en de winst is zeer klein. Echter heb ik het niet met één doel geschreven, mijn doel was ook om de code minder leesbaar te maken, ik heb er ook een obfuscater bij geschreven. De combinatie van géén commentaar en obfuscated vars, private functions en encoded strings maken de code zeer ontoegangelijk. Ik was tevens benieuwd naar de snelheidswinst en vond het een uitdaging een dergelijk script te schrijven. Ik ben toen naar de performance gaan kijken en ik verbaasde mij over de conclusie.

Je haalt aan dat het eigenlijk heel logisch is dat bepaalde situaties sneller zijn, heb je hier een linkje naar, ik ben namelijk benieuwd waar dat vandaan komt. Ik vind het namelijk niet logisch.

[SchizoDuckie]

storeman schreef op zondag 27 januari 2008 @ 23:04:
[...]
Je haalt aan dat het eigenlijk heel logisch is dat bepaalde situaties sneller zijn, heb je hier een linkje naar, ik ben namelijk benieuwd waar dat vandaan komt. Ik vind het namelijk niet logisch.

Ik heb zo geen link, maar als je logisch nadenkt zal PHP intern toch die hele handel moeten parsen. Minder te parsen betekent minder cpu cycles lijkt mij

[Voutloos]

storeman schreef op zondag 27 januari 2008 @ 23:04:
De combinatie van géén commentaar en obfuscated vars, private functions en encoded strings maken de code zeer ontoegangelijk. Ik was tevens benieuwd naar de snelheidswinst en vond het een uitdaging een dergelijk script te schrijven.

De meeste obfuscation trucs (op oa zwaardere encoding en control flow trucs na) leiden ook tot betere performance, dus dat is eigenlijk ook geen nieuwe conclusie. Maar goed, het is inderdaad wel leuk om een keer zo'n script te maken, wat met PHP een stuk grotere uitdaging is dan menig andere taal btw.