[PHP][PEAR] Performance issue tov rectstreeks mysql

[Q]

Ik heb een classes file die met de database spreekt (MYSQL).

Gebenchmarkt met Apachebenchmark -c 500 -n 10 (machine = pII 300 / 256 / debian linux)

Naar mijn idee is PEAR een probleem:

code:

RESULTAAT classes.php MET PEAR
--------------------------------

Requests per second:    16.40 [#/sec] (mean)
Time per request:       609.90 [ms] (mean)
Time per request:       60.99 [ms] (mean, across all concurrent requests)
Transfer rate:          2.21 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     0    0.3      0     5
Processing:    39   604  384.9    527  2299
Waiting:       38   603  384.9    526  2298
Total:         39   604  384.9    527  2299

code:

RESULTAAT classes.php ZONDER PEAR (DIRECT PHP mysqlfuncties)
------------------------------------------------------------

Requests per second:    233.21 [#/sec] (mean)
Time per request:       42.88 [ms] (mean)
Time per request:       4.29 [ms] (mean, across all concurrent requests)
Transfer rate:          47.11 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     0    0.4      0     5
Processing:     5    42   24.9     41   226
Waiting:        4    41   24.9     40   225
Total:          5    42   24.9     41   226

Heeft iemand een idee hoe dit kan? Is pear brak of zou er iets mis moeten zijn met mijn installatie?

[djc]

Tsja, de Object Orientatie kost onder PHP 4 nog vrij veel performance, en je zal ongetwijfeld ook "betalen" voor de extra features die de PEAR DB je geeft in termen van performance. Ik denk dat het in PHP 5 wel beter gaat, maar tot die tijd is hier niet zo veel aan te doen, denk ik.

[LuCarD]

Dit is wel een aanzienlijk verschil, kan je misschien beide php als phps files online zetten. Ik wil er wel even naar kijken, en ben benieuwd waar die vertraging vandaan komt.

[Q]

LuCarD:

Pear: http://home.quicknet.nl/mw/prive/nan1/classes.php.pear

Mysql: http://home.quicknet.nl/mw/prive/nan1/classes.php.mysql

Ik moet toegeven dat mijn php ervaring nog niet zo bijster groot is (misschien is code niet zo heel netjes). Ik heb echter geen idee wat het kan zijn.

[chem]

Maak van die fetch loopjes iig zoiets:

PHP:

while($row = mysql_fetch_array())
{
$result[] = $row;
}

Scheelt je weer een onnodig tellertje.

[Q]

chem schreef op 20 januari 2003 @ 10:28:
Maak van die fetch loopjes iig zoiets:

PHP:

while($row = mysql_fetch_array())
{
$result[] = $row;
}

Scheelt je weer een onnodig tellertje.

Ik waardeer je hulp, dat van die while-loop dank ik je voor, maar dat is het probleem niet. Het probleem is de pear code. Die maar met 15 req/s kunnen worden uitgevoerd v.s. de mysql code met 50 req/s

[Q]

Ik wil dit onderwerp graag nog 1 keer onder de aandacht brengen. Iemand de zelfde ervaringen met Pear?

[ACM]

PHP:

function execute( $sql) {
    
        global $db;

Dat is potentieel iets wat slomer is, je kan beter een class-variabele gebruiken voor zoiets.

PHP:

    function get( $table, $criteria ) {
        
        //$sql = "SELECT * FROM $criteria $table";
        $sql = "SELECT * FROM $table $criteria";
        //echo $sql;
        $result = Database::execute( $sql );        
        //echo "$result[0] fiets";
        for ($i=0; $row = $result->fetchrow(DB_FETCHMODE_ASSOC); $i++ ) {
    
        $objectarray[$i] = $row; 
    
        }
        return $objectarray;
    }

Je doet de hele tijd Database:: enzo, kan je niet beter gewoon $this->execute doen ? (maar dat doe je bij beide).

Het verschil zal, uiteraard, grotendeels in je execute methode zitten. Er zijn daar een paar verschillen. Onder andere dus die global call en later nog de error-handling, commentaar die error handling in beide eens uit en kijk hoeveel het dan verschilt.

En maak van de $db als test een class variabele.

Daarnaast is het niet onverwachts dat er een (groot) verschil tussen Pear en de directe functies zit. Pear doet nogal wat extra handelingen bij het roepen van een functie, die je evt niet nodig hebt maar ze worden toch gedaan.
Verder staat Pear het wijzigen van een database op het niveau van Pear al toe en je hoeft niet perse een wrapper rond Pear schrijven, maar je kan Pear direct al toepassen

[ Voor 18% gewijzigd door ACM op 21-01-2003 14:00 ]

[Q]

Dank voor de info: dit is de eerste keer dat ik echt eens serieus met php aan de gang ben gegaan. Ik had pear dr ffies ingezet naar aanleiding van tip, omdat je dan zonder veel moeite van type db kan switchen. Echter, in deze opzet, is het ook maar het wijzigen van een stuk of 5-6 regels.

Dat van die 'This->execute' al ik er in verwerken.

Wat betreft pear: slechts het includen van pear, blijkt inmiddels, is al voldoende om nog maar 15 req/s te kunnen verwerken. Ik denk dat ik als php-mysql beginner het maar zo even aanpak (zonder pear).

[tech-no-logical]

Q schreef op 21 januari 2003 @ 22:25:
Wat betreft pear: slechts het includen van pear, blijkt inmiddels, is al voldoende om nog maar 15 req/s te kunnen verwerken. Ik denk dat ik als php-mysql beginner het maar zo even aanpak (zonder pear).

naar aanleiding van deze uitspraak heb ik even een kleine test gedaan. voor 't project waar ik nu mee bezig ben gebruik ik ook PEAR (PIII 1Ghz 256 MB Debian). uit tests blijkt dat bij mij 't includen van PEAR ongeveer 0.006 seconden kost, het includen van PEAR _en_ DB ongeveer 0.011 seconden, en de eerste query is gedaan na 0.030 seconden. zonder optimalisatie zou mijn desktop dit request dus zo'n 33 keer per seconde uit kunnen voeren.
zelfde test, met eigen functies die mysql_* gebruiken geven voor de eerste query 0.004 seconden (250 reqs/sec). dit alles komt wel zo'n beetje overeen met jouw tests...

het totaal per gegenereerde pagina is iets minder dramatisch : met PEAR en DB 0.12 sec, zonder PEAR en DB 0.05 sec. daarin zitten minstens 4 queries, het genereren van 3 domxml-objects en een xslt_process stap.

de applicatie komt straks op een grotere machine en is administratief van aard, dus het aantal reqs/sec zal wel meevallen, maar toch is 't verschil groter dan ik dacht.

overigens wacht ik ook al een hele tijd op php5, oop in php4.* zuigt imho al heel lang heel erg.

[djc]

PHP 5 wordt volgens de laatste schattingen pas verwacht in augustus.

[Rense Klinkenberg]

Manuzhai schreef op 22 januari 2003 @ 11:11:
PHP 5 wordt volgens de laatste schattingen pas verwacht in augustus.

De snapshots zijn beschikbaar op http://snaps.php.net/. Zelfs gecompileerde windows versies van cvs HEAD

[Q]

Tech-no-logical: buitengewoon interesting. natuurlijk is het zo dat als je er wat pittige hardware tegen aan gooit dat het dan niet zo heel veel uitmaakt. Ik ga echter een site bij een hoster draaien en ik denk niet dat ze het fijn zullen vinden als een site met pear eventueel goed bezocht gaat worden...

offtopic: wat is er zo speciaal aan php5 tov php4? (ik hoop op dabse onafhankelijke methoden oid)

[tech-no-logical]

Q schreef op 22 January 2003 @ 13:19:
Ik ga echter een site bij een hoster draaien en ik denk niet dat ze het fijn zullen vinden als een site met pear eventueel goed bezocht gaat worden...

als de hoster PEAR beschikbaar stelt zou ik me over de performance niet zo'n zorgen maken

offtopic: wat is er zo speciaal aan php5 tov php4? (ik hoop op dabse onafhankelijke methoden oid)

als je db-onafhankelijk methods wilt hebben kun je naar de 'dbx'-module kijken (bestaat die nog ?).
php5 krijgt een betere oop-implementatie, en betere pass-by-reference enzo (als je nu pass-by-reference wilt doen is dat hel, en vaak werkt 't ook gewoon niet goed : bijvoorbeeld als je domxml gebruikt).

misschien moet ik de snapshots maar 's gaan bekijken...

[Q]

als de hoster PEAR beschikbaar stelt zou ik me over de performance niet zo'n zorgen maken

De persoon die mij pear had aangesmeerd heeft ook die hoster gevraagd om pear te installeren vanwege zijn eigen pear-site. Niet wetende dat pear dus een pittige performance hit kan betekenen, zoals wij hebben gezien.

[djc]

freak007 schreef op 22 January 2003 @ 11:36:
De snapshots zijn beschikbaar op http://snaps.php.net/. Zelfs gecompileerde windows versies van cvs HEAD

Ik bedoelde een stable release.

De dbx-module bestaat zeker nog, maar ik geloof dat er niet zo erg veel development meer in zit.

[tech-no-logical]

Manuzhai schreef op 23 January 2003 @ 09:52:
[...]
Ik bedoelde een stable release.

als ik PHP-dev een beetje bekijk denk ik dat augustus optimistisch is. er liggen nog een aantal hele grote beslissingen open, geloof ik. het meest gegeven antwoord is nog steeds "when it's ready"

De dbx-module bestaat zeker nog, maar ik geloof dat er niet zo erg veel development meer in zit.

volgens mij hoeft dat ook niet, hij werkt gewoon. nadeel : gebaseerd op een grootste gemene deler qua feature-support (kort gezegd 'alles wat mysql kan'). voordeel : de ontwikkelaar is een vriend van me, dus ik weet waar ik moet zijn als er problemen zijn.

[GraasGast]

Die eigen class van jou kan zelfs nog sneller. Je maakt nu voor elke query een database connectie, en dat is niet slim.

haal dit:

code:

$db = mysql_connect("localhost", "root");
mysql_select_db("nan",$db);

uit de functie execute en maak een constructor Database aan en zet het daar in:

code:

function Database() {
        $this->db = mysql_connect("localhost", "root");
        mysql_select_db("nan",$this->db);
}

en dan dus overal $this->db en $this->execute() gebruiken

[ Voor 75% gewijzigd door GraasGast op 23-01-2003 11:24 ]

[ACM]

Nee, dat doet ie niet
Zie commentaar bij de mysql_connect functie...

Maar het is wel beter om een class-variabele te gebruiken ja.

[Q]

GraasGast schreef op 23 januari 2003 @ 11:21:
Die eigen class van jou kan zelfs nog sneller. Je maakt nu voor elke query een database connectie, en dat is niet slim.

haal dit:

code:

$db = mysql_connect("localhost", "root");
mysql_select_db("nan",$db);

uit de functie execute en maak een constructor Database aan en zet het daar in:

code:

function Database() {
        $this->db = mysql_connect("localhost", "root");
        mysql_select_db("nan",$this->db);
}

en dan dus overal $this->db en $this->execute() gebruiken

Hmm. ik snap het idee, nu zal bij iedere query execute worden gerunt en dus die db connectie. Via de constructor zal slechts 1 malig per object een connectie worden gemaakt. Ik ben aan het knoeien, maar werken doet het niet erg goed.

Edit: herstel: dat werkt prima en perfect.

[ Voor 9% gewijzigd door Q op 23-01-2003 13:01 ]

[GraasGast]

das mooi

ACM: welk commentaar bedoel je? ik niet vinden kan

[ACM]

GraasGast schreef op 23 januari 2003 @ 13:41:
das mooi

ACM: welk commentaar bedoel je? ik niet vinden kan

quote: http://www.php.net/mysql_connect

If a second call is made to mysql_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned.

[GraasGast]

Ow op die fiets...zeg dan 'documentatie' en niet 'commentaar', ik zat te zoeken in de 2 scripts die de topicstarter heeft gepost

maar je hebt gelijk, het hoeft niet, maar het is toch netter om de connectie eenmalig te maken en in een constructor te zetten.

[ Voor 16% gewijzigd door GraasGast op 23-01-2003 13:50 ]