[mysql] Aanvaardbaar aantal queries per pagina

Pagina: 1
Acties:

  • Reveller
  • Registratie: Augustus 2002
  • Laatst online: 05-12-2022
Een paar dagen geleden plaatste ik de post [PHP/MySQL] Teveel queries bij recursieve functie op GoT.

In het kort:

+ Ik bouw nu een veilingsite, waar op sommige pagina's een cookie crumb trail komt (zoals computers > desktops > Compaq > Pressario).
+ Mijn database tabel en bijbehorende recursieve functie zijn gebouwd volgens het Adjacency List model:

code:
1
2
3
4
5
6
7
8
9
---+--------+-------+
id | parent | title |
---+--------+-------+
 1 |        | root  |
---+--------+-------+
 2 | 1      | eten  |
---+--------+-------+

etc.


Het probleem hierbij is dat ik al snel 8 queries nodig heb om alleen:

+ de children van de gevraagde categorie weer te geven
+ de trail te bouwen

Ik maak me hier wat druk over, omdat ik voorzie dat wanneer de site zo'n beetje af is, ik plm. 20 queries per pagina nodig heb om deze, inclusief "nieuwe producten", "meest populaire categorien" etc. weer te geven.

Natuurlijk kan ik die queries of hun output cachen. Ik ken de mogelijkheden. Ook kan ik de extra queries van de trail ondervangen door gebruik te maken van Modified Preorder Tree Traversal - ik ben hier al mee bezig en ben erg enthousiast. Maar cachen moet geen vervanger zijn voor inefficient programmeren.

Vandaar dat mijn topic gaat over de vraag:

+ wat vind jij een aanvaarbaar aantal queries per pagina?

Ik stel hem omdat ik weinig ervaring heb met het opzetten van een site met een verwacht bezoekersaantal als deze (als ik de opdrachtgever mag geloven ;)) - heb tot nu toe alleen MKB sitejes gemaakt waarbij een query meer of minder weinig uitmaakt (want maar enkele bezoekers per dag dus lage serverload).

Je moet het aantal queries dus icm. bezoekers beschouwen: als ik bij mij lokaal een pagina draai die 200 queries afvuurt, heb ik nog maar een parsetime van 0.1 seconden ofzo. De vraag is alleen: in hoe verre en hoe snel gaat deze parsetime achteruit wanneer ik 100 concurrent users heb? Zijn hier goede benchmarks van (ik gebruik mysql)?

Ik heb gelezen dat bijna alle *nukes tot wel 50 queries per pagina kunnen gaan, en las op een ander forum (even vergeten welke) een post van iemand wiens indexpagina 168 queries afvuurde (!!)

Graag hoor ik jullie reakties, omdat het mij erg zou helpen bij de verdere ontwikkeling van dit ding :).

[ Voor 15% gewijzigd door Reveller op 02-01-2004 17:24 ]

"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."


  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 13:28

gorgi_19

Kruimeltjes zijn weer op :9

Een heel kort antwoord te geven:

Desnoods zijn het er 10.000 per pagina. Je moet niet kijken naar het aantal queries, maar naar de tijd dat het duurt dat een pagina opgebouwd wordt, oftewel de totale parsetime.

Om het nog lastiger te maken; het kan sneller zijn om 2 queries te gebruiken dan 1. :)
Maar cachen moet geen vervanger zijn voor inefficient programmeren.
Nee, maar je moet ook niet proberen om alles efficient te maken; dat is zonde van je tijd. Als ik me goed herinner maakt 20% van je code 80% van je totale executietijd uit. Op deze 20% moet je je richten. :) En er is niets mis met cachen; als je ziet hoeveel ik een cache gebruik / misbruik, om performanceredenen... Het enige nadeel is dat mijn applicatie het niet leuk gaat vinden als ik in een webfarm moet gaan opereren, maar daar is toch geen sprake van. :)
De vraag is alleen: in hoe verre en hoe snel gaat deze parsetime achteruit wanneer ik 100 concurrent users heb? Zijn hier goede benchmarks van (ik gebruik mysql)?
Dit zijn stresstesten, die je kan uitvoeren om zo een bepaalde load te simuleren. Microsoft heet een Microsoft Application Center Test gemaakt, welke gratis te downloaden is. Hiermee kan je een bepaalde belasting simuleren.

[ Voor 93% gewijzigd door gorgi_19 op 02-01-2004 17:30 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo


  • Skaah
  • Registratie: Juni 2001
  • Niet online
Voor http://www.granaet.nl/ voer ik ongeveer 15 queries per pagina uit. Daar zit dan een (phpBB)forumtracker bij, een lijstje met laatste toevoegingen, statistieken over bezoekers, settings voor de site uit de database en vrij veel recusieve functies. De site draait echter prima op zjin dual PIII-500. De bandbreedte is (veel) eerder het probleem. Ik schaar mij achter gorgi_19. Zolang het renderen van een pagina korter duurt dan 0,3s voor de gebruiker is het aanvaardbaar.