Hoekom 'n kletserige SQL-toepassing oor 'n VPN kruip en wat om te bondel

'n Vorm wat op 'n LAN in minder as 'n sekonde vertoon, neem oor 'n VPN vyf sekondes, terwyl 'n lêerkopie op dieselfde skakel teen volle spoed loop. Die verskil is nie bandwydte nie. Die vorm wag vir 'n reeks antwoorde en betaal die volle retoer op elke stap, terwyl die lêerkopie grepe deurlopend in die lug hou. Tel daardie wagtye voordat jy aan die toegangslyn raak.

Die simptoom is 'n skerm, nie 'n navraag nie

Elke navraag op daardie skerm kan vinnig wees en die skerm kan steeds stadig wees, want die totaal is die som van wagtye eerder as die som van uitvoeringstye. 'n Verklaring wat in twee millisekondes loop, kos steeds 'n volle retoer wanneer die kliënt die resultaat moet ontvang voordat hy die volgende een stuur. Op 'n pad met veertig millisekondes se latensie beloop honderd afhanklike oproepe ongeveer vier sekondes voordat enige vertoonwerk plaasvind. Die rekenkunde is 'n model van die wag, nie 'n maatstaf van jou skakel nie.

Dit is hoekom 'n spoedtoets onskuldig lyk. Grootmaat-oordrag meet deurset, 'n kletserige vorm meet latensie, en 'n VPN kan uitstekend wees in die een terwyl dit gewoon bly in die ander. Om die skerm te diagnoseer beteken dus om die skerm te meet eerder as die skakel.

Teken die end-tot-end tyd van een gebruikersaksie aan voordat jy enigiets verander. Daardie getal is die enigste basislyn wat jou kan sê of 'n latere regstelling gewerk het.

Tel opeenvolgende wagtye in een gebruikersaksie

Instrumenteer die kliënt eerder as om te raai. In psql druk \timing on die verstreke tyd van elke verklaring, en EXPLAIN (ANALYZE, BUFFERS) wys hoeveel van daardie tyd die bediener werklik aan die werk bestee het.

Die gaping tussen daardie twee getalle is jou netwerk- en kliëntoorhoof. As 'n verklaring in twee millisekondes uitgevoer word en die kliënt teken sestig aan, is die oorblywende agt-en-vyftig reis en plaaslike verwerking, en geen indeks sal dit verwyder nie. Herhaal daardie vergelyking vir elke verklaring wat die skerm uitstuur en tel die gapings op eerder as die uitvoeringstye.

Skryf die resultaat neer as 'n telling van opeenvolgende wagtye. Dit is die hoeveelheid wat die volgende twee afdelings kan verminder, en dit is 'n getal waaroor jy met bewyse kan redeneer.

Bondel die onafhanklike oproepe, hou die afhanklike een

Twee verklarings wat nie mekaar se resultate lees nie, kan saam reis en een keer ingesamel word, wat twee wagtye in een verander. Twee verklarings waar die tweede die waarde van die eerste nodig het, kan nie, want die afhanklikheid is eg en om dit te bondel sou verander wat die program doen. Sorteer die oproepe in daardie twee hope voordat jy enigiets herskryf, en die grootte van elke hoop sê vir jou wat moontlik is.

Versamelingsgebaseerde werk verwyder wagtye grondiger as bondeling. Een navraag wat die rye teruggee wat 'n lus een op 'n keer opgehaal het, elimineer die lus sowel as die retoere. Soek eerste na die lus, want dit is gewoonlik die groter wins en die makliker verandering om na te gaan.

'n Bondel moet steeds foutafhandeling en transaksiegrense bewaar. Om onverwante verklarings in een string saam te voeg is nie 'n veilige optimalisering nie, en 'n bondel wat 'n mislukte verklaring agter 'n suksesvolle indiening wegsteek, is erger as die wagtye wat dit bespaar het.

Herbruik verbindings voordat jy bandwydte koop

'n Nuwe verbinding kos naamresolusie, 'n TCP-handdruk, TLS-onderhandeling en verifikasie, en op 'n pad met hoë latensie is elkeen van daardie nog 'n retoer voordat die eerste navraag loop. Verbindingspoele bestaan om daardie koste een keer per proses te betaal eerder as een keer per oproep.

In ADO.NET gee die sluit of wegdoen van 'n gepoelde verbinding dit terug vir hergebruik in plaas daarvan om 'n nuwe fisiese een te open, so die patroon wat soos 'n lek lyk, is dikwels die korrekte gebruik. Verifieer dat die poel werklik in gebruik is eerder as om dit te aanvaar: teken die skepping van fisiese verbindings aan, of hou die sessietelling op die bediener dop terwyl die skerm loop. Die SQL-prestasieriglyne maak dieselfde punt oor die vermindering van retoere en die bondeling van gereelde ad hoc-oproepe, met diensspesifieke voorbeelde wat jy op jou eie ontplooiing moet toepas.

Poeling verwyder opstellingskoste en laat opeenvolgende navraagwagtye onaangeraak. Dit is 'n voorvereiste vir 'n skoon meting eerder as 'n regstelling op sigself.

Weeg dit op om uitvoering nader aan die data te skuif

Om die toepassing naby die databasis te laat loop, vervang baie afgeleë databasis-uitruilings met 'n enkele afgeleë vertoonsessie. Vir 'n kletserige werklading kan dit 'n groot verandering wees, en dit is 'n operasionele verandering net soveel as 'n prestasie-een: sessiebestuur, toegangsbeheer, sagteware-ontplooiing en gebruikerservaring beweeg almal saam met die toepassing.

Meet die werklike koppelvlak en die data wat dit oordra voordat jy aanvaar dat enige rigting vinniger is. 'n Afgeleë lessenaarsessie beweeg pixels, en 'n skerm met digte grafika kan oor dieselfde pad swakker presteer as die navrae wat dit vervang het, veral wanneer die kliënt deurlopend herteken.

Herhaal dan die oorspronklike aksie en vergelyk drie getalle: opeenvolgende wagtye, resultaatvolume en end-tot-end voltooiingstyd. 'n Verbetering wat die gemete gebruikerstaak verander terwyl dit datakorrektheid en toegangsbeleid bewaar, is die een wat die moeite werd is om te hou.