[PHP] Scripts testen op efficiency / Serverload

[Verwijderd]

Ik ben op zoek naar een programma of PHP add-in waarmee je de efficientie van scripts kan testen zodat je kan zien welke functies bijvoorbeeld veel tijd kosten of welke erg intensief voor de server zijn.
Bestaat er zoiets?

En misschien niet helemaal on-topic:
Wat is een acceptabele server-load voor een linux webserver? Hij draait MySQL en PHP.
Heb nu regelmatig een load meer dan 1,50. Heb nog niet echt trage pagina's maar bij welke load moet ik gaan denken aan upgrades?

[Verwijderd]

Antwoordt op je eerste vraag: PEAR ( pear.php.net ) heeft een package genaamd Benchmark die dit kan doen.

[u_nix_we_all]

Verwijderd schreef op donderdag 15 september 2005 @ 15:15:
Ik ben op zoek naar een programma of PHP add-in waarmee je de efficientie van scripts kan testen zodat je kan zien welke functies bijvoorbeeld veel tijd kosten of welke erg intensief voor de server zijn.
Bestaat er zoiets?

Dat weet ik niet, maar als mogelijk is de scripts vanaf de command line uit te voeren kun
je m.b.v. "time <scriptnaam>" de verbruikte cpu tijd zien.

En misschien niet helemaal on-topic:
Wat is een acceptabele server-load voor een linux webserver? Hij draait MySQL en PHP.
Heb nu regelmatig een load meer dan 1,50. Heb nog niet echt trage pagina's maar bij welke load moet ik gaan denken aan upgrades?

Hangt een beetje af van wat de server doet. Als je veel i/o moet doen (bijv. een database)
staat de load soms hoog omdat de cpu wacht op data van de disken.
Ik heb wel db servers gezien die continue een load van 8 of meer hadden.

Optimaliseren van queries kan soms veel zinniger zijn dan hardware upgraden.

[degroot]

Weet ook niet of er al een raidconfiguratie in je server zit.
Maar met een RAID5 of RAID10(1+0) is de database acces natuurlijk ook veel en veel sneller. maar zijn dat ook de kosten waard?
En dat zal de CPU load ook wel iets lager houden dan dat je op data zit te wachten van 1 enkele schijf.
Voor een webserver weet ik eigenlijk niet of dat veel zal uitmaken.

Zijn allemaal factoren die meespelen

[ Voor 13% gewijzigd door degroot op 15-09-2005 15:33 ]

[Verwijderd]

degroot schreef op donderdag 15 september 2005 @ 15:29:
Weet ook niet of er al een raidconfiguratie in je server zit.

Heb nu alleen mirroring, geen striping. Een andere RAID configuratie is inderdaad iets waar ik ook al aan zat te denken en is redelijk snel te realiseren natuurlijk.

[Verwijderd]

u_nix_we_all schreef op donderdag 15 september 2005 @ 15:24:
[...]

Dat weet ik niet, maar als mogelijk is de scripts vanaf de command line uit te voeren kun
je m.b.v. "time <scriptnaam>" de verbruikte cpu tijd zien.

Zal het eens proberen, hoewel ik de tijd die een script in beslag neemt wel al weet. Ken het commando time niet echt dus weet niet wat voor extra informatie het geeft.

Hangt een beetje af van wat de server doet. Als je veel i/o moet doen (bijv. een database)
staat de load soms hoog omdat de cpu wacht op data van de disken.
Ik heb wel db servers gezien die continue een load van 8 of meer hadden.

Optimaliseren van queries kan soms veel zinniger zijn dan hardware upgraden.

De database wordt inderdaad veelvuldig aangesproken, eigenlijk voor zo'n beetje iedere pagina.
Zou eens moeten uitvinden of de disk de bottleneck is misschien.
Wat betreft de queries, daar had ik vraag 1 ook een beetje voor gesteld. Zodat ik kan kijken wat er telkens het langst duurt.

[TheBorg]

Een load van 1,5 is nog niet zorgelijk.

Verdiep je eens in de cache instellingen van MySQL in de my.cfg. Kan een wereld van verschil maken.

[Janoz]

Efficientie problemen bij php scripts hebben in de meeste gevallen te maken met inefficiente queries of het niet/weinig gebruik maken van indices. Het lijkt me dan ook handiger om daar eens naar te kijken.

Sowieso zit je in de programmeer afdeling van Got. Als je het daadwerkelijk over serverconfiguraties wilt gaan hebben zul je bij de hardware poot moeten zijn.

[u_nix_we_all]

Verwijderd schreef op donderdag 15 september 2005 @ 15:57:
[...]


Zal het eens proberen, hoewel ik de tijd die een script in beslag neemt wel al weet. Ken het commando time niet echt dus weet niet wat voor extra informatie het geeft.

"man time"
De verbruikte cpu tijd wordt ook weergegeven.

De database wordt inderdaad veelvuldig aangesproken, eigenlijk voor zo'n beetje iedere pagina.
Zou eens moeten uitvinden of de disk de bottleneck is misschien.
Wat betreft de queries, daar had ik vraag 1 ook een beetje voor gesteld. Zodat ik kan kijken wat er telkens het langst duurt.

Dat je disk je bottleneck is is vrij normaal.
Om te optimaliseren zou je ook op db niveau kunnen gaan uitzoeken wat de zwaarste queries
zijn.
Ook optimaliseren van je db zelf is een optie (tabellen indexeren e.d)

[ACM]

Verwijderd schreef op donderdag 15 september 2005 @ 15:15:
Ik ben op zoek naar een programma of PHP add-in waarmee je de efficientie van scripts kan testen zodat je kan zien welke functies bijvoorbeeld veel tijd kosten of welke erg intensief voor de server zijn.
Bestaat er zoiets?

De extension xdebug kan loggen hoelang elk statement van een file duurde. Nadeel is natuurlijk dat het loggen zelf ook tijd kost.

En misschien niet helemaal on-topic:
Wat is een acceptabele server-load voor een linux webserver? Hij draait MySQL en PHP.
Heb nu regelmatig een load meer dan 1,50. Heb nog niet echt trage pagina's maar bij welke load moet ik gaan denken aan upgrades?

Ik zou streven om onder de "1 per cpu" te blijven, dus als je een dual-dual-core doos hebt onder de 4 blijven, bij een single-cpu (ook met HT) onder de 1 blijven.

Dat is in sommige gevallen erg lastig, met name als er zware I/O-operaties zijn.

Zoals Janoz overigens al zegt zit het grootste deel van je tijd waarschijnlijk in de executie van de queries. MySQL is met een standaard configuratie al redelijk snel, dus moet je zeer waarschijnlijk op zoek naar slome queries in je applicaties. De slow-query-log van mysql is een nuttig hulpmiddel om de slomere queries te identificeren.

u_nix_we_all schreef op donderdag 15 september 2005 @ 16:13:
Ook optimaliseren van je db zelf is een optie (tabellen indexeren e.d)

Ik zou dat niet "een optie" willen noemen... Dit is in de meeste gevallen de belangrijkste stap in het optimaliseren van database-gebaseerde webapplicaties, hier zijn over het algemeen de grootste winsten te bereiken.

[ Voor 15% gewijzigd door ACM op 15-09-2005 16:17 ]

[Verwijderd]

TheBorg schreef op donderdag 15 september 2005 @ 16:02:
Een load van 1,5 is nog niet zorgelijk.

Verdiep je eens in de cache instellingen van MySQL in de my.cfg. Kan een wereld van verschil maken.

Met query-caches was ik inderdaad al eens bezig geweest en dat scheelt behoorlijk

[Verwijderd]

ACM schreef op donderdag 15 september 2005 @ 16:15:
[...]

De extension xdebug kan loggen hoelang elk statement van een file duurde. Nadeel is natuurlijk dat het loggen zelf ook tijd kost.

Ik zal er eens naar gaan kijken.

Bedankt voor je verdere aanbevelingen. Zal nog eens alle queries gaan doornemen om te zien waar het beter kan.

[bartvb]

Ander erg handig tooltje is 'mytop'. Daar zijn (iig als je server flink belast is) erg makkelijk problematische queries uit te vissen. Het nadeel van de slow query log is dat het nogal zoeken is in dat ding aangezien queries die zelf niet zwaar zijn maar staan te wachten op een tablelock ook (in grote getalen) in die log aanwezig zijn.

Verder natuurlijk gewoon je queries timen en van te voren nadenken over indices e.d.

[GX]

Ik ben zelf groot fan van het PECL pakket apd (installeren met pear install apd). Laat per script de tijden en load zien, maar ook de processcall-tree, en de cpu-tijd per functie, en nog veel meer. Erg prettig