ProHoster > Blog > Adminisztráció > Hogyan használtuk a WebAssembly-t egy webalkalmazás 20-szoros felgyorsítására
Hogyan használtuk a WebAssembly-t egy webalkalmazás 20-szoros felgyorsítására
Ez a cikk a böngészőalkalmazások felgyorsításának esetét tárgyalja a JavaScript-számítások WebAssembly-re cserélésével.
WebAssembly – mi ez?
Röviden, ez egy bináris utasításformátum egy verem alapú virtuális géphez. A Wasm-ot (rövid név) gyakran programozási nyelvnek nevezik, de nem az. Az utasítás formátuma a böngészőben fut le a JavaScripttel együtt.
Fontos, hogy a WebAssembly elérhető legyen a források fordításával olyan nyelveken, mint a C/C++, Rust, Go. Itt a statisztikai tipizálást és az úgynevezett lapos memória modellt alkalmazzuk. A kód, ahogy fentebb említettük, kompakt bináris formátumban van tárolva, így majdnem olyan gyors, mint az alkalmazás parancssor használatával történő futtatása. Ezek a képességek a WebAssembly népszerűségének növekedéséhez vezettek.
Emlékeztetünk:a "Habr" minden olvasója számára - 10 000 rubel kedvezmény, ha a "Habr" promóciós kóddal bármely Skillbox tanfolyamra jelentkezik.
Jelenleg a Wasm-ot számos alkalmazásban használják, az olyan játékoktól, mint a Doom 3, az olyan webes alkalmazásokig, mint az Autocad és a Figma. A Wasm-ot olyan területeken is használják, mint a szerver nélküli számítástechnika.
Ez a cikk példát mutat be a Wasm használatával egy analitikai webszolgáltatás felgyorsítására. Az egyértelműség kedvéért vettünk egy működő, C nyelven írt alkalmazást, amely WebAssembly-be van fordítva. Az eredményt a rendszer a JS alulteljesítő szakaszainak pótlására használjuk fel.
Alkalmazás átalakítás
A példa a fastq.bio böngészőszolgáltatást fogja használni, amely genetikusoknak készült. Az eszköz lehetővé teszi a DNS-szekvenálás (megfejtés) minőségének értékelését.
Íme egy példa az alkalmazás működésére:
A folyamat részleteibe nem érdemes belemenni, mivel azok meglehetősen bonyolultak a nem szakemberek számára, de röviden összefoglalva, a tudósok a fenti infografika segítségével megérthetik, hogy a DNS-szekvenálási folyamat zökkenőmentesen ment-e, és milyen problémák merültek fel.
Ennek a szolgáltatásnak vannak alternatívái, asztali programjai. De a fastq.bio lehetővé teszi, hogy felgyorsítsa a munkát az adatok megjelenítésével. A legtöbb esetben tudnia kell a parancssorral dolgozni, de nem minden genetikus rendelkezik a szükséges tapasztalattal.
Minden egyszerűen működik. A bemenet egy szöveges fájl formájában megjelenített adat. Ezt a fájlt speciális szekvenáló eszközök hozzák létre. A fájl tartalmazza a DNS-szekvenciák listáját és az egyes nukleotidok minőségi pontszámát. A fájl formátuma .fastq, ezért kapta a szolgáltatás nevét.
Megvalósítás JavaScriptben
A fastq.bio-val végzett munka során a felhasználó első lépése a megfelelő fájl kiválasztása. A Fájl objektum használatával az alkalmazás véletlenszerű adatmintát olvas be egy fájlból, és feldolgozza azt a kötegelt. A JavaScript feladata itt egyszerű karakterlánc-műveletek végrehajtása és metrikák kiszámítása. Az egyik az A, C, G és T nukleotidok száma a különböző DNS-fragmenseken.
A szükséges mutatók kiszámítása után a rendszer a Plotly.js segítségével megjeleníti azokat, és a szolgáltatás új adatmintával kezd dolgozni. A darabolás az UX minőségének javítása érdekében történik. Ha az összes adattal egyszerre dolgozik, a folyamat egy ideig lefagy, mivel a szekvenálási eredményeket tartalmazó fájlok több száz gigabájt fájlterületet foglalnak el. A szolgáltatás 0,5-1 MB méretű adatdarabokat vesz fel, és lépésről lépésre dolgozik velük, grafikus adatokat építve.
Így működik:
A piros téglalap tartalmazza a karakterlánc-transzformációs algoritmust a vizualizáció eléréséhez. Ez a szolgáltatás számításigényesebb része. Érdemes megpróbálni Wasm-mal cserélni.
A WebAssembly tesztelése
A Wasm használatának lehetőségének felmérése érdekében a projektcsapat kész megoldásokat kezdett kutatni a QC metrikák (QC – minőségellenőrzés) létrehozására fastq fájlok alapján. A keresést C, C++ vagy Rust nyelven írt eszközök között végeztük, így a kódot át lehetett vinni a WebAssembly-re. Ezenkívül az eszköz nem lehet „nyers”, olyan szolgáltatásra volt szükség, amelyet a tudósok már teszteltek.
Ennek eredményeként a választás mellett döntöttek seqtk. Az alkalmazás meglehetősen népszerű, nyílt forráskódú, a forrásnyelv C.
A Wasm-re való konvertálás előtt érdemes megnézni a seqtk összeállítási elvét az asztalon. A Makefile szerint a következőkre van szüksége:
Ahelyett, hogy bináris fájlba adná ki a kimenetet, az Emscripten .wasm és .js fájlokat használ a fájlok generálásához, amelyek a WebAssemby modul futtatására szolgálnak.
A USE_ZLIB jelző a zlib könyvtár támogatására szolgál. A könyvtárat szétosztották és a WebAssembly-re portolták, és az Emscripten belefoglalja a projektbe.
Az Emscrippten virtuális fájlrendszer aktiválva van. Ez POSIX-szerű FS, amely a böngészőn belüli RAM-ban fut. Az oldal frissítésekor a memória törlődik.
Ahhoz, hogy megértsük, miért van szükség virtuális fájlrendszerre, érdemes összehasonlítani a seqtk parancssorból való futtatását a lefordított WebAssembly modul futtatásával.
# On the command line
$ ./seqtk fqchk data.fastq
# In the browser console
> Module.callMain(["fqchk", "data.fastq"])
A virtuális fájlrendszerhez való hozzáférésre azért van szükség, hogy ne írjuk át a seqtk-t karakterláncra, nem pedig fájlbevitelre. Ebben az esetben az adattöredék data.fastq fájlként jelenik meg a virtuális FS-ben, rajta a main() seqtk meghívásával.
Íme az új architektúra:
Az ábra azt mutatja, hogy a fő böngészőszálban végzett számítások helyett Webmunkások. Ez a módszer lehetővé teszi a számítások elvégzését egy háttérszálban anélkül, hogy befolyásolná a böngésző válaszkészségét. Nos, a WebWorker vezérlő elindítja a Worker-t, és kezeli annak interakcióját a fő szállal.
A seqtk parancs a Worker használatával fut a felcsatolt fájlon. A végrehajtás befejezése után a Dolgozó Ígéret formájában eredményt produkál. Amikor a főszál üzenetet kap, az eredményt a grafikonok frissítésére használják fel. És így tovább több iterációban.
Mi a helyzet a WebAssembly teljesítményével?
A teljesítmény változásának értékeléséhez a projektcsapat a másodpercenkénti olvasási műveletek paramétert használta. Az interaktív grafikonok felépítéséhez szükséges időt nem vesszük figyelembe, mivel mindkét megvalósítás JavaScriptet használ.
A kész megoldás használatakor a teljesítménynövekedés kilencszeres volt.
Ez kiváló eredmény, de mint kiderült, van lehetőség optimalizálni is. A helyzet az, hogy a QC elemzési eredmények nagy részét a seqtk nem használja fel, így azok törölhetők. Ha ezt megteszi, az eredmény 13-szor javul a JS-hez képest.
Ezt a printf() parancsok egyszerű megjegyzésével értük el.
De ez még nem minden. A tény az, hogy ebben a szakaszban a fastq.bio különböző C függvények meghívásával kapja meg az elemzési eredményeket, amelyek mindegyike kiszámítja a saját karakterisztikáját, így a fájl minden töredéke kétszer kerül beolvasásra.
A probléma megkerülése érdekében úgy döntöttek, hogy két funkciót egyesítenek egybe. Ennek eredményeként a termelékenység 20-szorosára nőtt.
Érdemes megjegyezni, hogy ilyen kiemelkedő eredményt nem mindig lehet elérni. Egyes esetekben a teljesítmény csökken, ezért érdemes minden esetet értékelni.
Következtetésként elmondhatjuk, hogy a Wasm lehetőséget biztosít az alkalmazások teljesítményének javítására, de okosan kell használni.