MGP-krasjet: Hvor mye er egentlig 38 millioner emojis?

- At 145 megabyte data knakk hele løsningen, høres litt merkelig ut, mener Øistein Sørensen.

Konstituert kringastingssjef Vibeke Fürst Haugen måtte svare for det tekniske kaoset under stemmegivningen under finalen i MGP i Trondheim Spektrum. 📸: Tore Meek / NTB scanpix
Konstituert kringastingssjef Vibeke Fürst Haugen måtte svare for det tekniske kaoset under stemmegivningen under finalen i MGP i Trondheim Spektrum. 📸: Tore Meek / NTB scanpix Vis mer

Alt gikk i stå hos NRK da nettavstemmingen av MGP skulle gjennomføres.

Vibeke Fürst Haugen, fungerende kringkastingssjef, sier at 38 millioner emojis er skylden til at systemene gikk ned.

Hvor mye er egentlig 38 millioner emojis?

For å kunne svare på det så må vi først se på hva en emoji er for noe:

  • En emoji er egentlig bare et unicode tegn som vises som et fancy symbol på telefonen eller PCen din.
  • En emoji er 4 bytes i størrelse.
  • En emoji er altså ikke noe annet enn en ganske vanlig bokstav av typen unicode.

I datastørrelse er 38 millioner emojis altså 152 millioner bytes, eller rundt 145 MB.

«I datastørrelse er 38 millioner emojis altså 152 millioner bytes, eller rundt 145 MB.»

Så med andre ord sier fungerende kringkastingssjef at 145 MB med data knakk hele løsningen deres, og i mitt hode så høres det litt merkelig ut. La oss se litt videre på dette.

Hvor mange oppkoblinger mot løsningen fikk de?

Dersom vi antar at emojiene ble sendt jevnt og trutt under alle låtene og at alle de 10 låtene varte i 3 minutter hver, så betyr dette at de hadde 38 millioner oppkoblinger på 30 minutter.

Dette blir da rundt 21.100 tilkoblinger i sekundet. Dette er relativt høy trafikk som kan skape problemer i flere ledd.

Hvor mye klarer en typisk server å håndtere?

I tiden jeg jobbet i Schibsted med datainnsamling testet vi forskjellige typer oppsett. Standard oppsett klarte vanligvis å håndtere 2-3.000 req/s på en typisk datainnsamlings applikasjon. Etter kodeoptimalisering og tuning kom vi opp mot 8-10.000 req/s per server på vårt Node.js oppsett.

Dataene som kom inn ble dyttet inn i en datakø (AWS SQS), og bak denne hadde vi flere applikasjoner som trakk ut data og behandlet denne så raskt det lot seg gjøre.

På denne måten kunne vi håndtere en gjennomsnittlig datamengde på 30-40.000 JSON-objekter pr sekund. Disse objektene var vesentlig større enn en emoji på 4 bytes. Peak trafikk kunne ofte være 3-4 ganger denne trafikken, og alt sammen kjørte komfortabelt på 5 servere.

Senere benyttet jeg omtrent samme tekniske prinsipper hos Telia og her behandlet mobiltrafikken, som er vesentlig høyere enn tallene over.

Så hvorfor krasjet løsningen til NRK?

Det blir bare spekulasjoner, men typiske feil ved oppsett av slike løsninger er:

  • Teknisk løsning er for tung i det ytterste leddet og bruker for mye resursser per forespørsel. Dette betyr igjen at oppskalering krever veldig mange servere og tar mye tid.
  • Stresstestingen er gjennomført med statiske test-data, som ikke representerer vanlig bruk.
  • Pre-heating før trafikken treffer løsningen er uteglemt.
  • Manglende rate limit pr klient.
  • Manglende skalering. 🙈

(kode24 er i kontakt med NRK for å få fakta på bordet, men velger å trykke dette innlegget inntil vi har fått svar på våre spørsmål. Vet du noe om saken, må du gjerne ta kontakt, på ole@kode24.no)