Përse një aplikacion SQL llafazan zvarritet përmes VPN-së dhe çfarë duhet grupuar

Një formular që hapet në më pak se një sekondë në një rrjet lokal kërkon pesë sekonda përmes VPN-së, ndërsa një kopje skedari në të njëjtën linjë shkon me shpejtësi të plotë. Diferenca nuk është gjerësia e brezit. Formulari pret një sekuencë përgjigjesh dhe paguan udhëtimin e plotë vajtje-ardhje në çdo hap, ndërsa kopja e skedarit i mban bajtët vazhdimisht në fluturim. Numëroni ato pritje përpara se të prekni linjën e aksesit.

Simptoma është një ekran, jo një kërkesë

Çdo kërkesë në atë ekran mund të jetë e shpejtë dhe ekrani mund të jetë ende i ngadaltë, sepse totali është shuma e pritjeve dhe jo shuma e kohërave të ekzekutimit. Një deklaratë që ekzekutohet për dy milisekonda kushton ende një udhëtim të plotë kur klienti duhet të marrë rezultatin përpara se të dërgojë tjetrin. Në një rrugë me vonesë dyzet milisekonda, njëqind thirrje të varura mblidhen në rreth katër sekonda përpara se të fillojë çdo punë vizatimi. Kjo aritmetikë është një model i pritjes, jo një matje e linjës tuaj.

Kjo është arsyeja pse një test shpejtësie duket i pafajshëm. Transferimi masiv mat qarkullimin, një formular llafazan mat vonesën, dhe një VPN mund të jetë e shkëlqyer në njërën dhe të mbetet e zakonshme në tjetrën. Prandaj diagnostikimi i ekranit do të thotë të matësh ekranin dhe jo linjën.

Regjistroni kohën nga fillimi në fund të një veprimi të përdoruesit përpara se të ndryshoni gjë. Ai numër është i vetmi bazë që mund t'ju thotë nëse një rregullim i mëvonshëm funksionoi.

Numëroni pritjet sekuenciale në një veprim të përdoruesit

Instrumentoni klientin në vend që të hamendësoni. Në psql, \timing on shtyp kohën e kaluar të çdo deklarate, dhe EXPLAIN (ANALYZE, BUFFERS) tregon sa nga ajo kohë serveri e kaloi vërtet në punë.

Hendeku midis këtyre dy numrave është kostoja juaj e rrjetit dhe e klientit. Nëse një deklaratë ekzekutohet për dy milisekonda dhe klienti regjistron gjashtëdhjetë, pesëdhjetë e tetë të mbeturat janë udhëtim dhe përpunim lokal, dhe asnjë indeks nuk do t'i heqë. Përsëriteni këtë krahasim për çdo deklaratë që lëshon ekrani dhe mblidhni hendekët, jo kohët e ekzekutimit.

Shkruajeni rezultatin si numërim i pritjeve sekuenciale. Kjo është sasia që dy seksionet e ardhshme mund të zvogëlojnë, dhe është një numër për të cilin mund të debatosh me prova.

Gruponi thirrjet e pavarura, mbani ato të varurat

Dy deklarata që nuk lexojnë rezultatin e njëra-tjetrës mund të udhëtojnë bashkë dhe të mblidhen një herë, gjë që i kthen dy pritje në një. Dy deklarata ku e dyta ka nevojë për vlerën e së parës nuk mundet, sepse varësia është e vërtetë dhe grupimi do të ndryshonte atë që bën programi. Ndajini thirrjet në ato dy grumbuj përpara se të rishkruani gjë, dhe madhësia e çdo grumbulli ju tregon çfarë është e mundur.

Puna mbi bashkësi i heq pritjet më tërësisht se grupimi. Një kërkesë që kthen rreshtat që një cikël i merrte një nga një eliminon ciklin si dhe udhëtimet. Kërkoni fillimisht ciklin, sepse zakonisht është fitimi më i madh dhe ndryshimi më i lehtë për t'u rishikuar.

Një grup ende duhet të ruajë trajtimin e gabimeve dhe kufijtë e transaksioneve. Bashkimi i deklaratave të palidhura në një varg të vetëm nuk është optimizim i sigurt, dhe një grup që fsheh një deklaratë të dështuar pas një dërgimi të suksesshëm është më keq se pritjet që kurseu.

Ripërdorni lidhjet përpara se të blini gjerësi brezi

Një lidhje e re kushton zgjidhje emri, shtrëngim duarsh TCP, negociim TLS dhe vërtetim, dhe në një rrugë me vonesë të lartë secili prej tyre është një udhëtim tjetër përpara se të ekzekutohet kërkesa e parë. Pishinat e lidhjeve ekzistojnë për ta paguar atë kosto një herë për proces dhe jo një herë për thirrje.

Në ADO.NET, mbyllja ose dispose e një lidhjeje të pishinuar e kthen atë për ripërdorim në vend që të hapë një lidhje të re fizike, prandaj modeli që duket si rrjedhje është shpesh përdorimi i saktë. Verifikoni se pishina është vërtet në përdorim në vend që ta supozoni: regjistroni krijimin e lidhjeve fizike, ose vëzhgoni numrin e sesioneve në server ndërsa ekrani punon. Udhëzimet për performancën e SQL thonë të njëjtën gjë për zvogëlimin e udhëtimeve dhe grupimin e thirrjeve të shpeshta ad hoc, me shembuj specifikë për shërbimin që duhet t'i hartëzoni në vendosjen tuaj.

Pishinimi heq koston e konfigurimit dhe i lë pritjet sekuenciale të kërkesave të paprekura. Është parakusht për një matje të pastër, jo një rregullim më vete.

Pesho zhvendosjen e ekzekutimit më pranë të dhënave

Ekzekutimi i aplikacionit pranë bazës së të dhënave zëvendëson shumë shkëmbime të largëta me bazën me një sesion të vetëm të largët shfaqjeje. Për një ngarkesë llafazane kjo mund të jetë një ndryshim i madh, dhe është një ndryshim operativ po aq sa një ndryshim performance: menaxhimi i sesioneve, kontrolli i aksesit, vendosja e softuerit dhe përvoja e përdoruesit lëvizin të gjitha bashkë me aplikacionin.

Matni ndërfaqen reale dhe të dhënat që transferon përpara se të supozoni se ndonjë drejtim është më i shpejtë. Një sesion desktop i largët lëviz pikselë, dhe një ekran me grafikë të dendur mund të performojë më keq në të njëjtën rrugë se kërkesat që zëvendësoi, veçanërisht kur klienti rivizaton vazhdimisht.

Më pas përsëritni veprimin origjinal dhe krahasoni tre numra: pritje sekuenciale, vëllim rezultati dhe kohë përfundimi nga fillimi në fund. Një përmirësim që ndryshon detyrën e matur të përdoruesit duke ruajtur saktësinë e të dhënave dhe politikën e aksesit është ai që vlen të mbahet.