PHP & MYSQL op website zeer traag

[GewoonNico]

Ik zit met het volgende probleem:

Mijn website is gescript met php&mysql, op mijn localhost draaide alles heerlijk en lekker snel. Nooit ergens problemen mee gehad totdat ik het zaakje ging uploaden.

Ik heb mijn probleem al in verschillende topics gevonden, alleen hier kwam het er altijd op uit dat de server overvol was. Maar dit is bij mij niet het geval. Ik heb een aantal functies uitgeprobeerd in php (welke ik gevonden had in de andere topics) en ik sta voor een raadsel. Het volgende heb ik uitgeprobeerd:

PHP:

// Starttijd
$mtime = explode(" ",microtime()); 
$starttime = $mtime[1] + $mtime[0]; 
// alle php pagina's

// Eindtijd
$mtime = explode(" ",microtime()); 
$endtime = $mtime[1] + $mtime[0]; 
$totaltime = ($endtime - $starttime);

code:

This page was created in 2.007 seconds 
09:23:17 up 5 days, 16:50, 0 users, load average: 0.59, 0.23, 0.16

PHP:

$status = explode('  ', mysql_stat());
print_r($status);

code:

Array
(
    [0] => Uptime: 492717
    [1] => Threads: 1
    [2] => Questions: 19730589
    [3] => Slow queries: 632
    [4] => Opens: 7251
    [5] => Flush tables: 1
    [6] => Open tables: 1024
    [7] => Queries per second avg: 40.044
)

PHP:

echo nl2br(`ls -la /home`);

code:

total 28<br />
drwxr-xr-x    7 root     root         4096 Apr 19 10:09 .<br />
drwxr-xr-x   20 root     root         4096 Apr 19 09:45 ..<br />
drwxr-xr-x    2 root     root         4096 Jan 30 12:51 ftp<br />
drwxr-xr-x    3 root     root         4096 Dec 28 21:05 httpd<br />
drwxr-xr-x    7 root     root         4096 Jan 24 02:14 phpMyAdmin<br />
drwxr-xr-x    7 root     root         4096 Apr 19 10:09 phpMyAdmin-2.6.1<br />
drwxr-xr-x    5 1000     1000         4096 Jan 13 19:50 phpSysInfo<br />

En ik heb ook nog eens lijst van de commando's

PHP:

//echo nl2br(`top -b -n 3`); 
//echo nl2br(`ps axf`); 

Alleen deze is wat groot om te posten.

De ping zit altijd rond de 15 en 20 ms. Met een enkele keer een uitschieter van 1000 ms. Maar dit komt 1x per minuut voor.

Het vreemde is, dat elke keer als ik een pagina opvraag er ongeveer 1,5 a 2 seconden overheen gaat en als ik een refresh doe -> CTRL + F5 dan gaat er bijvoorbeeld maar 0.01 seconden overheen.

Op mijn localhost draaide alles zonder problemen en zonder traagheid.

specs
Processor: P4 3 ghz
Geheugen: 1.024 mb
HD: 2x 80GB raid 1
Mysql: localhost

Ik moet er wel bij vertellen dat de website nog niet officieel in de lucht is, dit komt pas a.s. woensdag. Ik heb hiervoor een aanpassing moeten doen in mijn hosts file.
Is het mogelijk dat hier het probleem ligt?

code:

82.192.84.140   www.exilim-output.nl

[ Voor 4% gewijzigd door GewoonNico op 23-04-2005 09:56 ]

[GewoonNico]

Mij viel het aantal open tables heel erg op.
Kan dit een probleem veroorzaken?

[vriesdude]

Windows of Linux machine.

Ik heb ervaringen mee dat de defualt config van Windows, IIS en PHP niet helemaal soepeltjes is namelijk. Maar als het nu over linux gaat dan is dit niet van toepassing.

[Verwijderd]

vriesdude schreef op zaterdag 23 april 2005 @ 20:34:
Windows of Linux machine.

Ik weet niet of jij weleens de commando's ls, top en ps op een Windows machine uitvoert?

Maar de topicstarter kan het best even uitzoeken welk stukje van zijn script zoveel tijd in beslag neemt. Als het met élk scriptje gebeurt is er duidelijk iets mis met de server (configuratie). Het kan ook gewoon aan een slecht in elkaar gezet script liggen (dat bijvoorbeeld meerder malen een verbinding met mysql maakt).

[ Voor 3% gewijzigd door Verwijderd op 23-04-2005 20:40 ]

[vriesdude]

Verwijderd schreef op zaterdag 23 april 2005 @ 20:39:
[...]

Ik weet niet of jij weleens de commando's ls, top en ps op een Windows machine uitvoert?

_{Ehh het zoumoeten kunnen, gewoon een .exe in de windows map zetten met die naam..}

Maar ik ben verder geen linux kenner en wou alleen maar TS helpen

Maar de topicstarter kan het best even uitzoeken welk stukje van zijn script zoveel tijd in beslag neemt. Als het met élk scriptje gebeurt is er duidelijk iets mis met de server (configuratie). Het kan ook gewoon aan een slecht in elkaar gezet script liggen (dat bijvoorbeeld meerder malen een verbinding met mysql maakt).

[Verwijderd]

De kans dat het aan de entry in je hosts file ligt is zeer klein, het lijkt hem meer te zitten in de scripting an sich inderdaad zoals cheatah al zei

Probeer het eens heel procies te timen, dus doe het eens per query / gedeelte van de code om uit te zoeken waar het hem nou precies in zit

[GewoonNico]

Mijn computer betreft een Windows Machine, de server waar de website nu op draait is een Unix machine.

De scripting is naar mijn inziens in orde, het vreemde is namelijk dat de ene keer de server er 3 seconden over doet en de andere keer maar 0,03.
Kan het niet aan de configuratie van mysql liggen, of kan het niet iets in die richting zijn?

[_JGC_]

Heb je in apache reverse lookups aan staan? Grote kans dat apache of PHP 2 seconden staat te wachten op een NXDOMAIN response of een time-out, wat die 2 seconden verklaart, om vervolgens dat ding mooi in zn cache te houden voor een halve minuut of iets dergelijks.

[GewoonNico]

Het is niet altijd precies 2 seconden langer. Dit is soms ook 1,5 seconde langer.
Ik zal vanmiddag even aan mn host vragen of DNS lookups aan staan

[kamerplant]

Toch lijkt het me slim om te kijken waar precies die parsetime zo enorm oploopt. Zo kom je er wellicht achter dat er iets mis gaat bij een bepaalde regel/functie, je kunt dan pas uitzoeken wat er mogelijk mis is met de server config.

[Verwijderd]

Datafeest schreef op zondag 24 april 2005 @ 11:20:
Toch lijkt het me slim om te kijken waar precies die parsetime zo enorm oploopt. Zo kom je er wellicht achter dat er iets mis gaat bij een bepaalde regel/functie, je kunt dan pas uitzoeken wat er mogelijk mis is met de server config.

Dat is dus wat ik bedoelde ja. Anders blijft het bij een vermoeden. Je moet zien te isoleren wat er de hele tijd zo traag gaat. Als je een parsetime hebt van 2 seconden, dan is er een stuk code dat erg veel tijd in beslag neemt. Zoek dat op, dan weet je op een gegeven moment exact waar je de oorzaak moet zoeken.

[Korakal]

ik denk dat dit topic inmiddels beter op z'n plaats is in P&W

[flowerp]

Datafeest schreef op zondag 24 april 2005 @ 11:20:
Toch lijkt het me slim om te kijken waar precies die parsetime zo enorm oploopt.

Het lijkt me -zeer- stug dat het de parse time is. Dat zou alleen zo zijn als je een heel grote PHP file hebt met enorm veel text erin (denk aan >500K aan text).

Het zal eerder met de execution time te maken hebben. Dingen als een onhandig algoritme, of een query die (te) veel data over stuurt, etc.

Ik zou het gewoon even met een profiler runnen. Dan krijg je een break-down te zien per functie waar de meeste execution time in gaat zitten. Zo kun je heel snel zien waar de bottle-neck precies zit.

[GewoonNico]

Wat is een profiler en hoe doe ik dit ?

[flowerp]

partypas schreef op zondag 24 april 2005 @ 21:31:
Wat is een profiler en hoe doe ik dit ?

Een profiler is een tool die iha het resource gebruik van je applicatie meet. Het meet per functie hoe lang deze er over doet, hoe vaak ie totaal wordt aangeroepen, hoeveel geheugen ie gebruikt, hoeveel van welk type objecten het meest gealloceerd wordt (application wide, en per functie) etc.

Sommige profilers kunnen direct je code meten, maar de application server moet dan wel in debug mode worden opgestart. Op je eigen local host is dat makkelijk, maar als je bij een hosting partij een server deelt met anderen (dus geen dedicated), dan is dat wat lastiger.

Andere profilers passen een process toe wat "instrumentation" heet. Je code wordt dan automatisch voorzien (injected) van meet-code.

Het is de bedoeling dat je via je profiler je code een tijdje runt, en dan pas de resultaten bekijkt. Vaak kun je ook real-time dingen in de gaten houden, zoals het huidige geheugen gebruikt.

Je moet zelf maar even zoeken naar een geschikte profiler, en daar de documentatie van lezen hoe het process bij de door jouw gekozen profiler precies verloopt.

[alienfruit]

Nou je hebt ene boel langzame queries, probeer eens te achterhalen hoe dat komt.... door: http://dev.mysql.com/doc/mysql/en/slow-query-log.html

[NMe]

Probeer eens te achterhalen welke query (of queries) zoveel tijd in beslag nemen, en post deze (of enkele ervan) dan hier. Doe je geen gekke dingen waarbij je indexes vergeet? Het feit dat je gemiddeld 40 queries per seconde hebt terwijl je site nog niet eens in de lucht is doet mij ook denken aan vrij slecht gevormde queries, tenzij je heel intensief aan het testen bent. Kun je nergens wat joins in je queries verwerken die het proces versnellen?

[GewoonNico]

Ik deel de server met anderen. Die 40 query's per seconde kunnen nooit van mij zijn. en die slow query's zijn ook niet van mij.
Waarschijnlijk zijn ze van een andere website die ook op die server draait.

De 'dikste' query die ik gebruik zal deze zijn:

PHP:

$albumq = mysql_query("SELECT p.id,a.id AS agendaid ,a.name,a.date_from,ai.id AS imageid,l.name AS locationname,l.id AS id_location,COUNT(i.id) AS numpics,COUNT(ua.id) AS nummember
                        FROM album AS p, agenda AS a, album_image AS ai, agenda_location AS l
                            LEFT JOIN album_image AS i
                                ON (p.id = i.id_album)
                            LEFT JOIN user_album AS ua
                                ON (i.id = ua.id_image)
                        WHERE a.id_site='".$_SET['id_site']."'
                        AND p.id_agenda = a.id
                        AND ai.example = '1'
                        AND ai.id_album = p.id
                        AND a.id_location = l.id
                        GROUP BY p.id
                        ORDER BY a.date_from DESC,name
                        LIMIT ".$_GET['from'].", 10") or die(mysql_error());

[ Voor 16% gewijzigd door GewoonNico op 25-04-2005 12:40 ]

[Verwijderd]

Maar ga je ook nog eens kijken wat er in praktijk zoveel tijd kost? Kun je uitsluiten dat een bepaald stukje script soms overdreven veel tijd in beslag neemt? Als je dat hebt bepaalt, dan weet je waar je het moet zoeken: in de server load of configuratie, of in je scripts.

[NMe]

Die query lijkt me eigenlijk redelijk zwaar, zeker als je indices fout staan. Overigens bestaat $_SET['id_site'] niet, en verder sta je open voor SQL injectie, maar dat heeft verder niets met snelheid te maken.

Overigens: het feit dat die grote aantallen queries niet van jou zijn, wil natuurlijk niet zeggen dat het geen invloed heeft op de snelheid van je site. Praat eens met je host, of, als het gewoon een gezamelijk eigendom is, zoek dan uit welke site zoveel queries trekt, en zorg dat diegene zijn site optimaliseert, want dit lijkt me niet echt handig.