Kuidas vähendada serveri latentsust: 8 lahendust, mis tegelikult toimivad

Viivitus on viivitus päringu ja vastuse vahel. Interaktiivsete rakenduste puhul tundub kõik, mis ületab 100 ms, aeglane, ja kui ületatakse 500 ms, hakkavad kasutajad lahkuma. See postitus käsitleb seda, mis tegelikult põhjustab suurt viivitust, kaheksat viivituse vähendamise meetodit ning seda, milliseid neist tuleks kasutada sõltuvalt teie eelarvest ja arhitektuurist.

Mis põhjustab suurt latentsust

Peaaegu kogu serveri latentsust mõjutavad kolm asja:

• Füüsiline kaugus. Valgus liigub kiudoptikas umbes kahe kolmandiku kiirusega vaakumkiirusest. Kliendi ja serveri vahelise kauguse tõttu on edasi-tagasi liikumise ajale seatud kindel piir, millest allapoole ei ole võimalik seda ühegi häälestusega viia.
• Võrgu marsruutimine. Paketid liiguvad harva lühima teekonna pidi. Nad põrkuvad transiidipakkujate, interneti vahetuspunktide ja peering-punktide vahel, millest igaüks lisab mikrosekundeid kuni millisekundeid. Halb peering võib teoreetilist miinimumit kahekordistada või kolmekordistada.
• Serveripoolne töötlemine. Kui päring on saabunud, peab server selle veel töötlema: analüüsimine, andmebaasi päringud, kettaseadme sisend-väljund, rakenduse loogika. Üksainus aeglane päring võib lisada sekundeid, mis varjutavad võrguosa täielikult.

Teadmiseks olulised ligikaudsed edasi-tagasi-aja vahemikud:

• LAN: alla 1 ms
• Sama piirkond: 10–30 ms
• Riigipiiride ületamine (USA ida-lääs): 60–80 ms
• Atlandi ületamine: 70–100 ms
• Vaikse ookeani ületamine: 130–180 ms
• Geostatsionaarne satelliit: 500 ms+ (LEO-teenused nagu Starlink: 20–50 ms)

8 viisi serveri latentsuse vähendamiseks

1. Töötlemise lähemale toomine servarvutuse abil

Äärearvutuses käivitatakse rakenduste loogika serverites, mis asuvad füüsiliselt kasutajate lähedal, mitte ühes keskandmekeskuses. Töökoormuste puhul, kus iga päring käivitab edasi-tagasi liikluse (interaktiivsed API-d, reaalajas mängud, AI järeldused), vähendab see võrguosa latentsust ühekohaliste millisekunditeni. Sobib kõige paremini ülemaailmselt hajutatud kasutajatele, kelle töökoormused on latentsusele tundlikud.

2. Salvestage sisu CDN-i

CDN salvestab staatilist ja üha enam ka dünaamilist sisu ülemaailmsetes servasõlmedes, nii et kasutajad laadivad sisu alla lähimast koopias, mitte teie algallikast. See on lihtsaim viis suure kasu saamiseks igale ülemaailmset liiklust teenindavale veebisaidile, eriti meedia, JavaScripti, CSSi ja API-vastuste puhul, mida on võimalik vahemällu salvestada. Kaasaegsed CDN-id toetavad reaalajas puhastamist ja vahemällu salvestamise reegleid, mis põhinevad päringute päistel.

3. Liikluse eraldamine privaatsete VLAN-idega

Privaatsed VLAN-id jagavad võrguliikluse isoleeritud alamvõrkudeks, nii et mitteseotud töökoormused ei jaga ühtegi leviala. Koos QoS-poliitikatega tagavad need latentsusele tundlikele teenustele (VoIP, andmebaasi replikatsioon, videokõned) ribalaiuse, sõltumata sellest, mis muud samal füüsilisel infrastruktuuril töötab. See on pigem mitme kasutaja või suure LAN-i lahendus kui ühe serveri lahendus.

4. Kriitilise liikluse prioriseerimine QoS-iga

Teenuse kvaliteedi reeglid ütlevad võrguseadmetele, millised paketid saavad ülekoormuse korral prioriteedi. Andmebaasi päringud ja API-kõned saavad kiirema liini; varukoopiad ja massiline replikatsioon saavad selle, mis jääb üle. Tõeliselt efektiivne ühendustel, mis perioodiliselt küllastuvad. Mõttetu ühendustel, mis seda kunagi ei tee.

5. Uuendage kiiremale riistvarale

Suurimad serveripoolsed võidud tulenevad mõnest komponendist:

• NVMe-salvestusruum, mis asendab SATA SSD-d, tagades 10–100 korda madalama I/O-viiteaja
• Kaasaegsed võrgukaardid, mis toetavad RSS, RDMA või DPDK-d, tagavad suure pakettide läbilaskevõime
• Piisavalt RAM-i, et hoida aktiivseid andmeid mälus ja vältida kettalt lugemist
• Protsessorid, millel on piisavalt tuumaid ja tuuma kohta piisav jõudlus, et vältida konteksti vahetamise konflikte

Õigesti konfigureeritud üksik server ületab tihti halvasti konfigureeritud klastri jõudluse.

6. Jaotage koormus serverite vahel

Koormuse tasakaalustamine jaotab päringud mitme tagapõhja vahel, nii et ükski server ei muutu pudelikaelaks. Standardalgoritmid (round-robin, vähim ühendusi, kaalutud) sobivad staatuseta teenustele; staatiliste teenuste puhul on olulised püsivad seansid. Geograafiline koormuse tasakaalustamine anycasti või GeoDNS-i kaudu suunab kasutajad lähimale töökorras serverile, vähendades RTT-d ülemaailmsele publikule.

7. Optimeerige rakendusi ja andmebaase

Sageli on see suurim võit. Tavalised kahtlusalused:

• Puuduvad või kasutamata andmebaasi indeksid
• N+1 päringumustrid ORM-i väärkasutuse tõttu
• Järjekorras I/O, kus paralleelne töötaks
• Puudub mälupuhver (Redis, Memcached) korduvate lugemiste ees
• Blokeerivad operatsioonid aktiivsetel kooditeedel

Enne optimeerimist koostage profiil. Sellised tööriistad nagu py-spy, perf või sobiv APM näitavad, kus aega tegelikult kulutatakse, mitte kus teie arvate, et seda kulutatakse.

8. Jälgige pidevalt

Sa ei saa parandada seda, mida sa ei näe. Jälgi RTT-d, pakettide kadu, jitterit ja vastusaja protsentiile (p50, p95, p99). P99 on tavaliselt koht, kus peitub halb kasutajakogemus. Tööriistad, mida tasub tunda: mtr teekonna diagnoosimiseks, smokeping trendide jälgimiseks, Prometheus ja Grafana ajaseriate jaoks ning APM (Datadog, New Relic, Sentry) rakenduse tasandi nähtavuse jaoks.

8 lähenemisviisi võrdlus

Kuidas valida sobiv variant

Valige selle järgi, millest teil on kõige vähem:

• Piiratud eelarve. Alustage rakenduste ja andmebaaside optimeerimisest, lisage seire ja seejärel ribalaiuse haldus. Need nõuavad inseneride aega, mitte infrastruktuuri.
• Piiratud inseneritöö aeg. CDN ja riistvara uuendamine annavad suurt kasu väikese seadistamisvaevaga.
• Ülemaailmselt hajutatud kasutajad. Esmalt CDN. Lisage servaarvutus osadele, mida ei saa vahemällu salvestada.
• Viivitusele tundlikud töökoormused (reaalajas mängud, kauplemine, AI järeldused). Riistvara uuendamine ja serva rakendamine koos. Ainult rakenduste nipid ei aita siin edasi.
• Juba praegu suur liiklus. Enne mis tahes muu skaleerimist peaksid koormuse jaotamine ja seire olema paigas.

Lõppmõtted

Suurim kasu tuleb kahest allikast: füüsilise vahemaa vähendamine CDN-i või servasõlmede abil ning serveripoolse ebaefektiivsuse kõrvaldamine, mis muudab 50 ms võrguviivituse 500 ms koguvastusajaks. Enamik meeskondi alahindab teist aspekti.

Viivitusele tundlike töökoormuste puhul on alusvõrk sama oluline kui peal olev kood. FDC pühendatud serverid töötavad hästi ühendatud võrgus üle 70 asukoha üle maailma, pakkudes piiramatut ribalaiust ja kaasaegset riistvara (EPYC, NVMe). See annab teile aluse, mis ei tekita pudelikaela asjades, mida koodis parandada ei saa.