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:
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
.
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
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."