Site traag door vele records
Beste mensen,
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.
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
Hoe staan de indexen op je tabel?
En waar draai je deze website?
En wat gebeurt er verder aan query's etc.
En waar draai je deze website?
En wat gebeurt er verder aan query's etc.
Hoe zijn de indexen?
Index op ID, site draait op server in amsterdam, niet shared, gewoon een rack.
@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
@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...
ik heb alleen een totale meting..
Pagina laadtijd: 10.5259 seconden - 179.6328125 Kb's in memory gebruikt
He ga ik dat per query oplossen???
Pagina laadtijd: 10.5259 seconden - 179.6328125 Kb's in memory gebruikt
He ga ik dat per query oplossen???
een index op wedstrijd_id lijkt mij ook handig.
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.
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.
Ff een deel van het script (ingekort uiteraard, hier en daar voorzien van de benodigde comments)
(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!
(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
Gebruik EXPLAIN om te achterhalen hoe de query wordt uitgevoerd en welke indexen er worden gebruikt. Ga vervolgens de boel optimaliseren.
250.000 records stelt op zich niet veel voor, tenzij je enkele GB's per record hebt opgeslagen...
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!
Dan is jouw datamodel waarschijnlijk niet goed, wedstrijd_id klinkt echt als het id in de tabel wedstrijd, wat een primary key zal zijn, en waar je dus een foreign key op hebt staan. Je hebt toch wel een FK vanuit je tabel "Tabel1" naar de wedstrijden staan? Dan zou er al een index moeten zijn en had je deze niet met de hand aan hoeven maken. Ik gok er dan ook zo op dat je een fout in de database hebt zitten.
Uiteraard zorgen indexen voor grote verbeteringen, een verbetering met een factor 1000 is niks bijzonders.
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.
Okee jij je zin. De structuur was er, de werking was er, alleen het plakband dat schudden en lekken moeilijker maakt zat er nog niet opgeplakt.
Dat je geen relatie aanmaakt in de database lijkt mij overigens niet een fout in je datamodel, eerder in de implementatie ervan.
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.




