Plokiahel on uuenduslik tehnoloogia, mis tõotab parandada paljusid inimelu valdkondi. See toob reaalsed protsessid ja tooted digitaalsesse ruumi, tagab finantstehingute kiiruse ja usaldusväärsuse, vähendab nende maksumust ning võimaldab luua ka kaasaegseid DAPP-rakendusi kasutades nutikaid lepinguid detsentraliseeritud võrkudes.
Arvestades plokiahela paljusid eeliseid ja erinevaid rakendusi, võib tunduda kummaline, et see paljulubav tehnoloogia pole veel igasse tööstusharusse jõudnud. Probleem on selles, et kaasaegsetel detsentraliseeritud plokiahelatel puudub mastaapsus. Ethereum töötleb umbes 20 tehingut sekundis, millest ei piisa tänapäeva dünaamilise äri vajaduste rahuldamiseks. Samal ajal kõhklevad plokiahela tehnoloogiat kasutavad ettevõtted Ethereumist loobumisel selle kõrge kaitsetaseme tõttu häkkimise ja võrgutõrgete eest.
Plokiahela detsentraliseerimise, turvalisuse ja skaleeritavuse tagamiseks, lahendades sellega skaleeritavustrilemma, arendusmeeskond lõi Plasma Cash, alamahela, mis koosneb nutikast lepingust ja Node.js-il põhinevast privaatvõrgust, kandes perioodiliselt selle oleku üle juurahelasse (Ethereum).
Peamised protsessid Plasma Cashis
1. Kasutaja kutsub välja nutika lepingu funktsiooni "deposit", edastades ETH-s summa, mille ta soovib Plasma Cash märgisse paigutada. Nutika lepingu funktsioon loob märgi ja genereerib selle kohta sündmuse.
2. Nutikate lepingusündmustega tellitud Plasma Cashi sõlmed saavad sissemakse loomise sündmuse ja lisavad kogumisse loa loomise tehingu.
3. Spetsiaalsed Plasma Cashi sõlmed võtavad perioodiliselt kõik tehingud kogumist (kuni 1 miljon) ja moodustavad neist ploki, arvutavad Merkle'i puu ja vastavalt ka räsi. See plokk saadetakse kontrollimiseks teistele sõlmedele. Sõlmed kontrollivad, kas Merkle räsi on kehtiv, kas tehingud kehtivad (näiteks kas märgi saatja on selle omanik). Pärast ploki kontrollimist kutsub sõlm välja nutika lepingu funktsiooni "submitBlock", mis salvestab ploki numbri ja Merkle'i räsi kettahelasse. Nutikas leping genereerib sündmuse ploki eduka lisamise kohta. Tehingud eemaldatakse kogumist.
4. Ploki esitamise sündmuse saavad sõlmed hakkavad rakendama plokki lisatud tehinguid.
5. Mingil hetkel soovib märgi omanik (või mitteomanik) selle Plasma Cashist välja võtta. Selleks kutsub ta välja funktsiooni `startExit`, edastades sellele teabe 2 viimase tehingu kohta tokenil, mis kinnitavad, et ta on märgi omanik. Tark leping kontrollib Merkle räsi kasutades tehingute olemasolu plokkides ja saadab žetooni väljavõtmiseks, mis toimub kahe nädala pärast.
6. Kui žetooni väljavõtmise toiming toimus rikkumistega (märk kulutati pärast väljavõtmisprotseduuri algust või oli token juba enne väljavõtmist kellegi teise oma), saab märgi omanik kahe nädala jooksul tagasivõtmise ümber lükata.
Privaatsus saavutatakse kahel viisil
1. Juurkett ei tea alamahelas moodustatavatest ja saadetavatest tehingutest midagi. Teave selle kohta, kes Plasma Cashi ETH-d deponeeris ja sealt välja võttis, jääb avalikuks.
2. Alamkett võimaldab anonüümseid tehinguid zk-SNARK-ide abil.
Tehnoloogia virn
- NodeJS
- Redis
- Eeterium
- Muld
Katsetamine
Plasma Cashi arendamisel testisime süsteemi kiirust ja saime järgmised tulemused:
- basseini lisatakse kuni 35 000 tehingut sekundis;
- plokki saab salvestada kuni 1 000 000 tehingut.
Testid viidi läbi kolmes järgmises serveris:
1. Intel Core i7-6700 Quad-Core Skylake sh. NVMe SSD - 512 GB, 64 GB DDR4 RAM
Tõstetud on 3 valideerivat Plasma Cashi sõlme.
2. AMD Ryzen 7 1700X kaheksatuumaline "Summit Ridge" (Zen), SATA SSD - 500 GB, 64 GB DDR4 RAM
Ropsteni testneti ETH-sõlm on üles tõstetud.
Tõsteti üles 3 valideerivat Plasma Cashi sõlme.
3. Intel Core i9-9900K Octa-Core sh. NVMe SSD - 1 TB, 64 GB DDR4 RAM
Esitati 1 Plasma Cash sõlme taotlus.
Tõsteti üles 3 valideerivat Plasma Cashi sõlme.
Plasma Cashi võrku tehingute lisamiseks käivitati test.
Kokku: 10 Plasma Cash sõlme privaatvõrgus.
Test 1
Plokis on limiit 1 miljon tehingut. Seetõttu jaguneb 1 miljon tehingut 2 plokki (kuna süsteemil õnnestub osa tehingutest võtta ja need saatmise ajal esitada).
Algseisund: viimane plokk #7; Andmebaasis on salvestatud 1 miljon tehingut ja žetoon.
00:00 — tehingu genereerimise skripti käivitamine
01:37 — 1 miljon tehingut on loodud ja saatmine sõlme on alanud
01:46 — esitamissõlm võttis kogumist 240 8 tehingut ja vormis ploki nr 320. Samuti näeme, et 10 sekundiga lisatakse basseini XNUMX XNUMX tehingut
01:58 — plokk #8 allkirjastati ja saadeti kinnitamiseks
02:03 — plokk nr 8 on kinnitatud ja nutika lepingu funktsioon "submitBlock" kutsutakse välja Merkle räsi ja ploki numbriga
02:10 - demoskript lõpetas töö, mis saatis 1 miljon tehingut 32 sekundiga
02:33 - sõlmed hakkasid saama teavet, et plokk #8 lisati juurahelasse ja hakkasid täitma 240 XNUMX tehingut
02:40 - kogumist kustutati 240 8 tehingut, mis on juba plokis # XNUMX
02:56 — esitamissõlm võttis kogust ülejäänud 760 9 tehingut ja alustas Merkle räsi arvutamist ja allkirjastamisplokki #XNUMX
03:20 – kõik sõlmed sisaldavad 1 miljonit 240 XNUMX tehingut ja märki
03:35 — plokk #9 allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
03:41 - Ilmnes võrgutõrge
04:40 — ploki nr 9 kinnitamise ootamine peatus ajalõpu tõttu
04:54 — esitamissõlm võttis kogust ülejäänud 760 9 tehingut ja alustas Merkle räsi arvutamist ja allkirjastamisplokki #XNUMX
05:32 — plokk #9 allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
05:53 - plokk #9 on kinnitatud ja saadetakse juurahelasse
06:17 - sõlmed hakkasid saama teavet, et plokk #9 lisati juurahelasse ja hakkas täitma 760 XNUMX tehingut
06:47 - kogum kustutati tehingutest, mis on plokis #9
09:06 — kõik sõlmed sisaldavad 2 miljonit tehingut ja märki
Test 2
Piirang on 350 3 ploki kohta. Selle tulemusena on meil XNUMX plokki.
Algseisund: viimane plokk #9; Andmebaasis on salvestatud 2 miljonit tehingut ja žetoone
00:00 — tehingu genereerimise skript juba töötab
00:44 — 1 miljon tehingut on loodud ja saatmine sõlme on alanud
00:56 — esitamissõlm võttis kogumist 320 10 tehingut ja vormis ploki nr 320. Samuti näeme, et 10 sekundiga lisatakse basseini XNUMX XNUMX tehingut
01:12 — plokk #10 allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
01:18 - demoskript lõpetas töö, mis saatis 1 miljon tehingut 34 sekundiga
01:20 — plokk #10 on kinnitatud ja saadetud juurahelasse
01:51 - kõik sõlmed said juurahelalt teabe, et plokk #10 on lisatud, ja hakkavad rakendama 320 XNUMX tehingut
02:01 – kogum tühjendati 320 10 tehingu jaoks, mis lisati plokki nr XNUMX
02:15 — esitamissõlm võttis kogumist 350 11 tehingut ja vormiplokk nr XNUMX
02:34 — plokk #11 allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
02:51 — plokk #11 on kinnitatud ja saadetud juurahelasse
02:55 — viimane sõlm lõpetas tehingud plokist #10
10:59 - ploki nr 9 esitamisega tehing tehti juurahelas väga pikka aega, kuid see viidi lõpule ja kõik sõlmed said selle kohta teabe ja hakkasid täitma 350 XNUMX tehingut
11:05 – kogum tühjendati 320 11 tehingu jaoks, mis lisati plokki nr XNUMX
12:10 – kõik sõlmed sisaldavad 1 miljonit 670 XNUMX tehingut ja märki
12:17 — esitamissõlm võttis kogumist 330 12 tehingut ja vormiplokk nr XNUMX
12:32 — plokk #12 allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
12:39 — plokk #12 on kinnitatud ja saadetud juurahelasse
13:44 - kõik sõlmed said juurahelast teabe, et plokk #12 on lisatud ja hakkavad rakendama 330 XNUMX tehingut
14:50 — kõik sõlmed sisaldavad 2 miljonit tehingut ja märki
Test 3
Esimeses ja teises serveris asendati üks valideerimissõlm esitamissõlmega.
Algseisund: viimane plokk #84; Andmebaasi salvestatakse 0 tehingut ja žetoone
00:00 – käivitatakse 3 skripti, millest igaüks genereerib ja saadab 1 miljon tehingut
01:38 — 1 miljon tehingut on loodud ja saatmine sõlmele #3 on alanud
01:50 — esitamissõlm #3 võttis kogumist 330 85 tehingut ja vormiplokk #21 (f350). Samuti näeme, et 10 XNUMX tehingut lisatakse basseini XNUMX sekundiga
01:53 — 1 miljon tehingut on loodud ja saatmine sõlmele #1 on alanud
01:50 — esitamissõlm #3 võttis kogumist 330 85 tehingut ja vormiplokk #21 (f350). Samuti näeme, et 10 XNUMX tehingut lisatakse basseini XNUMX sekundiga
02:01 — esitamissõlm nr 1 võttis kogumist 250 85 tehingut ja vormiplokk nr 65 (XNUMXe)
02:06 — plokk #85 (f21) allkirjastatakse ja saadetakse kinnitamiseks teistele sõlmedele
02:08 — serveri demoskript nr 3 lõpetas töö, mis saatis 1 sekundiga 30 miljon tehingut
02:14 — plokk #85 (f21) on kinnitatud ja saadetud juurahelasse
02:19 — plokk #85 (65e) allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
02:22 — 1 miljon tehingut on loodud ja saatmine sõlmele #2 on alanud
02:27 — plokk #85 (65e) valideeritud ja saadetud juurahelasse
02:29 — esitamissõlm #2 võttis kogumist 111855 tehingut ja vormiplokk #85 (256).
02:36 — plokk #85 (256) allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
02:36 — serveri demoskript nr 1 lõpetas töö, mis saatis 1 sekundiga 42.5 miljon tehingut
02:38 — plokk #85 (256) on kinnitatud ja saadetud juurahelasse
03:08 — serveri skriptijuhtum #2 lõpetas töö, mis saatis 1 sekundiga 47 miljon tehingut
03:38 — kõik sõlmed said juurahelast informatsiooni, et plokid #85 (f21), #86(65e), #87(256) on lisatud ja hakkavad rakendama 330k, 250k, 111855 tehinguid
03:49 — kogum tühjendati 330 250, 111855 85, 21 86 tehingu jaoks, mis lisati plokkidesse #65 (f87), #256(XNUMXe), #XNUMX(XNUMX)
03:59 — esitamissõlm #1 võttis kogumist 888145 tehingut ja vormiplokk #88 (214), esitamissõlm #2 võttis kogumist 750 88 tehingut ja vormiplokk #50 (3a), esitamissõlm #670 võttis 88 3 tehingut bassein ja vormiplokk nr XNUMX (dXNUMXb)
04:44 — plokk #88 (d3b) allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
04:58 — plokk #88 (214) allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
05:11 — plokk #88 (50a) allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
05:11 — plokk #85 (d3b) on kinnitatud ja saadetud juurahelasse
05:36 — plokk #85 (214) on kinnitatud ja saadetud juurahelasse
05:43 — kõik sõlmed said juurahelalt informatsiooni, et plokid #88 (d3b), #89(214) on lisatud ja hakkavad rakendama 670k, 750k tehinguid
06:50 — plokk #85 (50a) jäi ühenduse katkemise tõttu valideerimata
06:55 — esitamissõlm #2 võttis kogumist 888145 tehingut ja vormiplokk #90 (50a)
08:14 — plokk #90 (50a) allkirjastatakse ja saadetakse valideerimiseks teistele sõlmedele
09:04 — plokk #90 (50a) on kinnitatud ja saadetud juurahelasse
11:23 - kõik sõlmed said juurahelast teabe, et plokk #90 (50a) on lisatud, ja hakkavad rakendama 888145 tehinguid. Samal ajal on server #3 pikka aega rakendanud tehinguid plokkidest #88 (d3b), #89(214)
12:11 - kõik basseinid on tühjad
13:41 - kõik serveri nr 3 sõlmed sisaldavad 3 miljonit tehingut ja žetoone
14:35 - kõik serveri nr 1 sõlmed sisaldavad 3 miljonit tehingut ja žetoone
19:24 - kõik serveri nr 2 sõlmed sisaldavad 3 miljonit tehingut ja žetoone
Takistused
Plasma Cashi arendamisel puutusime kokku järgmiste probleemidega, mida järk-järgult lahendasime ja lahendame:
1. Süsteemi erinevate funktsioonide interaktsiooni konflikt. Näiteks blokeeris tehingute basseini lisamise funktsioon plokkide esitamise ja kinnitamise töö ning vastupidi, mis tõi kaasa kiiruse languse.
2. Kohe polnud selge, kuidas saata tohutult palju tehinguid ja samal ajal minimeerida andmeedastuskulusid.
3. Ei olnud selge, kuidas ja kuhu andmeid salvestada, et saavutada kõrgeid tulemusi.
4. Polnud selge, kuidas sõlmede vahel võrku korraldada, kuna ploki suurus 1 miljoni tehinguga võtab umbes 100 MB.
5. Ühe lõimega režiimis töötamine katkestab sõlmedevahelise ühenduse, kui tegemist on pikkade arvutustega (näiteks Merkle puu ehitamine ja selle räsi arvutamine).
Kuidas me selle kõigega hakkama saime?
Plasma Cashi sõlme esimene versioon oli omamoodi kombain, mis suutis teha kõike korraga: aktsepteerida tehinguid, esitada ja kinnitada plokke ning pakkuda andmetele juurdepääsu API-d. Kuna NodeJS on algselt ühelõimeline, blokeeris raske Merkle puu arvutamise funktsioon tehingu lisamise funktsiooni. Oleme sellele probleemile näinud kahte lahendust:
1. Käivitage mitu NodeJS-i protsessi, millest igaüks täidab teatud funktsioone.
2. Kasutage faili worker_threads ja teisaldage osa koodi täitmine lõimedesse.
Selle tulemusena kasutasime mõlemat võimalust korraga: jagasime ühe sõlme loogiliselt 3 osaks, mis võivad töötada eraldi, kuid samal ajal sünkroonselt
1. Esitage sõlm, mis aktsepteerib kogumi tehinguid ja loob plokke.
2. Valideeriv sõlm, mis kontrollib sõlmede kehtivust.
3. API-sõlm – pakub andmetele juurdepääsu API-d.
Samal ajal saate iga sõlmega ühenduse luua unixi pistikupesa kaudu, kasutades cli.
Rasked toimingud, nagu Merkle puu arvutamine, liikusime eraldi lõime juurde.
Seega oleme saavutanud kõigi Plasma Cashi funktsioonide normaalse töö üheaegselt ja tõrgeteta.
Niipea kui süsteem oli töökorras, alustasime kiiruse testimisega ja kahjuks saime ebarahuldavaid tulemusi: 5 tehingut sekundis ja kuni 000 50 tehingut ploki kohta. Pidin välja selgitama, mida valesti rakendati.
Alustuseks alustasime Plasma Cashiga suhtlemise mehhanismi testimist, et välja selgitada süsteemi tippvõimekus. Varem kirjutasime, et Plasma Cashi sõlm pakub unixi pistikupesa liidest. Algselt oli see tekst. json-objektid saadeti funktsioonide „JSON.parse()” ja „JSON.stringify()” abil.
```json
{
"action": "sendTransaction",
"payload":{
"prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
"prevBlock": 41,
"tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
"newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
"type": "pay",
"data": "",
"signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
}
}
```
Mõõtsime selliste objektide edastuskiirust ja saime ~ 130k sekundis. Proovisime jsoniga töötamiseks standardfunktsioone asendada, kuid jõudlus ei paranenud. V8 mootor peab olema nende toimingute jaoks hästi optimeeritud.
Töötasime tehingute, žetoonide, plokkidega läbi klasside. Selliste klasside loomisel langes jõudlus 2 korda, mis näitab, et OOP meile ei sobi. Pidin kõik puhtalt funktsionaalsele lähenemisele ümber kirjutama.
Salvestamine andmebaasi
Algselt valiti Redis andmete salvestamiseks üheks produktiivsemaks lahenduseks, mis vastab meie nõudmisele: võtme-väärtuste salvestamine, töö räsitabelitega, komplektidega. Käitasime redis-benchmarki ja saime 80 konveierirežiimis ~1 XNUMX toimingut sekundis.
Suure jõudluse tagamiseks häälestasime Redise täpsemini:
- Loodud unixi pistikupesa ühendus.
- Keelatud kettale salvestamise olek (usaldusväärsuse huvides saate seadistada koopia ja salvestada kettale eraldi Redis).
Redis on kogum räsitabel, kuna vajame võimalust saada kõik tehingud ühe päringuga ja kustutada tehingud ükshaaval. Proovisime kasutada tavalist loendit, kuid see töötab kogu loendi mahalaadimisel aeglasemalt.
Standardse NodeJS-i kasutamisel saavutasid Redise teegid 18 9 tehingut sekundis. Kiirus langes XNUMX korda.
Kuna võrdlusnäitaja näitas meile võimalusi selgelt 5 korda rohkem, hakkasime optimeerima. Vahetasime raamatukogu ioredise vastu ja saime jõudluseks 25k sekundis. Lisasime tehingud ükshaaval käsu `hset` abil. Seega genereerisime Redises palju päringuid. Tekkis idee ühendada tehingud pakkidena ja saata need ühe `hmset` käsuga. Tulemuseks on 32k sekundis.
Mitmel põhjusel, mida me allpool kirjeldame, töötame andmetega puhvri abil ja nagu selgus, kui tõlgime need enne kirjutamist tekstiks (`buffer.toString('hex')`), saame täiendavaid andmeid. esitus. Seega tõsteti kiirus 35k-ni sekundis. Hetkel otsustasime edasise optimeerimise peatada.
Pidime binaarprotokollile üle minema, kuna:
1. Süsteem arvutab sageli räsi, signatuure jne ning selleks on vaja andmeid puhvris.
2. Teenuste vahel saatmisel kaaluvad binaarandmed tekstist vähem. Näiteks 1 miljoni tehinguga ploki saatmisel võivad tekstis olevad andmed võtta rohkem kui 300 megabaiti.
3. Pidev andmete teisendamine mõjutab jõudlust.
Seetõttu võtsime aluseks meie enda binaarandmete salvestamise ja edastusprotokolli, mis on välja töötatud imelise binaarandmete raamatukogu põhjal.
Selle tulemusena on meil järgmised andmestruktuurid:
— Tehing
```json
{
prevHash: BD.types.buffer(20),
prevBlock: BD.types.uint24le,
tokenId: BD.types.string(null),
type: BD.types.uint8,
newOwner: BD.types.buffer(20),
dataLength: BD.types.uint24le,
data: BD.types.buffer(({current}) => current.dataLength),
signature: BD.types.buffer(65),
hash: BD.types.buffer(32),
blockNumber: BD.types.uint24le,
timestamp: BD.types.uint48le,
}
```
— Token
```json
{
id: BD.types.string(null),
owner: BD.types.buffer(20),
block: BD.types.uint24le,
amount: BD.types.string(null),
}
```
— Blokeeri
```json
{
number: BD.types.uint24le,
merkleRootHash: BD.types.buffer(32),
signature: BD.types.buffer(65),
countTx: BD.types.uint24le,
transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
timestamp: BD.types.uint48le,
}
```
Tavaliste käskudega `BD.encode(block, Protocol).slice();` ja `BD.decode(buffer, Protocol)` teisendame andmed puhvrisse, et salvestada need Redisesse või saata teise sõlme ja hankige andmed tagasi.
Meil on ka 2 binaarprotokolli andmete edastamiseks teenuste vahel:
- Protokoll Plasma Node'iga suhtlemiseks unixi pesa kaudu
```json
{
type: BD.types.uint8,
messageId: BD.types.uint24le,
error: BD.types.uint8,
length: BD.types.uint24le,
payload: BD.types.buffer(({node}) => node.length)
}
```
kus:
- `tüüp ' - teostatav toiming, näiteks 1 - sendTransaction, 2 - getTransaction;
- `kasutav koormus` - vastavale funktsioonile edastatavad andmed;
- 'messageId' — sõnumi ID, et vastust oleks võimalik tuvastada.
— Sõlmedevahelise interaktsiooni protokoll
```json
{
code: BD.types.uint8,
versionProtocol: BD.types.uint24le,
seq: BD.types.uint8,
countChunk: BD.types.uint24le,
chunkNumber: BD.types.uint24le,
length: BD.types.uint24le,
payload: BD.types.buffer(({node}) => node.length)
}
```
kus:
- `kood` - sõnumi kood, näiteks 6 - PREPARE_NEW_BLOCK, 7 - BLOCK_VALID, 8 - BLOCK_COMMIT;
- 'versionProtocol' - protokolli versioon, kuna võrku saab tõsta erinevate versioonidega sõlmi ja need võivad töötada erinevalt;
- `järg` — sõnumi identifikaator;
- `countChunk` и 'chunkNumber' vajalik suurte sõnumite poolitamiseks;
- `pikkus` и `kasutav koormus` pikkus ja andmed ise.
Kuna me sisestasime andmed eelnevalt, on lõppsüsteem palju kiirem kui Ethereumi "rlp" teek. Kahjuks pole me saanud sellest veel loobuda, kuna vaja on viimistleda nutileping, mida plaanime ka edaspidi teha.
Kui meil õnnestuks kiirus saavutada 35 000 tehinguid sekundis, peame need ka optimaalse ajaga töötlema. Kuna ligikaudne ploki moodustamise aeg on 30 sekundit, peame plokki kaasama +1 000 tehinguid, mis tähendab rohkemate saatmist 100 mb andmed.
Algselt kasutasime sõlmede suhtlemiseks teeki `ethereumjs-devp2p', kuid see ei suutnud andmemahuga hakkama saada. Selle tulemusena kasutasime ws-teeki ja konfigureerisime binaarandmete edastamise veebipesa kaudu. Loomulikult tekkis meil probleeme ka suurte andmepakettide saatmisel, kuid jagasime need juppideks ja nüüd selliseid probleeme pole.
Samuti merkle puu moodustamine ja räsi arvutamine +1 000 tehingud nõuavad umbes 10 sekundit pidevat andmetöötlust. Selle aja jooksul on ühendus kõigi sõlmedega aega katkeda. See arvutus otsustati viia eraldi lõime.
Järeldused:
Tegelikult pole meie leiud uued, kuid millegipärast unustavad paljud eksperdid need väljatöötamisel.
- Funktsionaalse programmeerimise kasutamine objektorienteeritud programmeerimise asemel parandab jõudlust.
- Monoliit on produktiivse NodeJS-süsteemi jaoks halvem kui teenusearhitektuur.
- Funktsiooni "worker_threads" kasutamine raskeks arvutuseks parandab süsteemi reageerimisvõimet, eriti kui tegemist on i/o-toimingutega.
- unixi pesa on stabiilsem ja kiirem kui http-päringud.
- Kui teil on vaja kiiresti üle võrgu edastada suuri andmeid, on parem kasutada veebipistikuid ja saata kahendandmed, mis on jagatud tükkideks, mida saab edastada, kui need ei jõua, ja seejärel üheks sõnumiks ühendada.
Kutsume teid külla GitHub projekt:
Artikkel on koostatud Aleksander Nashivan, vanemarendaja .
Allikas: www.habr.com