Kun näppäimistö tietää mitä haluat sanoa ennen sinua

Oletko koskaan huomannut, kun kirjoitat hakukenttään ja ehdotukset ilmestyvät ennen kuin ehit painaa nappia loppuun? Se ei ole taikuutta – se on insinöörityötä. Ja varsin kiehtova ongelma, kun taustalla on 240 miljoonaa verkkotunnusta.

Miksi nopeus on tärkeämpää kuin uskotkaan

Käyttäjät odottavat tuloksia välittömästi. Nielsen Norman Groupin tutkimuksen mukaan 0,1 sekuntia on kynnys, jonka jälkeen toiminnot alkavat tuntua viivästyneiltä. Hitaampi vastaus katkaisee ajatuksenkulun.

Wirewikin kaltaiselle työkalulle autocomplete on se portti, josta käyttäjät astuvat sisään. Jokainen millisekunti on tärkeä, kun yrität tarkistaa DNS-tietoja nopeasti. Käyttäjän pitäisi tuntea, että työkalu lukee hänen ajatuksiaan – ei odota palvelimen vastausta.

Ennakohakunnan taika

Tässä piilee oleellinen oivallus: kyse ei ole API:n nopeuttamisesta (vaikka sekin auttaa). Kyse on ajan varastamisesta itse kirjoitusprosessista.

Kun käyttäjä painaa näppäintä (keyDown), haetaan ehdotuksia sille mitä hän kirjoittaa sekä seuraavalle todennäköiselle kirjaimelle. Kun näppäin vapautuu (keyUp), näytetään mitä ikinä on valmiina. Aikabudjettisi ei siis ole API:n viive – se on kahden näppäinpainalluksen kesto plus niiden välinen tauko.

60 Hz näytöllä aikaa on 16,7 millisekuntia per ruutu. Budjetti on noin 121 millisekuntia nopeimmilla kirjoittajilla p99-tasolla. Se on sinun aikasi. Jos tulokset ovat valmiina ennen toisen näppäinpainalluksen loppua, käyttäjästä se tuntuu ilmiömäisen nopealta.

Suunnittelua skaalautuvuuden ehdoilla

APIn täytyy käsitellä 240 miljoonaa verkkotunnusta ongelmitta. Nokkela ratkaisu on kohdella suosittuja domaineja eri tavalla kuin harvinaisempia:

Huippu: Suosituimmat verkkotunnukset elävät muistissa olevassa merkkipuussa (trie). Hakutulokset ovat vain osoittimien läpikävelyä – nopeaa ja ennustettavaa. Kunkin mahdollisen etuliitteen kahdeksan parasta ehdotusta on laskettu valmiiksi. Pahimmillaan? O(syötteen pituus). Erittäin pieni.

Häntä: Kaikki muu asuu SSD-levyllä muistin kautta käsiteltävässä lohkohakemistossa. Verkkotunnukset on järjestetty, delta-pakattu ja jaettu kiinteän kokoisiin lohkoihin. Hakemisto mahtuu muistiin ja mahdollistaa binaarihaun. 240 miljoonaa verkkotunnusta vie noin 2,5 gigatavua, ja käyttöjärjestelmä hoitaa kuumien sivujen välimuistin automaattisesti.

Molemmat rakenteet sisältävät rajatun syötteen – verkkotunnusten määrä ja kyselyn pituus eivät kasva äärettömästi. Käytännön monimutkavuus on siis likimain O(1), mikä pitää p99-viiveen tasaisena.

Numerot puhuvat puolestaan

Kuormitustestit paljastivat mielenkiintoisen havainnon. API itsessään vastaa useimmat pyynnöt alle kahdessa millisekunnissa. Vaikka kuorma nousee 1 600 pyyntöön sekunissa, Nginx ja API yhdessä pysyvät 15 millisekunnissa p99-tasolla. Hyvä suorituskyky.

Mutta sitten tulee todellisuus: verkko. Käytännössä kokonaisviive koostuu selaimen, Cloudflaren ja palvelimen välisestä edestakaisesta ajasta plus noin 10 millisekunnin yleiskustannuksista. Sama-alueellisille käyttäjille ollaan budjetissa. Muille? Siinä kohtaa tarvitaan tähti.

Tähti

p99 0ms* tarkoittaa, että 99 % pyynnöistä palauttaa tulokset ennen kuin käyttäjä ehtii painaa näppäintä loppuun – jos hän on lähellä palvelinta. Lisää 100–200 millisekuntia mannerlaajojen välistä latenssia, ja yhtäkkiä ollaan budjetin ulkopuolella.

Korjaus olisi maantieteellisesti hajautettu palvelinverkko kuormantasauksella. Mutta sivuprojektille se on valtava infrastruktuuri ylläpidettäväksi. Joskus "riittävän hyvä" on oikeasti riittävän hyvä – varsinkin kun kohdekäyttäjät ovat eurooppalaisia kehittäjiä tarkistamassa verkkotunnuksia.

Mitä tämä tarkoittaa seuraavalle projektillesi

Tässä on opetus, joka pätee paljon laajemmalle kuin verkkotunnushakuihin: ennakohae älykkäästi. Jos tiedät mitä käyttäjät saattavat seuraavaksi kysyä, hae se ennen kuin he kysyvät. Anna käyttöliittymän reagoida siihen mikä on valmiina sen sijaan että odotetaan varmuutta.

Toinen opetus koskee tietorakenteiden valintaa. Trie kuumille tiedoille, hyvin indeksoitu järjestetty rakenne kaikelle muulle. Sinun ei tarvitse pitää 240 miljoonaa riviä RAM-muistissa, jos suunnittelet käyttömallit sen mukaan mitä todennäköisesti tarvitaan.

Lopuksi: mittaa todellinen budjettisi. Tässä tapauksessa se oli kaksi näppäinpainallusta plus tauko. Mikä on sinun vastaavasi? Löydä se, optimoi sen mukaan, ja lopeta optimoimasta sen yli.

Lopputulos tuntuu taikuudelta. Mutta se alkaa ymmärtämällä täsmälleen, kuinka paljon aikaa sinulla oikeasti on.