Blockchain â en innovativ teknologi, der lover at forbedre mange omrĂ„der af menneskelivet. Den transporterer reale processer og produkter ind i det digitale rum, sikrer hastighed og pĂ„lidelighed i finansielle transaktioner, reducerer omkostningerne ved dem, og gĂžr det muligt at skabe moderne DAPP-applikationer med brug af intelligente kontrakter i decentraliserede netvĂŠrk.
I betragtning af de mange fordele og forskellige anvendelsesomrÄder, kan det synes mÊrkeligt, at denne lovende teknologi endnu ikke har trÊngt ind i alle brancher. Problemet er, at moderne decentraliserede blockchains mangler skalerbarhed. Ethereum behandler omkring 20 transaktioner i sekundet, hvilket er utilstrÊkkeligt til at imÞdekomme behovene i nutidens dynamiske erhvervsliv. Samtidig tÞver virksomheder, der anvender blockchain-teknologi, med at slippe Ethereum pÄ grund af dens hÞje grad af beskyttelse mod hacking og netvÊrksfejl.
For at sikre decentralisering, sikkerhed og skalerbarhed i blockchain og dermed lĂžse Skaleringsdilemmaet, har teamet udviklet Plasma Cash â en underkĂŠde, der bestĂ„r af en smart kontrakt og et privat netvĂŠrk baseret pĂ„ Node.js, som periodisk overfĂžrer sin tilstand til rodkĂŠden (Ethereum).
NĂžgleprocesser i Plasma Cash
1. Brugeren kalder smart kontraktens `deposit`-funktion ved at videregive det belĂžb i ETH, som han Ăžnsker at placere i Plasma Cash-tokenet. Smart kontraktens funktion skaber tokenet og genererer en begivenhed om dette.
2. Plasma Cash-noder, der er tilmeldt begivenhederne fra smart kontrakten, modtager begivenheden om oprettelsen af indbetalingen og tilfĂžjer transaktionen om oprettelsen af tokenet til puljen.
3. Periodisk tager sĂŠrlige Plasma Cash-noder alle transaktioner fra puljen (op til 1 million) og danner en blok ud fra dem, beregner Merkle-trĂŠet og dermed hash'en. Denne blok sendes til de andre noder til verifikation. Noderne kontrollerer, om Merkle-hash'en er gyldig, og om transaktionerne er gyldige (for eksempel, om afsenderen af tokenet er dens ejer). Efter verifikationen af blokken kalder noden smart kontraktens `submitBlock`-funktion, som gemmer bloknummeret og Merkle-hash'en i rodkĂŠden. Smart kontrakten genererer en begivenhed om den succesfulde tilfĂžjelse af blokken. Transaktionerne fjernes fra puljen.
4. Noder, der modtager begivenheden om block submission, begynder at anvende de transaktioner, der er blevet tilfĂžjet til blocket.
5. PĂ„ et tidspunkt Ăžnsker ejer (eller ikke ejer) af tokenet at trĂŠkke det tilbage fra Plasma Cash. For dette kalder han funktionen `startExit`, og sender de seneste 2 transaktioner om tokenet, som bekrĂŠfter, at han er ejer af tokenet. Smartkontrakten bruger Merkle-hash for at verificere, at transaktionerne findes i blokkene og sender tokenet til at blive trukket tilbage, hvilket vil ske om to uger.
6. Hvis tokenudtrĂŠkningen skete med overtrĂŠdelser (tokenet blev brugt efter proceduren for udtrĂŠkning startede, eller tokenet var allerede andres fĂžr udtrĂŠkning), kan tokenets ejer anfĂŠgte udtrĂŠkningen inden for to uger.
Privatliv opnÄs pÄ to mÄder
1. RodekĂŠden ved ikke noget om de transaktioner, der dannes og sendes inden for den underliggende kĂŠde. Information om, hvem der indsatte og trak ETH ind/ud af Plasma Cash, forbliver offentlig.
2. Den underliggende kĂŠde muliggĂžr anonyme transaktioner ved at bruge zk-SNARKs.
Teknologisk stack
- NodeJS
- Redis
- Etherium
- Soild
Testning
Ved udviklingen af Plasma Cash testede vi systemets hastighed og opnÄede fÞlgende resultater:
- op til 35.000 transaktioner pr. sekund tilfĂžjes til puljen;
- op til 1.000.000 transaktioner kan gemmes i en blok.
Testene blev udfÞrt pÄ de fÞlgende 3 servere:
1. Intel Core i7-6700 Quad-Core Skylake inkl. NVMe SSD â 512 GB, 64 GB DDR4 RAM
3 validerende Plasma Cash noder blev opsat.
2. AMD Ryzen 7 1700X Octa-Core «Summit Ridge» (Zen), SATA SSD â 500 GB, 64 GB DDR4 RAM
En Ropsten testnet ETH node blev opsat.
3 validerende Plasma Cash noder blev opsat.
3. Intel Core i9-9900K Octa-Core inkl. NVMe SSD â 1 TB, 64 GB DDR4 RAM
1 submit Plasma Cash node blev opsat.
3 validerende Plasma Cash noder blev opsat.
Der blev kĂžrt en test for at tilfĂžje transaktioner til Plasma Cash netvĂŠrket.
I alt: 10 Plasma Cash noder i et privat netvĂŠrk.
Test 1
Der er en grÊnse pÄ 1 million transaktioner i en blok. Derfor bliver 1 million transaktioner fordelt pÄ 2 blokke (da systemet nÄr at tage nogle transaktioner og indsende dem, mens de sendes).
Ursprungligt tilstand: sidste blok #7; databasen gemte 1 million transaktioner og tokens.
00:00 â start af script til generation af transaktioner
01:37 â 1 million transaktioner er oprettet, og sending til noden er begyndt
01:46 â submit noden tog 240k transaktioner fra puljen og danner blok #8. Vi ser ogsĂ„, at 320k transaktioner tilfĂžjes til puljen pĂ„ 10 sekunder
01:58 â blok #8 er underskrevet og sendt til validering
02:03 â blok #8 er blevet valideret, og funktionen `submitBlock` i smartkontrakten er blevet kaldt med Merkle-hash og bloknummeret
02:10 â demo-scriptet er fĂŠrdigt og har sendt 1 million transaktioner pĂ„ 32 sekunder
02:33 â noderne begyndte at modtage information om, at blok #8 er blevet tilfĂžjet til den rod kĂŠde og begyndte at behandle 240.000 transaktioner
02:40 â 240.000 transaktioner blev fjernet fra puljen, som allerede er i blok #8
02:56 â submit-noden tog de resterende 760.000 transaktioner fra puljen og begyndte at beregne Merkle-hash og signere blok #9
03:20 â alle noder indeholder 1.240.000 transaktioner og tokens
03:35 â blok #9 er blevet signeret og sendes til validering i andre noder
03:41 â der opstod en netvĂŠrksfejl
04:40 â validering af blok #9 stoppede pĂ„ grund af timeout
04:54 â submit-noden tog de resterende 760.000 transaktioner fra puljen og begyndte at beregne Merkle-hash og signere blok #9
05:32 â blok #9 er blevet signeret og sendes til validering i andre noder
05:53 â blok #9 er blevet valideret og sendt til den rod kĂŠde
06:17 â noderne begyndte at modtage information om, at blok #9 er blevet tilfĂžjet til den rod kĂŠde, og de begyndte at behandle 760.000 transaktioner
06:47 â puljen er blevet renset for transaktioner, der er i blok #9
09:06 â alle noder indeholder 2 millioner transaktioner og tokens
Test 2
Der er en grÊnse pÄ 350.000 for blokken. Resultatet er 3 blokke.
Starttilstand: den sidste blok #9; der er gemt 2 millioner transaktioner og tokens i databasen
00:00 â scriptet til generering af transaktioner er allerede startet
00:44 â der er oprettet 1 million transaktioner, og sendingen til noden er startet
00:56 â submit-noden tog 320.000 transaktioner fra puljen og danner blok #10. Vi ser ogsĂ„, at 320.000 transaktioner tilfĂžjes til puljen pĂ„ 10 sekunder
01:12 â blok #10 er blevet signeret og sendes til de andre noder til validering
01:18 â demo-scriptet er fĂŠrdigt og har sendt 1 million transaktioner pĂ„ 34 sekunder
01:20 â blok #10 er blevet valideret og sendt til den rod kĂŠde
01:51 â alle noder har modtaget information fra den rod kĂŠde om, at blok #10 er blevet tilfĂžjet, og de begynder at anvende 320.000 transaktioner
02:01 â puljen er blevet renset for 320.000 transaktioner, der blev tilfĂžjet til blok #10
02:15 â submit-noden tog 350.000 transaktioner fra puljen og danner blok #11
02:34 â blok #11 er blevet signeret og sendes til de andre noder til validering
02:51 â blok #11 er blevet valideret og sendt til den rod kĂŠde
02:55 â den sidste node har udfĂžrt transaktionerne fra blok #10
10:59 â meget lang tid brugte den rod kĂŠde til at udfĂžre transaktionen med submission af blok #9, men den blev gennemfĂžrt, og alle noder fik information om det og begyndte at udfĂžre 350k transaktioner
11:05 â puljen blev ryddet med 320k transaktioner, som blev tilfĂžjet til blok #11
12:10 â alle noder indeholder 1 million 670k transaktioner og tokens
12:17 â submission noden tog 330k transaktioner fra puljen og danner blok #12
12:32 â blok #12 er underskrevet og sendes til andre noder til validering
12:39 â blok #12 er valideret og sendt til den rod kĂŠde
13:44 â alle noder har fĂ„et information fra den rod kĂŠde om, at blok #12 er tilfĂžjet, og begynder at anvende 330k transaktioner
14:50 â alle noder indeholder 2 millioner transaktioner og tokens
Test 3
PĂ„ den fĂžrste og anden server blev en valideringsnode udskiftet med en submissionsnode.
Starttilstand: sidste blok #84; 0 transaktioner og tokens er gemt i databasen
00:00 â 3 scripts er startet, som genererer og sender 1 million transaktioner
01:38 â 1 million transaktioner er oprettet, og sendingen til submissionsnode #3 er startet
01:50 â submissionsnode #3 tog 330k transaktioner fra puljen og danner blok #85 (f21). Vi ser ogsĂ„, at puljen tilfĂžjes med 350k transaktioner pĂ„ 10 sekunder
01:53 â 1 million transaktioner er oprettet, og sendingen til submissionsnode #1 er startet
01:50 â submissionsnode #3 tog 330k transaktioner fra puljen og danner blok #85 (f21). Vi ser ogsĂ„, at puljen tilfĂžjes med 350k transaktioner pĂ„ 10 sekunder
02:01 â submissionsnode #1 tog 250k transaktioner fra puljen og danner blok #85 (65e)
02:06 â blok #85 (f21) er underskrevet og sendes til andre noder til validering
02:08 â demo-scriptet pĂ„ server #3 er fĂŠrdigt, som har sendt 1 million transaktioner pĂ„ 30 sekunder
02:14 â blok #85 (f21) er valideret og sendt til den rod kĂŠde
02:19 â blok #85 (65e) er underskrevet og sendes til andre noder til validering
02:22 â 1 million transaktioner er oprettet, og sendingen til submissionsnode #2 er startet
02:27 â blok #85 (65e) er valideret og sendt til den rod kĂŠde
02:29 â submissionsnode #2 tog 111855 transaktioner fra puljen og danner blok #85 (256).
02:36 â blok #85 (256) er underskrevet og sendes til andre noder til validering
02:36 â demo-scriptet pĂ„ server #1 er fĂŠrdigt, som har sendt 1 million transaktioner pĂ„ 42.5 sekunder
02:38 â blok #85 (256) er valideret og sendt til den rod kĂŠde
03:08 â demo-scriptet pĂ„ server #2 er fĂŠrdigt, som har sendt 1 million transaktioner pĂ„ 47 sekunder
03:38 â alle noder har fĂ„et information fra den rod kĂŠde om, at blokke #85 (f21), #86(65e), #87(256) er tilfĂžjet, og begynder at anvende 330k, 250k, 111855 transaktioner
03:49 â puljen er blevet renset for 330k, 250k, 111855 transaktioner, som blev tilfĂžjet til blokke #85 (f21), #86(65e), #87(256)
03:59 â submission node #1 har taget 888145 transaktioner fra puljen og danner blok #88 (214), submission node #2 har taget 750k transaktioner fra puljen og danner blok #88 (50a), submission node #3 har taget 670k transaktioner fra puljen og danner blok #88 (d3b)
04:44 â blok #88 (d3b) er blevet underskrevet og sendes til de andre noder for validering
04:58 â blok #88 (214) er blevet underskrevet og sendes til de andre noder for validering
05:11 â blok #88 (50a) er blevet underskrevet og sendes til de andre noder for validering
05:11 â blok #85 (d3b) er blevet valideret og sendt til den primĂŠre kĂŠde
05:36 â blok #85 (214) er blevet valideret og sendt til den primĂŠre kĂŠde
05:43 â alle noder har modtaget information fra den primĂŠre kĂŠde om, at blokke #88 (d3b), #89(214) er blevet tilfĂžjet og begynder at anvende 670k, 750k transaktioner
06:50 â pĂ„ grund af forbindelsesafbrydelse er blok #85 (50a) ikke blevet valideret
06:55 â submission node #2 har taget 888145 transaktioner fra puljen og danner blok #90 (50a)
08:14 â blok #90 (50a) er blevet underskrevet og sendes til de andre noder for validering
09:04 â blok #90 (50a) er blevet valideret og sendt til den primĂŠre kĂŠde
11:23 â alle noder har modtaget information fra den primĂŠre kĂŠde om, at blok #90 (50a) er blevet tilfĂžjet, og begynder at anvende 888145 transaktioner. Imens har server #3 lĂŠnge vĂŠret i gang med at anvende transaktioner fra blokke #88 (d3b), #89(214)
12:11 â alle puljer er tomme
13:41 â alle noder pĂ„ server #3 indeholder 3 millioner transaktioner og tokens
14:35 â alle noder pĂ„ server #1 indeholder 3 millioner transaktioner og tokens
19:24 â alle noder pĂ„ server #2 indeholder 3 millioner transaktioner og tokens
Hindringer
Under udviklingen af Plasma Cash stÞdte vi pÄ fÞlgende problemer, som vi gradvist har lÞst og stadig lÞser:
1. Konflikt mellem forskellige funktioner i systemet. For eksempel blokerede funktionen tilfĂžjelse af transaktioner til puljen operationen af submission og validering af blokke, og omvendt, hvilket fĂžrte til et fald i hastigheden.
2. Det var ikke klart, hvordan man kunne sende et stort antal transaktioner og samtidig minimere omkostningerne ved datatransmission.
3. Det var ikke klart, hvordan og hvor man skulle opbevare data for at opnÄ hÞje resultater.
4. Det var ikke klart, hvordan man skulle organisere netvÊrket mellem noderne, da stÞrrelsen pÄ en blok med 1 million transaktioner fylder omkring 100 Mb.
5. Arbejdet i enkelttrÄdet tilstand bryder forbindelsen mellem noderne, nÄr der udfÞres langvarige beregninger (for eksempel opbygning af Merkle-trÊet og beregning af dets hash).
Hvordan klarede vi alt dette?
Den fÞrste version af Plasma Cash-noden var en slags kombineret lÞsning, der kunne gÞre alt pÄ én gang: modtage transaktioner, indsende og validere blokke, og leverede API til dataadgang. Da NodeJS oprindeligt er enkelttrÄdet, blokerede den tunge funktion til beregning af Merkle-trÊet funktionen til at tilfÞje transaktioner. Vi sÄ to muligheder for at lÞse dette problem:
1. KĂžre flere NodeJS-processer, hvor hver udfĂžrer bestemte funktioner.
2. Brug af worker_threads og flytte udfÞrelsen af dele af koden til trÄde.
I sidste ende anvendte vi begge lĂžsninger samtidigt: vi delte logisk en node op i 3 dele, som kan arbejde separat, men samtidig synkront.
1. Indsendningsnode, som modtager transaktioner i puljen og hÄndterer oprettelse af blokke.
2. Valideringsnode, som verificerer validiteten af noderne.
3. API-node â leverer API til dataadgang.
Hver node kan tilsluttes via en unix socket gennem CLI.
Tunge operationer, sÄsom beregning af Merkle-trÊet, flyttede vi til en separat trÄd.
Dermed opnÄede vi normal drift af alle funktioner i Plasma Cash samtidigt og uden fejl.
SÄ snart systemet fungerede, begyndte vi at teste hastigheden, og desvÊrre fik vi utilfredsstillende resultater: 5 000 transaktioner pr. sekund og op til 50 000 transaktioner i en blok. Vi mÄtte finde ud af, hvad der var implementeret forkert.
For at starte testede vi kommunikationsmekanismen med Plasma Cash for at finde systemets maksimale kapacitet. Tidligere havde vi skrevet, at Plasma Cash-noden tilbyder unix socket-interface. Oprindeligt var det tekstbaseret, json objekter blev sendt ved hjĂŠlp af `JSON.parse()` og `JSON.stringify()`.
{
"action": "sendTransaction",
"payload":{
"prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
"prevBlock": 41,
"tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
"newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
"type": "pay",
"data": "",
"signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
}
}
Vi mÄlte hastigheden for overfÞrsel af sÄdanne objekter og fik ~ 130k pr. sekund. Vi prÞvede at erstatte standardfunktionerne til arbejde med json, men prÊstationen forbedredes ikke. MÄ vÊre, at V8-motoren er godt optimeret til disse operationer.
Arbejdet med transaktioner, tokens, blokke foregik gennem klasser. Da vi oprettede sÄdanne klasser, faldt prÊstationen med det halve, hvilket indikerer, at OOP ikke passer til os. Vi mÄtte omskrive alt til en ren funktionel tilgang.
Skrivning til databasen
Oprindeligt blev Redis valgt til datalagring som en af de mest effektive lĂžsninger, der opfylder vores krav: key-value lagring, arbejde med hash-tabeller, mĂŠngder. Vi kĂžrte redis-benchmark og fik ~80k operationer pr. sekund i tilstand 1 pipelining.
For hĂžj prĂŠstation har vi finjusteret Redis:
- Vi har etableret en unix socket-forbindelse.
- Vi har deaktiveret tilstandens gemmelse pÄ disk (for pÄlidelighed kan man sÊtte en replica op og gemme til disk i en separat Redis).
I Redis er et pool en hash-tabel, da vi har brug for muligheden for at hente alle transaktioner med en forespĂžrgsel og slette transaktioner enkeltvis. Vi prĂžvede at bruge en almindelig liste, men den fungerer langsommere ved udtrĂŠkning af hele listen.
Ved brug af standard NodeJS Redis-biblioteket fik vi en prÊstation pÄ 18k transaktioner pr. sekund. Hastigheden faldt med 9 gange.
Da benchmark viste os mulighederne klart 5 gange stĂžrre, begyndte vi at optimere. Vi skiftede bibliotek til ioredis og fik en prĂŠstation pĂ„ 25k pr. sekund. Vi tilfĂžjede transaktioner enkeltvis ved at bruge kommandoen `hset`. PĂ„ denne mĂ„de genererede vi mange forespĂžrgsler til Redis. Ideen opstod om at samle transaktioner i pakker og sende dem med Ă©n kommando `hmset`. Resultatet â 32k pr. sekund.
Af flere grunde, som vi vil beskrive nedenfor, arbejder vi med data ved hjÊlp af `Buffer`, og det viste sig, at hvis man oversÊtter det til tekst (`buffer.toString('hex')`) inden skrivning, kan man opnÄ ekstra prÊstation. PÄ denne mÄde lykkedes det at Þge hastigheden til 35k pr. sekund. PÄ nuvÊrende tidspunkt har vi besluttet at sÊtte yderligere optimering pÄ pause.
Vi mÄtte skifte til binÊr protokol, da:
1. Systemet beregner ofte hashes, signaturer osv., og til dette har det brug for data i `Buffer.
2. NÄr man sender mellem tjenester, vejer binÊre data mindre end tekst. For eksempel, nÄr man sender en blok med 1 million transaktioner, kan dataene i teksten tage over 300 megabyte.
3. Fortsat datakonvertering pÄvirker ydeevnen.
Derfor har vi baseret vores egen binĂŠre protokol til lagring og overfĂžrsel af data, udviklet med den fantastiske bibliotek `binary-data`.
Som resultat har vi fĂžlgende datastrukturer:
â Transaktion
```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),
}
```
â Blok
```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,
}
```
Med de almindelige kommandoer `BD.encode(block, Protocol).slice();` og ` BD.decode(buffer, Protocol)` konverterer vi data til `Buffer` til lagring i Redis eller for at sende til en anden node og hente data tilbage.
Vi har ogsÄ 2 binÊre protokoller til dataoverfÞrsel mellem tjenester:
â Protokol til interaktion med Plasma Node via unix socket
```json
{
type: BD.types.uint8,
messageId: BD.types.uint24le,
error: BD.types.uint8,
length: BD.types.uint24le,
payload: BD.types.buffer(({node}) => node.length)
}
```
hvor:
- `type` â den handling, der skal udfĂžres, f.eks. 1 â sendTransaction, 2 â getTransaction;
- `payload` â de data, der skal sendes til den tilsvarende funktion;
- `messageId` â id for beskeden, sĂ„ man kan identificere svaret.
â Protokol for interaktion mellem noder
```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)
}
```
hvor:
- `code` â koden for beskeden, f.eks. 6 â PREPARE_NEW_BLOCK, 7 â BLOCK_VALID, 8 â BLOCK_COMMIT;
- `versionProtocol` â versionen af protokollen, da der kan vĂŠre noder i netvĂŠrket med forskellige versioner, og de kan fungere forskelligt;
- `seq` â identifikatoren for beskeden;
- `countChunk` og `chunkNumber` nĂždvendige for at opdele store beskeder;
- `length` og `payload` lĂŠngden og selve dataene.
Da vi pÄ forhÄnd typeklassificerede dataene, fungerer det endelige system meget hurtigere end `rlp`-biblioteket fra Ethereum. DesvÊrre har vi ikke vÊret i stand til at droppe det endnu, da vi skal arbejde videre med smart-kontrakten, hvilket vi planlÊgger at gÞre i fremtiden.
Hvis vi har formÄet at nÄ en hastighed 35 000 af transaktioner pr. sekund, skal vi ogsÄ behandle dem inden for optimal tid. Da den omtrentlige tid til dannelse af en blok tager 30 sekunder, skal vi inkludere i blokken 1 000 000 transaktioner, hvilket betyder, at vi sender mere end 100 mb data.
Oprindeligt brugte vi `ethereumjs-devp2p`-biblioteket til at kommunikere mellem noderne, men det kunne ikke hÄndtere sÄ meget data. Derfor brugte vi `ws`-biblioteket og satte op for at sende binÊre data over websocket. SelvfÞlgelig stÞttede vi ogsÄ pÄ problemer med at sende store datapakker, men vi delte dem op i chunks, og nu er disse problemer lÞst.
Desuden krÊver dannelsen af Merkle-trÊet og beregningen af hash 1 000 000 transaktioner cirka 10 sekunder med kontinuerlig beregning. I denne tid fÞlger forbindelsen til alle noderne ofte med. Det blev besluttet at flytte denne beregning til en separat trÄd.
Konklusioner:
Faktisk er vores konklusioner ikke nye, men alligevel glemmer mange specialister dem under udviklingen.
- Brugen af funktionel programmering frem for objektorienteret programmering Ăžger ydeevnen.
- Monolit er dÄrligere end servicearkitektur for et performant system pÄ NodeJS.
- Brugen af `worker_threads` til tunge beregninger forbedrer systemets reaktivitet, isÊr ved hÄndtering af i/o-operationer.
- Unix-sockets er mere stabile og hurtigere end http-anmodninger.
- Hvis store data skal overfÞres hurtigt over netvÊrket, er det bedre at bruge websockets til at sende binÊre data opdelt i chunks, som kan sendes igen, hvis de ikke nÄr frem, og derefter samles til en enkelt meddelelse.
Vi inviterer dig til at besĂžge GitHub projektet:
Artiklen blev skrevet i samarbejde med Alexander Nashivan, seniorudvikler .
Kilde: habr.com
