Site traag door vele records
Ik ben de afgelopen tijd met een website bezig, alleen nu is het zo ongelofelijk druk geworden dat het laden van reacties op foto's erg lang duurt. Soms wel meer dan 10 seconden voor het laden van een pagina. Het gaat om www.wineenfotoshoot.nl, en dan de contestfoto's.
Voorbeeld:
http://www.wineenfotoshoot.nl/profiel.php?onderdeel=wedstrijd_profiel&wedstrijd_id=13051
Eerst worden alle bijbehorende reacties geteld, i.v.m. paginanummering. Daarna haal ik alle data eruit. Echter is het zo dat er in 250.000 reacties moet worden gezocht daarvoor. Hoe kam ik de snelheid optimaliseren??
Huidige query (aangepaste tabel-/veldnamen):
SELECT profiel_id, reactie, naam, id, DATE_FORMAT(datum, '%d-%m-%y @ %H:%i') AS post_date FROM Tabel1 WHERE wedstrijd_id = {$wedstrijd_id} ORDER BY id DESC LIMIT {$start},{$aantal}
Bij voorbaad dank!
PS. Zitten nu rond 2 pageviews per seconde, dus optimalisatie is ect belangrijk op moment.
Gewijzigd op 01/01/1970 01:00:00 door Bas Matthee
En waar draai je deze website?
En wat gebeurt er verder aan query's etc.
Hoe zijn de indexen?
@TJVB:
Wat bedoal je met wat gebeurt er verder aan de query's?
Aan de hand van de profiel_id, haal ik de profielfoto_id op, waarmee ik de foto ophaal ut de foto tabel
We kunnen er vanuit gaan dat er meerdere querys uitgevoerd worden. Word er nog iets van gebenchmarkt? Ik kan (met mijn framework) eenvoudig een parameter aanslingeren om een lijst te krijgen van iedere query die word uitgevoerd en hoeveel microseconden daarover werd gedaan...
Pagina laadtijd: 10.5259 seconden - 179.6328125 Kb's in memory gebruikt
He ga ik dat per query oplossen???
Wat ik bedoel met verder aan query's is dat ik nog wel eens scripts zie die al een heleboel query's uitvoeren en de schuld dan wordt gegeven aan één query terwijl die dan maar een deel van het probleem is.
Kun je eventueel je data model met alle keys/indexen laten zien. Misschien zijn er meerdere plekken waar een index handig kan zijn.
Verder is het handig om de tijden van de verschillende onderdelen te loggen en vergelijken.
Tevens kun je ook gaan kijken naar het caching van gegevens.
(code heb ik verwijderd, is niet meer relevant)
EDIT:
Volgens mij heb ik het opgelost, ik was bezg met het maken van screens in phpmyadmin, toen mijn oog viel op een dubbele melding van myadmin. ik had 3 indexen op id staan :S, hoe dat gebeurd is weet ik ook niet...
iig bedankt!
Gewijzigd op 01/01/1970 01:00:00 door Bas Matthee
250.000 records stelt op zich niet veel voor, tenzij je enkele GB's per record hebt opgeslagen...
Ik heb alsnog een index op wedstrijd_id gezet, en stond hersteld van de snelheidswinst! Bedankt voor de tip!
Uiteraard zorgen indexen voor grote verbeteringen, een verbetering met een factor 1000 is niks bijzonders.
Hij haalde records met foto's uit de database, en koos de foto's die hij moest hebben op wedstrijd_id. Je kan meerdere foto's per wedstrijd hebben maar maar één wedstrijd per foto, dus volgens mij klopt het wel :)
Volgens mij niet, wanneer je een foreign key op wedstrijd_id hebt staan, wat in een relationele database noodzakelijk is, heb je al een index op deze kolom staan. Er moest handmatig een index worden aangemaakt, de index (en dus de FK) ontbrak blijkbaar. Het lijkt me dan ook sterk dat er sprake is van een relationele database.
Dat je geen relatie aanmaakt in de database lijkt mij overigens niet een fout in je datamodel, eerder in de implementatie ervan.
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
Hij heeft het over phpmyadmin oftewel mysql, en dan zou het me niet verbazen als die MyISAM gebruikt. Dat maakt het hebben van een FK onmogelijk. Maar de FK's was ook een reden om naar het datamodel te vragen, als ze daarin aangegeven zijn is de kans al weer groter dat ze geplaatst zijn.