Kial babilema SQL-aplikaĵo rampas tra VPN kaj kion grupigi

Formularo, kiu aperas en malpli ol sekundo en loka reto, bezonas kvin sekundojn tra VPN, dum dosiera kopio sur la sama ligo iras plenrapide. La diferenco ne estas bendlarĝo. La formularo atendas sinsekvon de respondoj kaj pagas la tutan vojaĝon ĉe ĉiu paŝo, dum la dosiera kopio tenas bajtojn konstante survoje. Nombrigu tiujn atendojn antaŭ ol tuŝi la alirlinion.

La simptomo estas ekrano, ne demando

Ĉiu demando sur tiu ekrano povas esti rapida kaj la ekrano tamen povas esti malrapida, ĉar la tuto estas la sumo de atendoj, ne la sumo de plenumaj tempoj. Deklaro, kiu ruliĝas en du milisekundoj, tamen kostas tutan vojaĝon kiam la kliento devas ricevi ĝian rezulton antaŭ ol sendi la sekvan. Sur vojo kun kvardek milisekundoj da latento, cent dependaj alvokoj sumiĝas al proksimume kvar sekundoj antaŭ ol komenciĝas ajna desegna laboro. Tiu aritmetiko estas modelo de la atendo, ne mezuro de via ligo.

Tial rapidtesto aspektas senkulpa. Amasa transigo mezuras trairon, babilema formularo mezuras latenton, kaj VPN povas esti bonega en unu kaj ordinara en la alia. Diagnozi la ekranon do signifas mezuri la ekranon anstataŭ la ligon.

Notu la tutan tempon de unu uzantoago antaŭ ol ŝanĝi ion ajn. Tiu nombro estas la sola bazlinio, kiu povas diri al vi, ĉu posta korekto funkciis.

Nombrigu sinsekvajn atendojn en unu uzantoago

Mezuru en la kliento anstataŭ diveni. En psql \timing on presas la pasintan tempon de ĉiu deklaro, kaj EXPLAIN (ANALYZE, BUFFERS) montras kiom el tiu tempo la servilo efektive elspezis por la laboro.

La breĉo inter tiuj du nombroj estas via reta kaj klienta superkosto. Se deklaro plenumiĝas en du milisekundoj kaj la kliento registras sesdek, la restantaj kvindek ok estas vojaĝo kaj loka prilaboro, kaj neniu indekso forigos ilin. Ripetu tiun komparon por ĉiu deklaro, kiun la ekrano eldonas, kaj sumu la breĉojn anstataŭ la plenumajn tempojn.

Skribu la rezulton kiel nombron de sinsekvaj atendoj. Tio estas la kvanto, kiun la sekvaj du sekcioj povas malpliigi, kaj ĝi estas nombro, pri kiu vi povas argumenti kun pruvoj.

Grupigu la sendependajn alvokojn, konservu la dependajn

Du deklaroj, kiuj ne legas la rezultojn de la alia, povas vojaĝi kune kaj esti kolektitaj unufoje, kio igas du atendojn unu. Du deklaroj, kie la dua bezonas la valoron de la unua, ne povas, ĉar la dependeco estas reala kaj grupigo ŝanĝus tion, kion la programo faras. Ordigu la alvokojn en tiujn du amasojn antaŭ ol reskribi ion ajn, kaj la grandeco de ĉiu amaso diras al vi, kio eblas.

Laboro bazita sur aroj forigas atendojn pli funde ol grupigo. Unu demando, kiu redonas la vicojn, kiujn buklo alportis unu post unu, forigas kaj la buklon kaj la vojaĝojn. Serĉu unue la buklon, ĉar ĝi kutime estas la pli granda gajno kaj la pli facila ŝanĝo por revizio.

Grupo ankoraŭ devas konservi erartrakton kaj transakciajn limojn. Kunigi neligitajn deklarojn en unu ĉenon ne estas sekura optimumigo, kaj grupo, kiu kaŝas malsukcesan deklaron malantaŭ sukcesa sendo, estas pli malbona ol la atendoj, kiujn ĝi ŝparis.

Reuzu konektojn antaŭ ol aĉeti bendlarĝon

Nova konekto kostas nomdistribuon, TCP-manpremon, TLS-negocadon kaj aŭtentikigon, kaj sur vojo de alta latento ĉiu el tiuj estas plia vojaĝo antaŭ ol ruliĝas la unua demando. Konektujoj ekzistas por pagi tiun koston unufoje por procezo anstataŭ unufoje por alvoko.

En ADO.NET, fermo aŭ forigo de kunigita konekto redonas ĝin por reuzo anstataŭ malfermi novan fizikan, do la ŝablono, kiu aspektas kiel liko, ofte estas la ĝusta uzo. Kontrolu, ke la konektujo vere estas uzata anstataŭ supozi: registru la kreon de fizikaj konektoj, aŭ observu la sesian nombron sur la servilo dum la ekrano ruliĝas. La gvidlinioj pri SQL-agado diras la samon pri malpliigo de vojaĝoj kaj grupigo de oftaj ad hoc alvokoj, kun servoespecifaj ekzemploj, kiujn vi devus mapi al via propra deplojo.

Kunigado forigas la agordan koston kaj lasas sinsekvajn demandatendojn netuŝitaj. Ĝi estas antaŭkondiĉo por pura mezuro, ne korekto per si mem.

Pripensu movi la plenumadon pli proksimen al la datumoj

Ruligi la aplikaĵon proksime al la datumbazo anstataŭigas multajn malproksimajn datumbazajn interŝanĝojn per unu malproksima ekrandosiero. Por babilema laborŝarĝo tio povas esti granda ŝanĝo, kaj ĝi estas operacia ŝanĝo same kiel agada ŝanĝo: sesia administrado, alirkontrolo, programara deplojo kaj uzanta sperto ĉiuj moviĝas kun la aplikaĵo.

Mezuru la faktan interfacon kaj la datumojn, kiujn ĝi transigas, antaŭ ol supozi, ke iu direkto estas pli rapida. Malproksima labortabla sesio movas rastrumerojn, kaj ekrano kun densa grafiko povas farti pli malbone sur la sama vojo ol la demandoj, kiujn ĝi anstataŭigis, precipe kiam la kliento senĉese redesegnas.

Poste ripetu la originan agon kaj komparu tri nombrojn: sinsekvaj atendoj, rezulta volumeno kaj finfina plenumtempo. Plibonigo, kiu ŝanĝas la mezuritan uzantoagon konservante datuman ĝustecon kaj alirpolitikon, estas tiu, kiun indas reteni.