Hvordan vi brukte WebAssembly for å øke hastigheten på en nettapplikasjon 20 ganger

Denne artikkelen diskuterer en sak for å øke hastigheten på en nettleserapplikasjon ved å erstatte JavaScript-beregninger med WebAssembly.

WebAssembly - hva er det?

Kort fortalt er dette et binært instruksjonsformat for en stabelbasert virtuell maskin. Wasm (kort navn) kalles ofte et programmeringsspråk, men det er det ikke. Instruksjonsformatet kjøres i nettleseren sammen med JavaScript.

Det er viktig at WebAssembly kan fås ved å kompilere kilder på språk som C/C++, Rust, Go. Her brukes statistisk skriving og den såkalte flate minnemodellen. Koden, som nevnt ovenfor, lagres i et kompakt binært format, noe som gjør det nesten like raskt som å kjøre programmet ved hjelp av kommandolinjen. Disse egenskapene har ført til veksten av WebAssemblys popularitet.

Vi minner om: for alle lesere av "Habr" - en rabatt på 10 000 rubler når du melder deg på et hvilket som helst Skillbox-kurs ved å bruke kampanjekoden "Habr".

Skillbox anbefaler: Praktisk kurs "Mobilutvikler PRO".

For tiden brukes Wasm i mange applikasjoner, fra spill som Doom 3 til nettporterte applikasjoner som Autocad og Figma. Wasm brukes også i områder som serverløs databehandling.

Denne artikkelen gir et eksempel på bruk av Wasm for å øke hastigheten på en analysenetttjeneste. For klarhetens skyld tok vi en fungerende applikasjon skrevet i C, som er kompilert i WebAssembly. Resultatet vil bli brukt til å erstatte underpresterende deler av JS.

Søknadstransformasjon

Eksemplet vil bruke nettlesertjenesten fastq.bio, som er beregnet på genetikere. Verktøyet lar deg evaluere kvaliteten på DNA-sekvensering (dechiffrering).

Her er et eksempel på applikasjonen i aksjon:

Detaljene i prosessen er ikke verdt å gå inn på siden de er ganske komplekse for ikke-spesialister, men kort fortalt kan forskere bruke infografikken ovenfor for å forstå om DNA-sekvenseringsprosessen gikk problemfritt og hvilke problemer som oppsto.

Denne tjenesten har alternativer, skrivebordsprogrammer. Men fastq.bio lar deg få fart på arbeidet ditt ved å visualisere dataene. I de fleste andre tilfeller må du kunne jobbe med kommandolinjen, men ikke alle genetikere har den nødvendige erfaringen.

Alt fungerer rett og slett. Inndata er data presentert i form av en tekstfil. Denne filen er generert av spesialiserte sekvenseringsverktøy. Filen inneholder en liste over DNA-sekvenser og en kvalitetspoengsum for hvert nukleotid. Filformatet er .fastq, som er grunnen til at tjenesten har fått navnet sitt.

Implementering i JavaScript

Det første trinnet til brukeren når han arbeider med fastq.bio er å velge riktig fil. Ved å bruke File-objektet leser applikasjonen et tilfeldig utvalg av data fra en fil og behandler den batchen. JavaScripts jobb her er å utføre enkle strengoperasjoner og beregne beregninger. En av dem er antall nukleotider A, C, G og T på forskjellige DNA-fragmenter.

Etter å ha beregnet de nødvendige indikatorene, blir de visualisert ved hjelp av Plotly.js, og tjenesten begynner å jobbe med en ny dataprøve. Chunkingen er gjort for å forbedre kvaliteten på UX. Hvis du jobber med alle dataene samtidig, vil prosessen fryse i noen tid, siden filene med sekvenseringsresultatene tar opp hundrevis av gigabyte med filplass. Tjenesten tar data som varierer i størrelse fra 0,5 til 1 MB og jobber med dem trinn for trinn, og bygger grafiske data.

Slik fungerer det:

Det røde rektangelet inneholder strengtransformasjonsalgoritmen for å oppnå visualisering. Dette er den mest beregningsintensive delen av tjenesten. Det er verdt å prøve å erstatte den med Wasm.

Testing av WebAssembly

For å vurdere muligheten for å bruke Wasm begynte prosjektgruppen å søke etter ferdige løsninger for å lage QC-metrikker (QC - kvalitetskontroll) basert på fastq-filer. Søket ble utført blant verktøy skrevet i C, C++ eller Rust, slik at det var mulig å portere koden til WebAssembly. I tillegg skal verktøyet ikke være "rå"; en tjeneste som allerede var testet av forskere var nødvendig.

Som et resultat ble valget tatt til fordel for seqtk. Applikasjonen er ganske populær, den er åpen kildekode, kildespråket er C.

Før du konverterer til Wasm, er det verdt å se på kompileringsprinsippet for seqtk for skrivebordet. I følge Makefile, her er det du trenger:

# Compile to binary
$ gcc seqtk.c 
   -o seqtk 
   -O2 
   -lm 
   -lz

I prinsippet kan du kompilere seqtk ved hjelp av Emscripten. Hvis det ikke er der, klarer vi det. Docker-bilde.

$ docker pull robertaboukhalil/emsdk:1.38.26
$ docker run -dt --name wasm-seqtk robertaboukhalil/emsdk:1.38.26

Hvis ønskelig, Du kan montere den selv, men det tar tid.

Inne i en beholder kan du enkelt bruke emcc som et alternativ til gcc:

# Compile to WebAssembly
$ emcc seqtk.c 
    -o seqtk.js 
    -O2 
    -lm 
    -s USE_ZLIB=1 
    -s FORCE_FILESYSTEM=1

Minimumsendringer:

I stedet for å sende ut til en binær fil, bruker Emscripten .wasm og .js for å generere filene, som brukes til å kjøre WebAssemby-modulen.

USE_ZLIB-flagget brukes til å støtte zlib-biblioteket. Biblioteket er distribuert og portert til WebAssembly, og Emscripten inkluderer det i prosjektet.

Det virtuelle filsystemet Emscrippten er aktivert. Dette POSIX-lignende FS, kjører i RAM inne i nettleseren. Når siden er oppdatert, tømmes minnet.

For å forstå hvorfor et virtuelt filsystem er nødvendig, er det verdt å sammenligne måten du kjører seqtk på fra kommandolinjen med måten du kjører en kompilert WebAssembly-modul på.

# On the command line
$ ./seqtk fqchk data.fastq
 
# In the browser console
> Module.callMain(["fqchk", "data.fastq"])

Å få tilgang til det virtuelle filsystemet er nødvendig for ikke å omskrive seqtk for streng i stedet for filinndata. I dette tilfellet vises datafragmentet som en data.fastq-fil i den virtuelle FS med et kall til main() seqtk.

Her er den nye arkitekturen:

Figuren viser at i stedet for beregninger i hovednettlesertråden, Webarbeidere. Denne metoden lar deg utføre beregninger i en bakgrunnstråd uten å påvirke nettleserens respons. Vel, WebWorker-kontrolleren starter Worker og administrerer interaksjonen med hovedtråden.

Seqtk-kommandoen kjøres med Worker på den monterte filen. Etter fullført henrettelse produserer arbeideren et resultat i form av et løfte. Når en melding mottas av hovedtråden, brukes resultatet til å oppdatere grafene. Og så videre i flere iterasjoner.

Hva med WebAssembly-ytelsen?

For å evaluere endringen i ytelse, brukte prosjektteamet parameteren leseoperasjoner per sekund. Tiden det tar å bygge interaktive grafer er ikke tatt i betraktning siden begge implementeringene bruker JavaScript.

Ved bruk av den ferdige løsningen var ytelsesøkningen ni ganger.

Dette er et utmerket resultat, men som det viser seg, er det en mulighet til å optimalisere det også. Faktum er at et stort antall QC-analyseresultater ikke brukes av seqtk, så de kan slettes. Hvis du gjør dette, forbedres resultatet med 13 ganger sammenlignet med JS.

Det ble oppnådd ved ganske enkelt å kommentere printf()-kommandoene.

Men det er ikke alt. Faktum er at på dette stadiet mottar fastq.bio analyseresultatene ved å kalle forskjellige C-funksjoner. Hver av dem beregner sitt eget sett med egenskaper, slik at hvert fragment av filen leses to ganger.

For å komme rundt dette problemet ble det besluttet å kombinere to funksjoner til én. Som et resultat økte produktiviteten med 20 ganger.

Det er verdt å merke seg at et så enestående resultat ikke alltid kan oppnås. I noen tilfeller vil ytelsen synke, så det er verdt å vurdere hvert enkelt tilfelle.

Som en konklusjon kan vi si at Wasm gir en mulighet til å forbedre applikasjonsytelsen, men du må bruke den med omhu.

Skillbox anbefaler:

• Toårig praktisk kurs "Jeg er en PRO-nettutvikler".
• Online kurs "C#-utvikler fra 0".
• Praktisk årskurs "PHP-utvikler fra 0 til PRO".

Kilde: www.habr.com