Review overzicht is "traag"

[GrooV]

Vaak lees ik wel eens ergens dat tweakers.net de webpagina's onder de 0,1 seconden probeert te laden. Dat is natuurlijk een goed streven! Klikte ik toevallig op het review overzicht (http://tweakers.net/produ...g&orderSort=desc&page=121) en toen had ik het gevoel dat die pagina erg traag laadde (eerst eigen internet controleren natuurlijk ) maar dat bleek het niet te zijn.

Die pagina duurde ongeveer 0,7-0,8 seconden. Aangezien jullie altijd alles zo snel mogelijk willen hebben, dacht ik hey ik meldt het even!

[GlowMouse]

Zal wel met LIMIT werken. Als je weet dat het er 12.319 zijn, kun je de sortering in de database omdraaien (dan krijg je LIMIT 219,100 voor resultaten 12.001 t/m 12.100) en dan in de code nog een keer omdraaien. En daarnaast kun je proberen eerst de reviewId's uit een covering index te halen en pas met die id's de joins uit te voeren.
_{heb wel iets vergelijkbaars meegemaakt}

[NMe]

Ik vind eigenlijk dat het nog steeds behoorlijk rap gaat voor een overzicht (en dus een query) dat zo op het oog een usertabel (320.000+ records), een reviewtabel (12.319 records) en een productentabel (63.039 + 83.386 records) met elkaar joint en waarschijnlijk nog wat dingetjes groupt onder water.

Overigens zou een limit toch niet uit mogen maken? Het snelheidsverschil zit hem daarbij in het doorgeven van de data, niet het ophalen ervan omdat onder water nog altijd de hele resultset opgehaald wordt alvorens de LIMIT eroverheen gaat.

[GlowMouse]

NMe schreef op maandag 05 oktober 2009 @ 01:26:
Overigens zou een limit toch niet uit mogen maken? Het snelheidsverschil zit hem daarbij in het doorgeven van de data, niet het ophalen ervan omdat onder water nog altijd de hele resultset opgehaald wordt alvorens de LIMIT eroverheen gaat.

Nee, LIMIT stopt direct als de nodige rijen zijn opgehaald. Als je de tabel waar je de andere tabellen op joint dus goed kunt sorteren, is LIMIT heel effectief op de eerste paar pagina's.

[ACM]

GrooV schreef op maandag 05 oktober 2009 @ 01:05:
Die pagina duurde ongeveer 0,7-0,8 seconden. Aangezien jullie altijd alles zo snel mogelijk willen hebben, dacht ik hey ik meldt het even!

Dat weten we, maar bij deze specifieke sorteringsvariant hebben we geen goed idee hoe we hem sneller kunnen maken, zonder het structureel anders aan te pakken.

GlowMouse schreef op maandag 05 oktober 2009 @ 01:13:
Zal wel met LIMIT werken. Als je weet dat het er 12.319 zijn, kun je de sortering in de database omdraaien (dan krijg je LIMIT 219,100 voor resultaten 12.001 t/m 12.100) en dan in de code nog een keer omdraaien. En daarnaast kun je proberen eerst de reviewId's uit een covering index te halen en pas met die id's de joins uit te voeren.

Dat kan je natuurlijk vrij simpel controleren of het daar aan ligt door de snelheid van de laatste pagina met de eerste te vergelijken. En dan zie je dat het bij deze weinig uit maakt. Het gaat hier specifiek om de sortering op waardering, die wordt namelijk on-the-fly berekend.
En aangezien deze pagina vrij weinig opgevraagd wordt, en nog vrij vlot laadt, en dit de enige plek is waar zoveel waarderingen tegelijk uitgerekend worden, hebben we er verder nog geen moeite in gestoken het structureel anders aan te pakken.

GlowMouse schreef op maandag 05 oktober 2009 @ 01:43:
Nee, LIMIT stopt direct als de nodige rijen zijn opgehaald. Als je de tabel waar je de andere tabellen op joint dus goed kunt sorteren, is LIMIT heel effectief op de eerste paar pagina's.

Bij sorteringen op tijd en naam enzo gaat dat idd prima. Maar bij waardering dus niet.

[crisp]

no need to fix dus