Bun vai Node.js? Lähes kaksinkertainen läpimeno ei ratkaise tuotantoa

Bunin Expressin HTTPS-mittauksessa Bun 1.4 käsitteli 48 243 ja Node.js 26.7.0 käsitteli 25 181 pyyntöä sekunnissa. Bunin tulos on noin 1,92-kertainen. Nopeusetu antaa syyn tutkia vaihtoa, mutta tuotantopäätös riippuu siitä, toimivatko nykyisen sovelluksen riippuvuudet Bunissa ja pysyvätkö sen vasteajat hyväksyttävinä.

Toimivaa Node.js-palvelua ei siis kannata siirtää pelkän vertailuluvun perusteella. Jos sovellus käyttää Bunissa eri tavoin toimivaa rajapintaa tai sen hitaimmat pyynnöt hidastuvat, suurempi läpimeno ei auta käyttäjiä. Päätöksen perustaksi tarvitaan saman sovelluksen kuormituskoe sekä tapa palauttaa liikenne aiempaan ajoon.

Mitä HTTPS-läpimeno mittaa?

Mittauksen kohteena oli Express 5.2.1:n Hello World -sovellus TLS 1.3 -yhteydellä. Kuormitustyökalu käytti 50 rinnakkaista yhteyttä viiden sekunnin ajan Linux x64 -ympäristössä, ja julkaistut luvut ovat kolmen ajon mediaaneja. Näissä oloissa Bun käsitteli noin 92 prosenttia enemmän pyyntöjä sekunnissa kuin Node.js. Kyse on saman kevyen sovelluksen vertailusta, joten suhdeluku kuvaa juuri tätä työkuormaa.

Oman palvelun tulos voi muuttua, kun pyyntö käy tietokannassa, odottaa toista verkkopalvelua, tarkistaa käyttäjän oikeudet tai käsittelee suuremman vastauksen. Jos suurin osa ajasta kuluu ulkoisen palvelun odottamiseen, ajonaikaisen ympäristön nopeampi pyynnönkäsittely vaikuttaa kokonaisaikaan vähemmän. Tämä on työkuormasta seuraava päätelmä, ei lupaus kummankaan ympäristön tuotantonopeudesta.

Vertailukelpoisessa kokeessa reitit, riippuvuuksien versiot, vastaukset ja tarjottu kuorma pidetään samoina. Läpimenon rinnalle tarvitaan toteutuneet virheet, muistinkäyttö ja viivejakauma: suuri pyyntömäärä voi muuten peittää hitaat vastaukset. Bunin julkaisema mittaus antaa lähtökohdan kokeelle, mutta hyöty on päätöksenteon kannalta todellinen vasta, kun se näkyy palvelun omassa liikenteessä.

Käynnistysnopeus vastaa eri kysymykseen

Bunin Linuxin Hello World -käynnistysmittauksessa Bunin aika on 5,2 millisekuntia ja Node.js:n 25,1 millisekuntia. Tulos koskee yksinkertaisen skriptin käynnistämistä, ei valmiin verkkopalvelun pyynnön vasteaikaa. Siksi se täydentää HTTPS-läpimenon vertailua eikä ole toinen mittaus samasta nopeusedusta.

Lyhyissä komentoriviohjelmissa, toistuvasti käynnistyvissä töissä ja usein luotavissa prosesseissa käynnistysaika voi olla näkyvä osa kokonaiskestoa. Pitkään käynnissä oleva palvelu taas käsittelee paljon pyyntöjä saman käynnistyksen jälkeen. Sen kohdalla jatkuvan kuorman käyttäytyminen painaa yleensä enemmän, vaikka nopeampi käynnistyminen voisi auttaa esimerkiksi uusien prosessien avaamisessa.

Todellinen sovellus myös lataa moduuleja, alustaa asetuksia ja avaa yhteyksiä ennen kuin se on valmis ottamaan liikennettä vastaan. Jos käynnistysnopeus on siirron peruste, mitattava väli alkaa prosessin käynnistämisestä ja päättyy vasta palvelun käyttövalmiuteen. Pelkän Hello World -skriptin ero ei kerro, kuinka suuri osuus oman sovelluksen odotusajasta kuuluu ajonaikaiselle ympäristölle.

Yhteensopivuus löytyy käytetyistä rajapinnoista

Bunin Node.js v26 -yhteensopivuuskuvaus listaa edelleen osittain toteutettuja rajapintoja: node:worker_threads-moduulin Worker ohittaa resourceLimits-asetuksen, ja node:async_hooks-moduulin eräät kutsut ovat korvikkeita. Kuvaus kertoo myös, ettei AsyncLocalStorage-konteksti välity Worker-tapahtumiin. Erot ovat merkityksellisiä silloin, kun sovellus tai sen riippuvuus käyttää juuri näitä toimintoja.

Onnistunut asennus ei siksi vielä osoita, että paketti käyttäytyy tuotannossa samoin kuin Node.js:ssä. Se voi käynnistyä normaalisti mutta käyttää poikkeavaa rajapintaa vasta taustatehtävässä, virhetilanteessa tai jäljitystä käynnistettäessä. Riippuvuusketjussa kannattaa erottaa toisistaan ominaisuudet, joita sovellus todella käyttää, ja ominaisuudet, jotka vain näkyvät paketin mahdollisissa käyttötavoissa.

Erityisen selvä pysäytysehto syntyy, jos palvelun toiminta tai sen turvaraja perustuu työntekijäsäikeen resourceLimits-asetukseen. Asetuksen hyväksyminen ilman odotettua vaikutusta voi jäädä huomaamatta tavallisessa toiminnallisessa testissä. Myös pyyntökohtaisen kontekstin välittyminen on syytä testata niissä tapahtumissa, joihin sovelluksen lokitus tai jäljitys nojaa. Näitä riskejä ei voi ratkaista yleisellä yhteensopivuusprosentilla; ratkaisevaa on käytetyn koodipolun toiminta.

Miksi p99 voi kääntää tuloksen?

Platformaticin tammikuun 2026 Next.js-kokeessa Bunin p99-viive oli yhdessä ajossa 960,45 millisekuntia ja Node.js:n 144,45 millisekuntia. Kuormaksi asetettiin 1 000 pyyntöä sekunnissa 120 sekunnin ajaksi AWS EKS -ympäristössä; kokeessa käytettiin Bun 1.3.5:tä ja Node.js 24:ää. Expressin HTTPS-mittauksessa käytettiin uudempia versioita, kevyempää sovellusta ja läpimenoa mittarina. Näitä tuloksia ei voi asettaa saman testin voittaja- ja häviäjälukemiksi.

P99 on vasteaika, jonka alle 99 prosenttia mitatuista pyynnöistä jää. Se näyttää, mitä tapahtuu jakauman hitaassa päässä, vaikka keskimääräinen vastaus olisi nopea. Next.js-kokeen kaikki ajonaikaiset ympäristöt käsittelivät tavoitellun kuorman ilman epäonnistuneita pyyntöjä, mutta niiden viiveet erosivat selvästi. Siksi onnistumisprosentti ja läpimeno eivät yksin kuvaa asiakkaan kokemaa odotusta.

Nykyisen palvelun kuormituskokeessa p99 on verrattava etukäteen asetettuun vasteaikatavoitteeseen samalla kuormalla ja laitteistolla. Riittävän pitkä ajo voi lisäksi paljastaa muistin kasvun tai ajoittaisen hidastumisen, jota lyhyt testi ei näytä. Jos Bun lisää häntäviivettä palvelulle kriittisillä reiteillä, Expressin kevyessä testissä saatu läpimenoetu ei perustele vaihtoa.

Millä ehdoilla ajonaikaisen ympäristön voi vaihtaa?

Newstackin tuotantovertailu suosittelee pitämään toimivan palvelun Node.js:ssä ja kokeilemaan Bunia ensin asennuksissa, testeissä ja skripteissä. Bunin työkalujen käyttö ei edellytä palveluprosessin siirtämistä. Nykyisen sovelluksen ajonaikaisen ympäristön vaihtoon tarvitaan erillinen hyöty, joka kestää myös yhteensopivuus- ja kuormitustestit.

Siirrolle voi asettaa kolme pysäytysehtoa:

• Kriittinen riippuvuus tai koodipolku vaatii Node.js-ominaisuutta, joka puuttuu Bunista tai toimii siinä sovelluksen oletusten vastaisesti.
• Oman kuorman p99-viive, virhemäärä tai muistinkäyttö ylittää ennalta sovitun rajan, vaikka läpimeno kasvaisi.
• Liikennettä ei voida palauttaa aiempaan Node.js-ajoon hallitusti samoilla sovellus- ja tietoversioilla.

Jos ehdot täyttyvät ja mitattu hyöty on palvelulle merkittävä, rajattu tuotantokoe antaa lisää tietoa ennen laajempaa siirtoa. Jos hyöty jää pieneksi, Node.js:n säilyttäminen on perusteltu valinta. Bun voi silti nopeuttaa kehityksen työvaiheita ilman, että verkkopalvelun ajoalustaa vaihdetaan.

Lue myös:

• Docker vai Podman? Käynnistysnopeus ei ratkaise, käyttöoikeudet ratkaisevat
• vLLM vai TGI? Suuri rinnakkaisuus käänsi läpimenon 24-kertaiseksi
• Vercel vai Netlify? Kolmas tiimin jäsen muuttaa saman 20 dollarin hinnan