[mysql] testen snelheid van queries/db

[HenkS]

hallo,

Ik heb een site (zie sign) en die is nogal aan het groeien...

nu hou ik ook hoevaak er naar een voertuig gezocht wordt.. en hoelang die query er over doet...

en aangezien onze db gestaagd groeit, en we meer bezoekers krijgen, neemt de query tijd ook toe....

nu hebben we een testserver en een produktieserver... al zijn ze allebij NIET dedicated.. draaien op dit moment dus ook andere sites op... de query tijden enz worden dus ook beinvloed door andere zooi op die server.

nu wil ik wat gaan spelen met de indexen, keys enz... maar ik wil echt goed kunnen meten of het resultaat heeft.... maar nu vraag ik me af hoe je dat het beste kan doen?? omdat er ook andere dingen van invloed zijn.....

ik had in gedachte:

een query in een loop (dus x of 50 uitvoeren) en die totaal tijd tellen... omdat je met 50x iets beter verschil in tijden ziet, omdat het verschil bij 1x te vaak gering is...

maar ik vraag me af of dit zinvol is, of dat iemand andere voorstellen heeft...

want ik heb wel gezocht op het woord 'optimalisatie' hier op GOT, maar dan krijg je echt vaak query gerichte problemen, of mensen die normalisatie problemen hebben..

so please help me

[whoami]

Heb je (of MySQL) geen tooltje waarmee je het execution path van een query kunt bekijken? Een explain - functie zeg maar?

Bekijk ook even dit topic:
[rml][ sql] Wat is sneller? Select * of Select , , ...[/rml]

en bekijk ook even deze:

[rml][ sql] forum query's verbeteren.[/rml]
PL/SQL performance subqueries of hulptabellen
[rml][ mysql] Optimalisatie hulp.[/rml]
[rml][ Stored Procedures] Redenen gebruik Stored Proc.[/rml]
wat is beter: losse queries of in elkaar gevlegt q
[rml][ mysql] Optimaliseren van[/rml]

Je zegt dus wel dat je gesearched hebt, maar ik kan me toch niet van de indruk ontdoen dat dit niet het geval is....

[GarBaGe]

idd, gewoon ff de mysql client gebruiken om de queries via een commandline uit te voeren. Dan krijg je gelijk de tijd gedisplayed die het heeft gekost om de query uit te voeren

[cameodski]

50 keer dezelfde query uitvoeren, is helaas geen goede methode om te testen of je performance deugt. Als een tabel bijvoorbeeld 1000 records bevat, wil dat niet zeggen dat ie dan alles 50 keer zo snel doet als wanneer die 50000 records bevat.

Er zijn wel een aantal andere mogelijkheden om aan je performance te werken:
- wachten tot er veel data in je produktieserver zit, zodat eventuele performance problemen vanzelf naar boven komen
- testdata genereren
- je verdiepen in het effect van bepaalde indexen e.d. en op basis daarvan indexen toevoegen

Persoonlijk geef ik de voorkeur aan een combinatie, namelijk de laatste twee.

[HenkS]

ja testdata heb ik

en die indexen heb ik me ook in verdiept , maar wil dus mijn veranderingen die ik ga uitvoeren, willen meten of ze nuttig zijn

[whoami]

HenkS schreef op 25 september 2002 @ 09:53:
ja testdata heb ik

en die indexen heb ik me ook in verdiept , maar wil dus mijn veranderingen die ik ga uitvoeren, willen meten of ze nuttig zijn

Het execution path van de query bekijken dus... Daarin kun je zien welke indexen de query gebruikt etc...

[cameodski]

HenkS schreef op 25 september 2002 @ 09:53:
ja testdata heb ik

en die indexen heb ik me ook in verdiept , maar wil dus mijn veranderingen die ik ga uitvoeren, willen meten of ze nuttig zijn

OK, dan hoef je er alleen nog maar voor te zorgen dat je voldoende testdata hebt om verschil te merken. En dan kun je dus aan het meten gaan.

[Crazy D]

Behalve eerder genoemde tips is het imho soms ook een kwestie van logisch denken: als ik weet dat er in mijn artikelbestand zeer regelmatig gezocht wordt met als criteria dat de artikelgroep een bepaalde groep moet zijn en verkoopprijs groter dan een x-bedrag, dan hou ik iig alvast in mn achterhoofd dat die velden weleens intressant kunnen zijn om een index op aan te leggen.

En uiteraard testen met een goed gevulde database, niet 10 keer een test van 100 keer eenzelfde querie, maar af en toe criteria wijzigen, indien mogelijk ook kijken wat er gebeurt als de tabel 2 keer zo vol is, dat soort dingen.