[mysql/php] mysql performance probleem *

[Dwightjo]

edit:
Sorry mijn topic titel was nog niet af

mysql performance probleem ?


Ik zit met een vreemd probleem waar ik niet meer uit kom.

Probleem:
Bepaalde pagina's van een admin gedeelte van een website laden zeer traag
(Het gaat hier om een overzicht van alle transacties)

Hardware:
Amd Athlon XP 1800 GHZ
1,5 GB geheugen
normale IDE disk

Software:
Redhat 8.0 (helemaal up to date)
mysql versie: 3.23.58
php versie: 4.3.9 (pas geupdate om te kijken of dat het probleem kon oplossen)
apache: 2.0.50
------------------------------------------

Uit een mysql tabel worden alle records opgevraagt en deze worden vervolgens (als ik php nog een beetje begrijp) door php ingedeelt (maakt een berekening) Tijdens het opvragen van de records wordt er wel al een indeling gemaakt wat betreft type data (voor weergave in het overzicht)

vanaf het moment van opvragen tot weergave duurt het ongeveer 10-15 seconden. Het gaat hier momenteel om ongeveer 7500 records. De database is netjes opgemaakt alle velden bevatten een "Int", "varchar" net dat gene wat vereist is voor de waarde. (de database structuur komt ook van de externe partij af)

De persoon die dit alles heeft gebouwt kan er zo 1 2 3 geen verklaring voor geven waarom het zo lang duurt. (hij zou er verder nog naar kijken, maar hij heeft geen volledige toegang tot de server)Het zelfde software pakket (zelfde database structuur en scripts) doet het op andere servers een stuk sneller en dan praten we over bijvoorbeeld 80000 transacties in de database.

Ik heb geprobeerd mijn my.cnf van mysql aan te passen. meer geheugen toewijzen etc etc. maar dit mocht allemaal niet baten.

Ik heb rechtstreekt een query uitgevoerd op de database. Als ik bijvoorbeeld doe:

code:

select * from `transactions` where `date`> X

dan duurt het 0.20 seconden

dus dat lijkt me vrij normaal.
Toen dacht ik; dan zit het hem in mijn PHP?!

dus ik heb de laatste versie van php gepakt, vorige was gecompiled met de ingebouwde mysql support, ik heb nu de mysql van de server gebruikt. Apache herstart, maar ook dit maakt niets uit.

Als ik de stats aanpas, om bijvoorbeeld vanaf 1 november te gaan tellen. dan gaat alles wel gewoon rap.

Ik vermoed dat het ergens in een setting moet zitten, maar ik zou niet weten waar ik zou moeten zoeken. Vooral ook omdat het zelfde script op andere servers met grotere databases het wel gewoon goed doet.

Als iemand mij misschien in de juiste richting kan sturen, dan kan ik verder zoeken.
p.s. als dit niet het juiste forum ervoor is, dan mag het verplaats worden

[ Voor 3% gewijzigd door Dwightjo op 06-11-2004 08:26 . Reden: verkeerde topic titel ]

[Kees]

Ga timen, gooi een stel counters in je script, en dan kijken wat lang duurt

[ Voor 25% gewijzigd door Kees op 06-11-2004 09:33 ]

[KurtDB]

- Indexes zetten in je tabel (alhoewel dat hier de oplossing waarschijnlijk niet is)
- Alle function-calls in 'n iteratie die je ervoor kan zetten eruit filteren.
- Onnodige iteraties vermijden.
- ...

Zo zijn er wel 'n waslijstje dingen die je performance kunnen verbeteren. Ik denk dat je best Kees z'n raad opvolgt en parsetimes begint te trekken op elke instructie.

[Verwijderd]

Probeer eens je MySQL te upgraden naar 4.0, of als je al wat meer ballen hebt naar 4.1 ( is inmiddels stable verklaard maar is nog niet zooo heel lang stable, werkt hier thuis overigens perfect). Vanaf 4.0 worden queries gecached, dus als je vaak dezelfde queries uitvoert dan kan dit aanzienlijk helpen (de eerste querie is hier een factor tien langzamer dan de volgende querie die hetzelfde doet!)

Maar probeer eerst eens alles te timen met

PHP:

$begin = microtime();
$eind = microtime();
$verschil = $eind - $begin;
echo $begin;

Doet dit voor de verschillende stukken van je pagina om de bottleneck te ontdekken Post anders ook even de inhoud van je my.cnf, dan heb je iig een second opinion of je caches e.d. goed staan Probeer php eens met (even uit mijn hoofd, don't shoot the messenger) met -pipe -O3 te compilen. Kan ook nog wel eens wat schelen.

edit: Anders lezen we de volgende keer even goed. Dbase lijkt het probleem niet te zijn Dan zit er weinig op dan eerst te timen en daarna te kijken waar de evt bottlenecks zitten.

[ Voor 29% gewijzigd door Verwijderd op 06-11-2004 15:44 ]

[Dwightjo]

Bedankt voor de reply's ik was zo druk bezig met het probleem dat ik helemaal vergeten was deze thread in de gaten te houden.

mijn my.cf (samenvatting
-----------------------------
set-variable = key_buffer=256M
set-variable = record_buffer=32M
set-variable = record_rnd_buffer=32M
set-variable = sort_buffer=4M
set-variable = join_buffer=16M
set-variable = table_cache=768
set-variable = max_allowed_packet=1M
set-variable = thread_stack=128K
set-variable = max_connections=400
--------------------------------------


Inmiddels heeft de programmer het script aangepast zodat mysql alle berekeningen doet in plaats van php. resultaat: Pagina's laden verschikkelijk snel. de load die mysql op de server geeft is niet noemenswaardig toegenomen.

Toch ga ik er wel even verder naar kijken, vindt het namelijk vreemd dat andere er geen last van hebben.