Blockchain er nýstárleg tækni sem lofar að bæta mörg svið mannlífsins. Það flytur raunverulega ferla og vörur inn í stafræna rýmið, tryggir hraða og áreiðanleika fjármálaviðskipta, dregur úr kostnaði þeirra og gerir þér einnig kleift að búa til nútíma DAPP forrit með því að nota snjalla samninga í dreifðri netkerfum.
Í ljósi margra kosta og fjölbreyttra notkunar blockchain gæti það komið á óvart að þessi efnilega tækni hafi ekki enn náð sér á strik í öllum atvinnugreinum. Vandamálið er að nútíma dreifð blockchains skortir sveigjanleika. Ethereum vinnur um 20 viðskipti á sekúndu, sem er ekki nóg til að mæta þörfum öflugra fyrirtækja í dag. Á sama tíma eru fyrirtæki sem nota blockchain tækni hik við að yfirgefa Ethereum vegna mikillar verndar gegn reiðhestur og netbilunum.
Til að tryggja valddreifingu, öryggi og sveigjanleika í blockchain og leysa þannig Scalability Trilemma, þróunarteymið búið til Plasma Cash, dótturfyrirtækiskeðju sem samanstendur af snjöllum samningi og einkaneti byggt á Node.js, sem flytur ástand sitt reglulega yfir í rótarkeðjuna (Ethereum).
Lykilferli í Plasma Cash
1. Notandinn kallar snjallsamningsaðgerðina „innborgun“ og lætur inn í hana upphæð ETH sem hann vill leggja inn á Plasma Cash táknið. Snjallsamningsaðgerðin býr til tákn og býr til viðburð um það.
2. Plasma Cash hnúðar sem eru áskrifendur að snjallsamningsviðburðum fá viðburð um að búa til innborgun og bæta við færslu um að búa til tákn í laugina.
3. Reglulega taka sérstakir Plasma Cash hnúðar allar færslur úr lauginni (allt að 1 milljón) og mynda blokk úr þeim, reikna Merkle tréð og, í samræmi við það, kjötkássa. Þessi blokk er send til annarra hnúta til staðfestingar. Hnútarnir athuga hvort Merkle hassið sé gilt og hvort viðskiptin séu gild (til dæmis hvort sendandi táknsins sé eigandi þess). Eftir að hafa staðfest blokkina kallar hnúturinn á "submitBlock" fall snjallsamningsins, sem vistar blokkanúmerið og Merkle kjötkássa í brúnkeðjunni. Snjallsamningurinn býr til atburð sem gefur til kynna árangursríka viðbót við blokk. Viðskipti eru fjarlægð úr lauginni.
4. Hnútar sem taka á móti blokkasendingarviðburðinum byrja að beita færslunum sem var bætt við blokkina.
5. Á einhverjum tímapunkti vill eigandi (eða ekki eigandi) táknsins taka það út úr Plasma Cash. Til að gera þetta kallar hann á `startExit` aðgerðina og sendir inn í hana upplýsingar um síðustu 2 viðskiptin á tákninu, sem staðfesta að hann sé eigandi táknsins. Snjallsamningurinn, með Merkle kjötkássa, athugar tilvist viðskipta í blokkunum og sendir táknið til afturköllunar, sem mun eiga sér stað eftir tvær vikur.
6. Ef afturköllun táknsins átti sér stað með brotum (tákninu var eytt eftir að afturköllunarferlið hófst eða táknið var þegar einhvers annars fyrir afturköllun), getur eigandi táknsins hafnað afturkölluninni innan tveggja vikna.
Persónuvernd er náð á tvo vegu
1. Rótakeðjan veit ekkert um færslurnar sem myndast og framsenda innan undirkeðjunnar. Upplýsingar um hver lagði inn og tók ETH út úr Plasma Cash eru áfram opinberar.
2. Barnakeðjan leyfir nafnlaus viðskipti með zk-SNARK.
Tæknistafla
- NodeJS
- Redis
- Eteríum
- Sild
Prófun
Við þróun Plasma Cash prófuðum við hraða kerfisins og fengum eftirfarandi niðurstöður:
- allt að 35 færslur á sekúndu bætast við hópinn;
- Hægt er að geyma allt að 1 færslur í blokk.
Prófanir voru gerðar á eftirfarandi 3 netþjónum:
1. Intel Core i7-6700 Quad-Core Skylake incl. NVMe SSD - 512 GB, 64 GB DDR4 vinnsluminni
3 sannprófandi Plasma Cash hnútar voru hækkaðir.
2. AMD Ryzen 7 1700X Octa-Core „Summit Ridge“ (Zen), SATA SSD – 500 GB, 64 GB DDR4 vinnsluminni
Ropsten testnet ETH hnúturinn var hækkaður.
3 sannprófandi Plasma Cash hnútar voru hækkaðir.
3. Intel Core i9-9900K Octa-Core inkl. NVMe SSD - 1 TB, 64 GB DDR4 vinnsluminni
1 Plasma Cash innsendingarhnútur var hækkaður.
3 sannprófandi Plasma Cash hnútar voru hækkaðir.
Próf var sett af stað til að bæta viðskiptum við Plasma Cash netið.
Samtals: 10 Plasma Cash hnútar í einkaneti.
Próf 1
Það eru 1 milljón færslur á hverri blokk. Þess vegna falla 1 milljón færslur í 2 blokkir (þar sem kerfið nær að taka hluta af færslunum og senda inn á meðan þær eru sendar).
Upphafsástand: síðasta blokk #7; 1 milljón færslur og tákn eru geymdar í gagnagrunninum.
00:00 — upphaf færslugerðarforskriftar
01:37 - 1 milljón færslur voru búnar til og sending á hnútinn hófst
01:46 — sendingarhnútur tók 240 færslur úr lauginni og eyðublaði blokk #8. Við sjáum líka að 320 þúsund færslum er bætt við hópinn á 10 sekúndum
01:58 — blokk #8 er undirritaður og sendur til staðfestingar
02:03 — blokk #8 er staðfest og „submitBlock“ fallið í snjallsamningnum er kallað með Merkle hassinu og blokkanúmerinu
02:10 — kynningarforritið lauk að virka, sem sendi 1 milljón færslur á 32 sekúndum
02:33 - hnútar fóru að fá upplýsingar um að blokk #8 væri bætt við rótarkeðjuna og fóru að framkvæma 240 þúsund viðskipti
02:40 - 240 þúsund færslur voru fjarlægðar úr lauginni, sem eru þegar í blokk #8
02:56 — sendingarhnútur tók 760 þúsund færslurnar sem eftir voru úr hópnum og byrjaði að reikna Merkle kjötkássa og undirskriftarblokk #9
03:20 - allir hnútar innihalda 1 milljón 240 þúsund færslur og tákn
03:35 — blokk #9 er undirritaður og sendur til staðfestingar á aðra hnúta
03:41 - netvilla kom upp
04:40 — bið eftir staðfestingu blokk #9 hefur runnið út
04:54 — sendingarhnútur tók 760 þúsund færslurnar sem eftir voru úr hópnum og byrjaði að reikna Merkle kjötkássa og undirskriftarblokk #9
05:32 — blokk #9 er undirritaður og sendur til staðfestingar á aðra hnúta
05:53 — blokk #9 er staðfest og send í rótarkeðjuna
06:17 - hnútar fóru að fá upplýsingar um að blokk #9 væri bætt við rótarkeðjuna og byrjaði að framkvæma 760 þúsund viðskipti
06:47 — laugin hefur hreinsað af viðskiptum sem eru í blokk #9
09:06 - allir hnútar innihalda 2 milljónir færslur og tákn
Próf 2
Það er hámark 350k á blokk. Þar af leiðandi höfum við 3 blokkir.
Upphafsástand: síðasta blokk #9; 2 milljónir færslur og tákn eru geymdar í gagnagrunninum
00:00 — færslumyndaforskrift hefur þegar verið hleypt af stokkunum
00:44 - 1 milljón færslur voru búnar til og sending á hnútinn hófst
00:56 — sendingarhnútur tók 320 færslur úr lauginni og eyðublaði blokk #10. Við sjáum líka að 320 þúsund færslum er bætt við hópinn á 10 sekúndum
01:12 — blokk #10 er undirritaður og sendur til annarra hnúta til staðfestingar
01:18 — kynningarforritið lauk að virka, sem sendi 1 milljón færslur á 34 sekúndum
01:20 — blokk #10 er staðfest og send í rótarkeðjuna
01:51 - allir hnútar fengu upplýsingar frá rótarkeðjunni um að blokk #10 væri bætt við og byrjaði að beita 320 þúsund færslum
02:01 - laugin hefur hreinsað fyrir 320 þúsund færslur sem bætt var við blokk #10
02:15 — sendingarhnútur tók 350 þúsund færslur úr hópnum og eyðublaðablokk #11
02:34 — blokk #11 er undirritaður og sendur til annarra hnúta til staðfestingar
02:51 — blokk #11 er staðfest og send í rótarkeðjuna
02:55 — síðasti hnúturinn kláraði færslur úr blokk #10
10:59 — viðskiptin með innsendingu á blokk #9 tóku mjög langan tíma í rótarkeðjunni, en henni var lokið og allir hnútar fengu upplýsingar um það og fóru að framkvæma 350 þúsund færslur
11:05 - laugin hefur hreinsað fyrir 320 þúsund færslur sem bætt var við blokk #11
12:10 - allir hnútar innihalda 1 milljón 670 þúsund færslur og tákn
12:17 — sendingarhnútur tók 330 þúsund færslur úr hópnum og eyðublaðablokk #12
12:32 — blokk #12 er undirritaður og sendur til annarra hnúta til staðfestingar
12:39 — blokk #12 er staðfest og send í rótarkeðjuna
13:44 - allir hnútar fengu upplýsingar frá rótarkeðjunni um að blokk #12 væri bætt við og byrjaði að beita 330 þúsund færslum
14:50 - allir hnútar innihalda 2 milljónir færslur og tákn
Próf 3
Í fyrsta og öðrum netþjóni var einum staðfestingarhnút skipt út fyrir sendandi hnút.
Upphafsástand: síðasta blokk #84; 0 færslur og tákn vistuð í gagnagrunninum
00:00 — 3 forskriftir hafa verið settar af stað sem búa til og senda 1 milljón færslur hvert
01:38 — 1 milljón færslur voru búnar til og sending til að senda inn hnút #3 hófst
01:50 — sendingarhnút #3 tók 330 þúsund færslur úr lauginni og myndaði blokk #85 (f21). Við sjáum líka að 350 þúsund færslum er bætt við hópinn á 10 sekúndum
01:53 — 1 milljón færslur voru búnar til og sending til að senda inn hnút #1 hófst
01:50 — sendingarhnút #3 tók 330 þúsund færslur úr lauginni og myndaði blokk #85 (f21). Við sjáum líka að 350 þúsund færslum er bætt við hópinn á 10 sekúndum
02:01 — sendu hnút #1 tók 250 þúsund færslur úr lauginni og eyðublaði #85 (65e)
02:06 — blokk #85 (f21) er undirritaður og sendur til annarra hnúta til staðfestingar
02:08 — kynningarforrit af þjóni #3, sem sendi 1 milljón færslur á 30 sekúndum, lauk að virka
02:14 — blokk #85 (f21) er staðfest og send í rótarkeðjuna
02:19 — blokk #85 (65e) er undirritaður og sendur til annarra hnúta til staðfestingar
02:22 — 1 milljón færslur voru búnar til og sending til að senda inn hnút #2 hófst
02:27 — blokk #85 (65e) staðfest og send í rótarkeðjuna
02:29 — sendu hnút #2 tók 111855 færslur úr lauginni og myndar blokk #85 (256).
02:36 — blokk #85 (256) er undirritaður og sendur til annarra hnúta til staðfestingar
02:36 — kynningarforrit af þjóni #1, sem sendi 1 milljón færslur á 42.5 sekúndum, lauk að virka
02:38 — blokk #85 (256) er staðfest og send í rótarkeðjuna
03:08 — handrit þjóns #2 lauk að virka, sem sendi 1 milljón færslur á 47 sekúndum
03:38 - allir hnútar fengu upplýsingar frá rótarkeðjunni sem blokkir #85 (f21), #86(65e), #87(256) var bætt við og fóru að beita 330k, 250k, 111855 færslum
03:49 - laugin var hreinsuð á 330k, 250k, 111855 færslum sem bætt var við blokkir #85 (f21), #86(65e), #87(256)
03:59 — sendu hnút #1 tók 888145 færslur úr hópnum og myndaði blokk #88 (214), sendu hnút #2 tók 750 þúsund færslur úr hópnum og myndaði blokk #88 (50a), sendu hnút #3 tók 670 þúsund færslur frá laugin og myndar blokk #88 (d3b)
04:44 — blokk #88 (d3b) er undirritaður og sendur til annarra hnúta til staðfestingar
04:58 — blokk #88 (214) er undirritaður og sendur til annarra hnúta til staðfestingar
05:11 — blokk #88 (50a) er undirritaður og sendur til annarra hnúta til staðfestingar
05:11 — blokk #85 (d3b) er staðfest og send í rótarkeðjuna
05:36 — blokk #85 (214) er staðfest og send í rótarkeðjuna
05:43 - allir hnútar fengu upplýsingar frá rótarkeðjunni sem blokkir #88 (d3b), #89(214) hafa verið bætt við og byrja að beita 670k, 750k færslum
06:50 — vegna samskiptabilunar var reit #85 (50a) ekki staðfest
06:55 — sendu hnút #2 tók 888145 færslur úr lauginni og eyðublaði #90 (50a)
08:14 — blokk #90 (50a) er undirritaður og sendur til annarra hnúta til staðfestingar
09:04 — blokk #90 (50a) er staðfest og send í rótarkeðjuna
11:23 - allir hnútar fengu upplýsingar frá rótarkeðjunni um að blokk #90 (50a) væri bætt við og byrja að beita 888145 færslum. Á sama tíma hefur þjónn #3 þegar beitt færslum úr blokkum #88 (d3b), #89(214)
12:11 - allar sundlaugar eru tómar
13:41 — allir hnútar á netþjóni #3 innihalda 3 milljónir færslur og tákn
14:35 — allir hnútar á netþjóni #1 innihalda 3 milljónir færslur og tákn
19:24 — allir hnútar á netþjóni #2 innihalda 3 milljónir færslur og tákn
Hindranir
Við þróun Plasma Cash lentum við í eftirfarandi vandamálum sem við leystum smám saman og erum að leysa:
1. Átök í samspili ýmissa kerfisaðgerða. Til dæmis hindraði aðgerðin að bæta viðskiptum við hópinn vinnu við að senda inn og staðfesta blokkir og öfugt, sem leiddi til hraðalækkunar.
2. Það var ekki strax ljóst hvernig á að senda gríðarlegan fjölda viðskipta á sama tíma og gagnaflutningskostnaður var lágmarkaður.
3. Ekki var ljóst hvernig og hvar ætti að geyma gögn til að ná háum árangri.
4. Ekki var ljóst hvernig ætti að skipuleggja net á milli hnúta, þar sem stærð blokkar með 1 milljón færslum tekur um 100 MB.
5. Með því að vinna í einsþræðisham rjúfa tengslin milli hnúta þegar langir útreikningar eiga sér stað (til dæmis, smíða Merkle tré og reikna kjötkássa þess).
Hvernig brugðumst við við þetta allt?
Fyrsta útgáfan af Plasma Cash hnútnum var eins konar sameining sem gat gert allt á sama tíma: samþykkja viðskipti, senda inn og staðfesta blokkir og útvega API til að fá aðgang að gögnum. Þar sem NodeJS er innfæddur einn-þráður, hindraði þunga Merkle tré reikniaðgerðin aðgerðina bæta við færslu. Við sáum tvo möguleika til að leysa þetta vandamál:
1. Ræstu nokkur NodeJS ferla, sem hver um sig framkvæmir sérstakar aðgerðir.
2. Notaðu worker_threads og færðu keyrslu hluta kóðans í þræði.
Fyrir vikið notuðum við báða valkostina á sama tíma: við skiptum einum hnút á rökréttan hátt í 3 hluta sem geta virkað sitt í hvoru lagi, en á sama tíma samstillt
1. Sendingarhnútur, sem tekur við færslum inn í laugina og býr til blokkir.
2. Staðfestingarhnútur sem athugar gildi hnúta.
3. API hnútur - býður upp á API til að fá aðgang að gögnum.
Í þessu tilviki geturðu tengst hverjum hnút í gegnum unix fals með því að nota cli.
Við færðum þungar aðgerðir, eins og að reikna Merkle-tréð, í sérstakan þráð.
Þannig höfum við náð eðlilegum rekstri allra Plasma Cash aðgerðir samtímis og án bilana.
Þegar kerfið var virkt byrjuðum við að prófa hraðann og fengum því miður ófullnægjandi niðurstöður: 5 færslur á sekúndu og allt að 000 færslur á blokk. Ég þurfti að finna út hvað var útfært rangt.
Til að byrja með byrjuðum við að prófa samskiptakerfi við Plasma Cash til að komast að hámarksgetu kerfisins. Við skrifuðum áðan að Plasma Cash hnúturinn býður upp á unix tengi. Upphaflega var það textabundið. json hlutir voru sendir með „JSON.parse()“ og „JSON.stringify()“.
```json
{
"action": "sendTransaction",
"payload":{
"prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
"prevBlock": 41,
"tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
"newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
"type": "pay",
"data": "",
"signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
}
}
```
Við mældum flutningshraða slíkra hluta og fundum ~ 130k á sekúndu. Við reyndum að skipta um staðlaðar aðgerðir fyrir að vinna með json, en árangur batnaði ekki. V8 vélin verður að vera vel fínstillt fyrir þessar aðgerðir.
Við unnum með færslur, tákn og blokkir í gegnum flokka. Þegar slíkir flokkar voru búnir til minnkaði árangurinn um 2 sinnum, sem bendir til þess að OOP henti okkur ekki. Ég þurfti að endurskrifa allt í eingöngu hagnýta nálgun.
Skráning í gagnagrunn
Upphaflega var Redis valið fyrir gagnageymslu sem ein afkastamesta lausnin sem uppfyllir kröfur okkar: lykilgildi geymsla, vinna með kjötkássatöflur, sett. Við settum af stað Redis-viðmið og fengum ~80 þúsund aðgerðir á sekúndu í 1 leiðsluham.
Fyrir mikla afköst stilltum við Redis betur:
- Unix tengi hefur verið komið á.
- Við slökktum á vistun ástandsins á disk (fyrir áreiðanleika geturðu sett upp eftirmynd og vistað á disk í sérstakri Redis).
Í Redis er laug kjötkássatafla því við þurfum að geta sótt allar færslur í einni fyrirspurn og eytt færslum í einu. Við reyndum að nota venjulegan lista, en það er hægara þegar búið er að afferma allan listann.
Þegar staðlað NodeJS var notað náðu Redis bókasöfnin 18 þúsund færslum á sekúndu. Hraðinn lækkaði 9 sinnum.
Þar sem viðmiðið sýndi okkur að möguleikarnir voru greinilega 5 sinnum meiri fórum við að hagræða. Við breyttum bókasafninu í ioredis og fengum frammistöðu upp á 25k á sekúndu. Við bættum viðskiptum við eitt í einu með því að nota 'hset' skipunina. Þannig að við vorum að búa til margar fyrirspurnir í Redis. Hugmyndin kom upp um að sameina viðskipti í lotur og senda þær með einni skipun `hmset`. Niðurstaðan er 32k á sekúndu.
Af nokkrum ástæðum, sem við munum lýsa hér að neðan, vinnum við með gögn með því að nota `Buffer` og eins og það kemur í ljós, ef þú breytir þeim í texta (`buffer.toString('hex')`) áður en þú skrifar, geturðu fengið fleiri frammistaða. Þannig var hraðinn aukinn í 35k á sekúndu. Í augnablikinu ákváðum við að fresta frekari hagræðingu.
Við þurftum að skipta yfir í tvíundarsamskiptareglur vegna þess að:
1. Kerfið reiknar oft kjötkássa, undirskriftir o.s.frv., og til þess þarf það gögn í `Buffer.
2. Þegar þau eru send á milli þjónustu vega tvöfaldur gögn minna en texti. Til dæmis, þegar þú sendir blokk með 1 milljón færslum, geta gögnin í textanum tekið meira en 300 megabæti.
3. Stöðugt umbreyting gagna hefur áhrif á frammistöðu.
Þess vegna tókum við okkar eigin tvöfalda siðareglur til grundvallar til að geyma og senda gögn, þróuð á grundvelli hins frábæra 'tvíundargagna' bókasafns.
Fyrir vikið fengum við eftirfarandi gagnaskipulag:
— Viðskipti
```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,
}
```
— Tákn
```json
{
id: BD.types.string(null),
owner: BD.types.buffer(20),
block: BD.types.uint24le,
amount: BD.types.string(null),
}
```
— Lokaðu
```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,
}
```
Með venjulegum skipunum `BD.encode(block, Protocol).slice();` og `BD.decode(buffer, Protocol)` umbreytum við gögnunum í `Buffer` til að vista í Redis eða áframsenda í annan hnút og sækja gögn til baka.
Við höfum líka 2 tvöfaldar samskiptareglur til að flytja gögn á milli þjónustu:
— Bókun um samskipti við Plasma Node í gegnum unix fals
```json
{
type: BD.types.uint8,
messageId: BD.types.uint24le,
error: BD.types.uint8,
length: BD.types.uint24le,
payload: BD.types.buffer(({node}) => node.length)
}
```
þar sem:
- „gerð“ — aðgerðin sem á að framkvæma, til dæmis, 1 — sendTransaction, 2 — getTransaction;
- 'burðarhlaða' — gögn sem þarf að senda til viðeigandi hlutverks;
- 'skilaboðaauðkenni' — auðkenni skilaboða svo hægt sé að bera kennsl á svarið.
— Bókun um samskipti milli hnúta
```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)
}
```
þar sem:
- `kóði` — skilaboðakóði, til dæmis 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
- 'versionProtocol' — útgáfa samskiptareglur, þar sem hægt er að hækka hnúta með mismunandi útgáfum á netinu og þeir geta virkað öðruvísi;
- 'seq' — auðkenni skilaboða;
- `countChunk` и `chunkNumber` nauðsynlegt til að skipta stórum skilaboðum;
- 'lengd' и 'burðarhlaða' lengd og gögnin sjálf.
Þar sem við slögðum inn gögnin er lokakerfið miklu hraðara en `rlp` bókasafn Ethereum. Því miður höfum við ekki enn getað hafnað því, þar sem nauðsynlegt er að ganga frá snjallsamningnum, sem við ætlum að gera í framtíðinni.
Ef okkur tókst að ná hraðanum 35 000 færslur á sekúndu, við þurfum líka að vinna úr þeim á besta tíma. Þar sem áætlaður blokkamyndunartími tekur 30 sekúndur, þurfum við að taka með í blokkina +1 000 000 XNUMX færslur, sem þýðir að senda meira 100 MB af gögnum.
Upphaflega notuðum við `ethereumjs-devp2p` bókasafnið til að hafa samskipti á milli hnúta, en það gat ekki séð um svo mikið af gögnum. Fyrir vikið notuðum við `ws` bókasafnið og stilltum sendingu tvöfaldra gagna í gegnum nettengi. Auðvitað lentum við líka í vandræðum við að senda stóra gagnapakka, en við skiptum þeim í bita og nú eru þessi vandamál horfin.
Einnig að mynda Merkle tré og reikna kjötkássa +1 000 000 XNUMX viðskipti krefjast um 10 sekúndur af samfelldum útreikningum. Á þessum tíma tekst tengingin við alla hnúta að rofna. Ákveðið var að færa þennan útreikning á sérstakan þráð.
Ályktanir:
Reyndar eru niðurstöður okkar ekki nýjar, en af einhverjum ástæðum gleyma margir sérfræðingar þeim þegar þeir þróa.
- Notkun hagnýtrar forritunar í stað hlutbundinnar forritunar bætir framleiðni.
- Einlitinn er verri en þjónustuarkitektúr fyrir afkastamikið NodeJS kerfi.
- Notkun `worker_threads` fyrir mikla útreikninga bætir viðbrögð kerfisins, sérstaklega þegar tekist er á við i/o aðgerðir.
- unix fals er stöðugri og hraðari en http beiðnir.
- Ef þú þarft að flytja stór gögn fljótt yfir netið er betra að nota veftengi og senda tvöfalda gögn, skipt í bita, sem hægt er að áframsenda ef þau berast ekki, og sameina síðan í eitt skilaboð.
Við bjóðum þér í heimsókn GitHub verkefni:
Greinin var skrifuð af Alexander Nashivan, eldri verktaki .
Heimild: www.habr.com