TCP_NODELAY ja AI: vähem latentsust SaaS-ile

Latentsus ei tapa toodet dramaatiliselt. Ta teeb seda vaikselt.

Kui kasutaja Telliskivis avab sõidujagamise äpi ja kaart “mõtleb” 300–800 ms liiga kaua, ei kirjuta ta sellest vihast e-kirja. Ta lihtsalt vajutab tagasi, proovib konkurenti või otsustab üldse mitte sõita. Sama loogika kehtib Bolt-tüüpi platvormimajanduse teenustes üle maailma: pisi-viivitus igas päringus kuhjub ja muudab kogemuse ebausaldusväärseks.

Siin on ebamugav tõde, mille olen näinud rohkem kui korra: kui sul on hajussüsteemis “müstiline latentsus”, on esimene asi, mida kontrollida, sageli TCP_NODELAY. Mitte sellepärast, et see oleks alati ainus põhjus, vaid sest see on üllatavalt tihti põhjus, mis jääb nähtamatuks kuni hetkeni, mil keegi selle sihilikult üle vaatab.

Allpool seon klassikalise TCP käitumise (Nagle’i algoritm ja delayed ACK-id) 2025. aasta reaalsusega: globaalne SaaS, regionaalsed kasutajad, TLS, mikroteenused ja AI-põhine automaatne jõudluse optimeerimine. Eesmärk on lihtne: vähem latentsust, vähem “juhuslikkust”, rohkem konversiooni ja paremad SLA-d.

Miks TCP_NODELAY latentsuse silmapetteks muutub

TCP_NODELAY on socket’i valik, mis lülitab välja Nagle’i algoritmi. Nagle’i algne idee (1980ndate alguses) oli ratsionaalne: vältida olukorda, kus TCP saadab tohutu hulga mikropakette (nt 1 bait andmeid + ~40 baiti header’it). Läbilaske võit võis olla suur.

Aga 2025. aasta SaaS-i ja platvormimajanduse süsteemides on prioriteedid teised.

Nagle’i algoritm: “oota ACK-i, siis saada juurde”

Nagle’i käitumise lihtsustus:

• kui sa saadad väikese tüki andmeid,
• ja eelmised saadetud baidid pole veel ACK-itud,
• siis TCP hoiab uue väikese tüki kinni, kuni ACK saabub.

See sobib hästi “kirjuta üks märk korraga” interaktiivse liikluse puhul. Aga hajussüsteemis on “üks väike tükk” sageli:

• järjekordne RPC/HTTP2 raami fragment
• väike gRPC control message
• cache’i päringu header
• matchmaking’i või hinnastusmootori väike vastus

Ehk: väiksed sõnumid, mis on latentsuse mõttes kriitilised.

Delayed ACK + Nagle = latentsuse võimendi

Praktikas läheb asi eriti valusaks, kui Nagle kohtub delayed ACK-idega.

• Nagle ootab ACK-i, et jätkata.
• delayed ACK võib ACK-i teadlikult edasi lükata, lootuses piggyback’ida see koos vastusandmetega.

Tulemus: pipelined või chatt-y protokollid saavad “kummipaela” efekti — sa ei saa sujuvat voogu, vaid perioodilisi mikroseisakuid.

Hajussüsteemides on üks RTT (round-trip time) datacenter’i sees sageli sadu mikrosekundeid kuni umbes 1 ms suurusjärgus; regioonide vahel millisekundid; maailmas üle ookeani kümned kuni sajad millisekundid. Isegi üks lisanduv RTT vales kohas on kalli hinnaga, sest server jõuab selle ajaga palju teha, kuid kasutaja kogemus ei liigu edasi.

Snippet-worthy mõte: Kui su rakendus tahab write() teha, aga kernel hoiab andmeid kinni “optimeerimise” nimel, siis see pole optimeerimine — see on kontrolli kaotus.

Mida see tähendab Eesti SaaS-ile ja sõidujagamise platvormidele

Eestis ehitatud tooted (Bolt on siin ilmne näide) skaleeruvad tihti kiiremini, kui nende algne infrastruktuurimudel eeldas. Platvormimajanduses on latentsus otseselt seotud:

• päringu usaldusväärsusega (kas tellimus kinnitub kohe?)
• hinnastuse tajutava stabiilsusega (kas hind “vilgub”?)
• reaalaja kaardikogemusega (kas auto liigub sujuvalt?)
• juhi töövooga (kas pakkumine jõuab õigel ajal?)

Sõidujagamise süsteem pole üks monoliit. See on terve võrgustik teenuseid:

• geokodeerimine, ETA, routing
• dünaamiline hinnastamine
• fraud/riski otsused
• maksed
• teavitused

Iga hop on uus TCP ühendus (või vähemalt uus voog), uus potentsiaalne “väike sõnum”, uus koht, kus vaikimisi TCP käitumine võib tuua ootamatu viivituse.

Siin on koht, kus paljud meeskonnad eksivad: nad mõõdavad ainult “keskmist latentsust”. Platvormimajanduses loeb aga tail — p95/p99. Üks “kummipael” p99-s võib kasutajakogemuse ära rikkuda rohkem kui 10 ms keskmise parandust.

Praktiline kontrollnimekiri: kus TCP_NODELAY päriselt rolli mängib

TCP_NODELAY pole maagia. Ta on tööriist, mis vähendab üht väga spetsiifilist viivituse allikat. Kasuta teda sihipäraselt.

1) Kontrolli protokolli mustrit: kas see on “chatt-y”?

Kui sul on palju väikeseid edasi-tagasi sõnumeid, on risk suurem.

Tüüpilised kandidaadid:

• gRPC / HTTP2 control frames ja väikesed payload’id
• request/response jadad, kus klient saadab mitu väikest käsku
• teenustevaheline koordinatsioon (locks, heartbeats, lease’i uuendused)

2) Vaata p99/p999, mitte ainult p50

Nagle’i + delayed ACK kombinatsioon kipub tekitama “sammu” latentsusjaotuses: mingi osa päringuid saab lisaviivituse. Seda on sageli p99-s selgem näha.

Mida logida:

• per-endpoint p50/p95/p99
• server-side queue time vs network time (kui võimalik)
• retransmits ja out-of-order pakid (kui sul on ligipääs madalamale telemeetriale)

3) Ära eelda, et TLS “lahendab” väiksed pakid

TLS lisab overhead’i ja record’ite loogika, kuid ei tähenda, et Nagle’i efekt kaoks. Väikeste kirjutuste mustrid on endiselt olemas, eriti kui rakenduse tasemel flush’itakse tihti.

4) Sea TCP_NODELAY teadlikult kohtades, kus latentsus on prioriteet

Hea rusikareegel latentsustundlikes teenustes: lülita Nagle välja teenustevahelistel ühendustel, kus saadad palju väikseid sõnumeid ja kus läbilase ei ole kitsaskoht.

Halb mõte: lülitada see pimesi kõikjal, ilma tagajärgi mõõtmata. Mõnes workload’is võib paketisagedus kasvada ja CPU/network interrupt koormus tõusta.

Kus AI tuleb mängu: automaatne TCP ja latentsuse optimeerimine

AI väärtus siin pole “AI kirjutab koodi sinu eest”. AI väärtus on keeruliste koostoimete haldamine süsteemides, kus ühe “default’i” mõju sõltub regioonist, kliendi seadmest, võrgust ja liiklusmustrist.

AI saab teha seda, mida inimestel pole aega teha iga päev

1. Anomaaliate avastamine latentsuses

   • Mudel õpib, milline on normaalne p95/p99 muster eri regioonides.
   • Kui ühes regioonis tekib “astmeline” lisaviivitus, saab see lipu.

2. Segmentide kaupa soovitused

   • “Nordics + iOS + 5G” võib käituda teistmoodi kui “Lõuna-Euroopa + Android + Wi‑Fi”.
   • AI saab pakkuda, kus tasub TCP_NODELAY (või rakenduse batching) aktiveerida.

3. Kontrollitud eksperimendid (safe rollout)

   • A/B test teenustevahelisel trafficul: TCP_NODELAY ON vs OFF.
   • Mõõdad mitte ainult latentsust, vaid ka CPU-d, packet rate’i, error rate’i.

4. Soovitus: paranda probleem rakenduse kihis, mitte kernelit “manitsedes”

   • Kui AI näeb, et sul on 200 write() call’i ühe request’i kohta, on parem see kokku pakkida.
   • Nagle’i väljalülitamine võib sümptomit leevendada, aga liigne “dribbling” on ikka halb arhitektuur.

Snippet-worthy mõte: AI aitab valida, millal optimeerida võrku ja millal parandada sõnumi kuju.

Kuidas siduda see platvormimajanduse KPI-dega (mitte ainult “ms on tore”)

Kui kirjutad tehnilist blogi Eesti SaaS-ile, on lihtne jääda millisekundite maailma. Müügi ja turunduse seisukohast loeb aga seos tulemustega.

Siin on kolm otseühendust, mida olen praktikas kasutanud:

1. Konversioon ja tellimuse lõpuni viimine

   • Latentsus tipukoormuse ajal (nt reede õhtu) mõjutab kõige rohkem. Just siis on raha laual.

2. Klienditoe koormus ja “ghost bugs”

   • Kui kinnitused hilinevad, tekivad topeltklõpsud, dubleeritud tellimused ja “äpp hangus” kaebused.

3. Globaalne kasv

   • Eesti toode võib olla tehniliselt suurepärane, kuid kui Aasia või Lõuna-Ameerika regioonides on tail-latentsus kole, tajutakse brändi “ebaühtlasena”.

Kõige praktilisem samm: pane p99 latentsus nähtavale samale dashboard’ile, kus on ärilised mõõdikud (tellimuse edukus, katkestused, makse läbimise aeg). Siis tekib organisatsioonis ühine keel.

Mida teha juba sel nädalal

Kui sul on SaaS või platvormimajanduse teenus (sh sõidujagamine, kuller, rendiäpid), siis ma teeks kolm sammu:

1. Audit: kus on “väikeste sõnumite” teekonnad?

   • teenustevaheline RPC
   • reaalaja positsioneerimine
   • hinnastus ja pakkumiste edastus

2. Eksperiment: TCP_NODELAY latentsustundlikes ühendustes

   • vali 1–2 teenust, kus p99 on probleem
   • tee canary ja mõõda p99 + packet rate + CPU

3. AI-põhine jälgimine ja soovitused

   • isegi lihtne mudel, mis tuvastab “astmeid” ja korrelatsioone (regioon, endpoint, payload size), annab kiiresti väärtust
   • eesmärk pole “autopiloot”, vaid kiirem diagnostika ja turvalisemad muudatused

Latentsusprobleemid kipuvad korduma, sest meeskonnad vahetuvad ja süsteem kasvab. Kui su protsess sõltub sellest, et “keegi mäletab TCP-d”, siis varem või hiljem maksad selle eest.

Bolt ja teised platvormimajanduse ettevõtted on näidanud, et Eestist saab ehitada globaalseid süsteeme. Järgmine tase on see, et jõudlusotsused ei jääks vaikimisi seadistuste hooleks, vaid oleksid mõõdetavad, automatiseeritud ja regioonipõhised.

Mis oleks sinu tootes kõige nähtavam võit: kas tellimuse kinnituse kiirus, kaardi sujuvus või tiputunni stabiilsus?