Contact met ondersteuning

Wij antwoorden per e-mail, meestal binnen twee dagen.

Google reCAPTCHA controleert deze inzending op misbruik; daarbij worden gegevens naar Google gestuurd. Het script laadt pas wanneer dit formulier wordt geopend.

← Alle berichten

Wanneer een index toevoegen het trager maakt

De tabel met dagcijfers heeft één sleutel: de teller en de datum samen. Vijf plaatsen in de code stellen haar een andere vraag — niet "deze teller door de tijd" maar "alle tellers op deze datums". De galerie op de voorpagina, de toplijst, de sitemap, een grafiek over 90 dagen, en de statuscijfers. Zonder index op de datumkolom leest elk daarvan alle 114.113 regels.

Die index toevoegen maakt de galerie tien keer sneller. Hij is niet toegevoegd. Hier is de meting die dat besliste.

galerie, één dag — 61,5 naar 6,1 ms toplijst, 30 dagen — 88,6 naar 89,2 ms sitemap, 14 dagen — 79,6 naar 94,8 ms grafiek over 90 dagen — 120,0 naar 109,2 ms statuscijfers, 365 dagen — 204,9 naar 225,1 ms bovenste staaf zonder de index, onderste staaf ermee samen: 555 ms wordt 524 ms

Eén bevraging werd veel sneller

De galerie vraagt naar de tellers die vandaag actief waren. Zonder index op de datum doorloopt ze de hele tabel; met een index zoekt ze één datum op en leest 443 regels. 61,5 milliseconden werd 6,1. Dat is geen subtiele uitkomst, en was het het enige geweest dat gemeten werd, dan stond de index nu in de database.

Twee bevragingen werden trager

De sitemap vraagt om veertien dagen en werd 19% trager. De statuscijfers vragen om een jaar en werden 10% trager. In beide gevallen stapte de planner van de primaire sleutel over op de nieuwe index en maakte een slechtere keuze.

Dit is het deel dat begrip verdient, want het is geen fout in de planner. Een bereik door een secundaire index lezen betekent de passende regels in de index vinden en ze daarna stuk voor stuk uit de tabel halen. Voor een smalle plak is dat koopje. Voor veertien dagen uit dertien maanden zijn het nog steeds veel regels die één voor één worden opgehaald, en een rechttoe rechtaan doorloop van de tabel — hem in fysieke volgorde lezen, en dat is wat schijven en caches prettig vinden — wint het daarvan. De planner weet dat niet. Hij ziet een bereik en een index en neemt hem.

Er is geen manier om te zeggen "gebruik deze index alleen voor de galerie". Een index is beschikbaar voor elke bevraging die de kolom aanraakt, en de planner gebruikt hem overal waar zijn schattingen zeggen dat hij dat moet. Er een toevoegen is een wijziging aan elke bevraging op die tabel, niet alleen aan de bevraging waarvoor hij bedoeld was.

Samen: niets

Over alle vijf werd 555 milliseconden 524. Een verbetering van 1,1×, en op een kleine server die deze pagina's toch uit een cache bedient, is dat geen wijziging aan het schema waard.

De grafiek over 90 dagen lijkt 9% verbeterd. Hij telt niet mee, en het is de moeite waard te zeggen waarom. Elke bevraging is drie keer gemeten: zonder de index, ermee, en dan weer zonder. Komt de tweede ronde zonder index niet in de buurt van de eerste, dan was het verschil de machine en niet de wijziging. Bij de grafiek over 90 dagen verschilden de twee rondes zonder index 13,8% — meer dan het effect dat beweerd wordt. Die regel meet dus niets, en ze wordt als niets gemeld.

Hoe dit gemeten is, en waarom dat uitmaakt

Niet op de levende tabel. Het script kopieert hem, werkt op de kopie, en gooit de kopie aan het eind weg. Een index aan een productietabel toevoegen om te zien wat er gebeurt, werkt maar één keer per verrassing.

De bevragingen zijn de echte, uit de code gelicht, inclusief de koppeling naar de tellertabel. Een eerdere versie van deze proef gebruikte een vereenvoudigde plaatsvervanger en leverde een veel spannender antwoord op: twintig keer sneller. Die vereenvoudigde bevraging was er geen die iets werkelijk draait.

Wat het getal geweest zou zijn

Was dit op de gewone manier gemeten — neem de bevraging die traag aanvoelt, klok hem voor en na — dan was het antwoord "tien keer sneller, doen" geweest. De index zou erin gegaan zijn, de galerie zou sneller geworden zijn, de sitemap en de statuspagina zouden trager geworden zijn, en niemand zou die twee met elkaar verbonden hebben, want niemand keek daarnaar.

Dat is de algemene vorm ervan. Een wijziging aan gedeelde infrastructuur is niet te beoordelen op het geval dat haar motiveerde. De vraag is niet "helpt dit het ding waar ik naar kijk" maar "wat raakt dit nog meer aan, en wat gebeurt daarmee".

Er is een versie die zou kunnen werken: een index die beide kolommen draagt, datum eerst, zodat de galerie uit de index alleen beantwoord kan worden zonder terug naar de tabel te gaan. Misschien verleidt hij de planner ook niet bij de bredere bereiken. Dat is niet gemeten, dus het is geen aanbeveling — het is het volgende om op de kopie te zetten.

Advertentie