Pyetja mĂ« e zakonshme pĂ«r çdo sistem tĂ« distribuuar nga njĂ« specialist jo teknik Ă«shtĂ« âSa tps ka bllokada juaj?â. MegjithatĂ«, numri i dhĂ«nĂ« nĂ« pĂ«rgjigje zakonisht ka pak tĂ« bĂ«jĂ« me atĂ« qĂ« dĂ«shiron tĂ« dĂ«gjojĂ« pyetĂ«si. NĂ« tĂ« vĂ«rtetĂ«, ai dĂ«shiron tĂ« pyesĂ« âa pĂ«rshtatet bllokada juaj me kĂ«rkesat e mia tĂ« biznesitâ, dhe kĂ«to kĂ«rkesa nuk janĂ« njĂ« numĂ«r e vetme, por njĂ« grup kushtesh â kĂ«tu pĂ«rfshihet qĂ«ndrueshmĂ«ria e rrjetit, kĂ«rkesat pĂ«r pĂ«rfundim, madhĂ«sitĂ«, natyra e transaksioneve dhe shumĂ« parametra tĂ« tjerĂ«. KĂ«shtu qĂ« pĂ«rgjigjja nĂ« pyetjen âsa tpsâ nganjĂ«herĂ« do tĂ« jetĂ« e komplikuar dhe pothuajse kurrĂ« nuk do tĂ« jetĂ« e plotĂ«. NjĂ« sistem i distribuuar me dhjetĂ«ra dhe qindra nyjash qĂ« realizojnĂ« llogaritje tĂ« ndĂ«rlikuara mund tĂ« jetĂ« nĂ« njĂ« sĂ«rĂ« gjendjesh tĂ« ndryshme, tĂ« lidhura me gjendjen e rrjetit, pĂ«rmbajtjen e bllokadĂ«s, dĂ«shtimet teknike, problemet ekonomike, sulmet nĂ« rrjet dhe shumĂ« arsye tĂ« tjera. Faza nĂ« tĂ« cilat mund tĂ« ketĂ« probleme me performancĂ«n dallohen nga shĂ«rbimet tradicionale, dhe serveri i rrjetit tĂ« bllokadave Ă«shtĂ« njĂ« shĂ«rbim rrjeti qĂ« kombinon funksionalitetin e njĂ« baze tĂ« dhĂ«nash, serveri web dhe klient torrent, gjĂ« qĂ« e bĂ«n jashtĂ«zakonisht tĂ« ndĂ«rlikuar nĂ« aspektin e profilit tĂ« ngarkesĂ«s nĂ« tĂ« gjitha nĂ«n-sistemat: procesori, memoria, rrjeti, ruajtja.
Siç ndodhi, rrjetet e decentralizuara dhe bllokadat janë një software mjaft specifik dhe i pazakontë për zhvilluesit e software-ve të centralizuar. Prandaj, do të doja të theksoj aspektet e rëndësishme të performancës dhe qëndrueshmërisë së rrjeteve të decentralizuara, qasjet për matjen e tyre dhe identifikimin e pengesave. Ne do të shqyrtojmë probleme të ndryshme të performancës që kufizojnë shpejtësinë e shërbimit për përdoruesit e bllokadave dhe do të shënojmë karakteristikat që janë specifike për këtë lloj software-i.
Fazat e kërkesës për shërbim nga klienti i bllokadës
Për të folur me sinqeritet rreth cilësisë së çdo shërbimi disi kompleks, duhet të merret parasysh jo vetëm vlera mesatare, por edhe ato maksimale/minimale, medianat, percentilet. Teoretikisht, mund të flitet për 1000 tps në ndonjë blockchain, por nëse 900 transaksione u përfunduan me një shpejtësi të madhe, ndërsa 100 - "ngjiten" për disa sekonda, atëherë koha mesatare e mbledhur për të gjitha transaksionet nuk është një metrikë krejtësisht e sinqertë për klientin, i cili nuk mundi të përfundojë marrëveshjen për disa sekonda. "Gropat" temporale, të shkaktuara nga humbje rrethesh konsensusi ose ndarje të rrjetit, mund të dëmtojnë rëndë shërbimin, i cili në stendat testuese tregonte performancë të shkëlqyer.
Për të identifikuar këto bottlenecks është e nevojshme të kuptohet mirë fazat se kur një blockchain real mund të hasë vështirësi në shërbimin e përdoruesve. Le të përshkruajmë ciklin e dorëzimit dhe procesin e përpunimit të transaksioneve, si dhe marrjen e gjendjes së re të blockchain-it, nga e cila klienti mund të konfirmojë që transaksioni i tij është përpunuar dhe regjistruar.
- transaksioni formohet në klient
- transaksioni nënshkruhet në klient
- klienti zgjedh një nga nodet dhe i dërgon transaksionin e tij
- klienti regjistrohet për azhornimet e state database-it të nodit, duke pritur shfaqjen e rezultateve të përpunimit të transaksionit të tij
- noda shpërndan transaksionin në rrjetin p2p
- disa, ose një BP (prodhues bllokesh) procesojnë transaksionet e akumuluara, duke azhurnuar state database
- BP formon një bllok të ri, duke përpunuar numrin e nevojshëm të transaksioneve
- BP shpërndan bllokun e ri në rrjetin p2p
- blloku i ri dërgohet në nodën që kliente i drejtohet
- noda azhurnon state database
- noda sheh azhurnimin që i përket klientit dhe i dërgon atij një njoftim për transaksionin
Tani le ta njĂ«herĂ« nĂ« detaje kĂ«to etapa dhe tĂ« pĂ«rshkruajmĂ« problemet potenciale me performancĂ«n nĂ« çdo hap. Ndryshe nga sistemet e centralizuara, ne do tĂ« shqyrtojmĂ« gjithashtu ekzekutimin e kodit nĂ« klientĂ«t e rrjetit. Mjaft shpesh, kur matet tps, koha e procesimit tĂ« transaksioneve mblidhet nga nodet dhe jo nga klienti â kjo nuk Ă«shtĂ« krejtĂ«sisht e sinqertĂ«. Klienti nuk e ka problem sa shpejt node proceson transaksionin e tij, ajo qĂ« Ă«shtĂ« mĂ« e rĂ«ndĂ«sishme pĂ«r tĂ« Ă«shtĂ« momenti kur informacioni i saktĂ« mbi kĂ«tĂ« transaksion, i pĂ«rfshirĂ« nĂ« blockchain, do tĂ« jetĂ« nĂ« dispozicion pĂ«r tĂ«. Kjo metrikĂ« Ă«shtĂ« esencialisht koha e ekzekutimit tĂ« transaksionit. Kjo do tĂ« thotĂ« se klientĂ«t e ndryshĂ«m, edhe pse dĂ«rgojnĂ« njĂ« transaksion tĂ« njĂ«jtĂ«, mund tĂ« kenĂ« kohĂ« tĂ«rĂ«sisht tĂ« ndryshme, tĂ« cilat varen nga kanali, ngarkesa dhe afĂ«rsia e nodit, etj. Pra, Ă«shtĂ« thelbĂ«sore tĂ« matet kjo kohĂ« nĂ« klientĂ«, pasi ky Ă«shtĂ« parametri qĂ« duhet optimizuar.
PĂ«rgatitja e transaksionit nga ana e klientit
Le të fillojmë me dy pikët e para: transaksioni formohet dhe nënshkruhet nga klienti. Siç duket, kjo gjithashtu mund të jetë një ngushticë e performancës së blockchain nga perspektiva e klientit. Kjo është e pazakontë për shërbimet e centralizuara, të cilat i marrin për vete të gjitha llogaritë dhe operacionet me të dhëna, ndërsa klienti përgatit një kërkesë të shkurtër, e cila mund të kërkojë një volum të madh të dhënash ose llogaritjesh, duke marrë rezultatin e gatshëm. Në blockchain, kodi i klientit po bëhet gjithnjë e më i fuqishëm, ndërsa bërthama e blockchain-it po bëhet gjithnjë e më e lehtë, dhe detyrat masive të llogaritjes zakonisht u jepen softuerëve të klientit. Në blockchain ekzistojnë klientë që mund të përgatisin një transaksion për një kohë të gjatë (po flas për dëshmitë e ndryshme merkle, dëshmitë e shkurtëra, nënshkrimet threshold dhe operacione të tjera komplekse nga ana e klientit). Një shembull i mirë i verifikimit të lehtë on-chain dhe përgatitjes së rëndë të transaksionit nga ana e klientit është dëshmia e përkatësisë në një listë të bazuar në Merkle-tree, ja .
Po gjithashtu, nuk duhet harruar se kodi i klientit nuk dĂ«rgon thjesht transaksione nĂ« blockchain, por fillimisht kĂ«rkon gjendjen e blockchain-it â dhe kjo aktivitet mund tĂ« ndikojĂ« nĂ« ngarkesĂ«n e rrjetit dhe node-ve tĂ« blockchain-it. Prandaj, gjatĂ« marrjes sĂ« matjeve, do tĂ« ishte e arsyeshme tĂ« emuloni sa mĂ« saktĂ« tĂ« jetĂ« e mundur sjelljen e kodit tĂ« klientit. Edhe nĂ«se nĂ« blockchain-in tuaj ka klientĂ« normalĂ« tĂ« lehtĂ«, qĂ« vendosin njĂ« nĂ«nshkrim dixhital tĂ« zakonshĂ«m nĂ« njĂ« transaksion tĂ« thjeshtĂ« pĂ«r transferimin e ndonjĂ« asset-i, sasia e llogaritjeve nĂ« anĂ«n e klientit vazhdon tĂ« rritet çdo vit, algoritmet kriptografike po bĂ«hen mĂ« tĂ« forta, dhe kjo pjesĂ« e procesimit mund tĂ« shndĂ«rrohet nĂ« njĂ« bllokim tĂ« konsiderueshĂ«m nĂ« tĂ« ardhmen. Prandaj, jini tĂ« kujdesshĂ«m dhe mos e humbisni situatĂ«n kur nĂ« njĂ« transaksion qĂ« zgjat 3.5 sekonda, 2.5 sekonda shpenzohen pĂ«r pĂ«rgatitjen dhe nĂ«nshkrimin e transaksionit, dhe 1.0 sekondĂ« pĂ«r dĂ«rgimin nĂ« rrjet dhe pritjen e pĂ«rgjigjes. PĂ«r tĂ« vlerĂ«suar rreziqet e ndodhjes sĂ« kĂ«tij bllokimi, duhet tĂ« mblidhni metrika nga makinat e klientĂ«ve dhe jo vetĂ«m nga node-t e blockchain-it.
Dërgimi i transaksionit dhe monitorimi i statusit të tij
Hapi i ardhshëm është dërgimi i transaksionit në node-n e zgjedhur të blockchain-it dhe marrja e statusit për pranimin e tij në grupin e transaksioneve. Ky hap i ngjan një kërkese të zakonshme në një databazë; node-ja duhet të regjistrojë transaksionin në grupin dhe të fillojë të shpërndajë informacionin për të në rrjetin p2p. Qasja për vlerësimin e performancës këtu është e ngjashme me vlerësimin e punës së mikroshërbimeve tradicionale Web API, ndërsa vetë transaksionet në blockchain mund të përditësohen, duke ndryshuar statusin aktivisht. Në përgjithësi, përditësimi i informacionit për një transaksion në disa blockchain-e mund të ndodhë disa herë, për shembull, gjatë kalimeve mes bifurkime të zinxhirit ose kur BP njoftojnë se kanë për qëllim të përfshijnë transaksionin në bllok. Kufizimet mbi volumet e këtij grupi dhe numrin e transaksioneve në të mund të ndikojnë në performancën e blockchain-it. Nëse grupi i transaksioneve është mbushur deri në madhësinë maksimale të mundshme, ose nuk i përshtatet në memorjen e përkohshme - performanca e rrjetit mund të bjerë ndjeshëm. Blockchain-et nuk kanë mjete të centralizuara mbrojtjeje nga fluksi i mesazheve të plehrave, dhe nëse blockchain-i mbështet transaksione të volumit të madh me tarifa të ulëta, kjo mund të çojë në mbushjen e grupit të transaksioneve - ky është një tjetër bllokim potencial i performancës.
NĂ« blockchain-e, klienti dĂ«rgon njĂ« transaksion nĂ« çdo nodĂ« tĂ« blockchain-it qĂ« i pĂ«lqen, hash-i i transaksionit zakonisht Ă«shtĂ« e njohur pĂ«r klientin edhe para dĂ«rgimit, kĂ«shtu qĂ« gjithçka qĂ« i nevojitet â Ă«shtĂ« tĂ« arrijĂ« njĂ« lidhje dhe pas dĂ«rgimit tĂ« presĂ« kur blockchain-i tĂ« ndryshojĂ« gjendjen e tij, duke pĂ«rfshirĂ« transaksionin e tij. VĂ«rejmĂ« se duke matur "tps" mund tĂ« merrni rezultate krejt tĂ« ndryshme pĂ«r mĂ«nyra tĂ« ndryshme lidhjeje me nodĂ«n e blockchain-it. Kjo mund tĂ« jetĂ« njĂ« HTTP RPC i zakonshĂ«m ose WebSocket, i cili lejon realizimin e modelit "subscribe". NĂ« rastin e dytĂ«, klienti do tĂ« marrĂ« njoftimin mĂ« herĂ«t, ndĂ«rsa nodja do tĂ« harxhojĂ« mĂ« pak burime (pĂ«r kryesisht kujtesĂ« dhe trafik) nĂ« pĂ«rgjigjet mbi gjendjen e transaksionit. Pra, kur matni "tps", duhet tĂ« merrni parasysh mĂ«nyrĂ«n e lidhjes sĂ« klientĂ«ve me nodat. Prandaj, pĂ«r vlerĂ«simin e rreziqeve tĂ« shfaqjes sĂ« kĂ«tij bottleneck-u, benchmark-u i blockchain-it duhet tĂ« jetĂ« nĂ« gjendje tĂ« emulojĂ« klientĂ« me WebSocket dhe me kĂ«rkesa HTTP RPC, nĂ« proporcione qĂ« pĂ«rputhen me rrjetet reale, si dhe tĂ« ndryshojĂ« natyrĂ«n e transaksioneve dhe madhĂ«sinĂ« e tyre.
Për vlerësimin e rreziqeve të shfaqjes së këtij bottleneck-u është gjithashtu e nevojshme të mblidhni metrika nga makinat e klientëve, dhe jo vetëm nga nodat e blockchain-it.
Transferimi i transaksioneve dhe blloqeve përmes rrjetit p2p
NĂ« blockchain-e, pĂ«r transferimin mes pjesĂ«marrĂ«sve tĂ« transaksioneve dhe blloqeve pĂ«rdoret rrjetĂ«zim peer-to-peer (p2p). Transaksionet shpĂ«rndahen nĂ« rrjet, duke filluar nga njĂ« nga nodet, derisa tĂ« arrijnĂ« peer-at-produes tĂ« blloqeve, tĂ« cilĂ«t paketojnĂ« transaksionet nĂ« blloqe dhe, duke pĂ«rdorur tĂ« njĂ«jtin p2p, shpĂ«rndajnĂ« blloqet e reja nĂ« tĂ« gjitha nodat e rrjetit. Baza e shumicĂ«s sĂ« rrjeteve moderne p2p Ă«shtĂ« ndryshime tĂ« ndryshme tĂ« protokollit Kademlia. njĂ« pĂ«rmbledhje e shkurtĂ«r e kĂ«tij protokolli, dhe â njĂ« artikull me matje tĂ« ndryshme nĂ« rrjetin BitTorrent, nga i cili mund tĂ« kuptoni â se ky lloj rrjeti Ă«shtĂ« mĂ« i komplikuar, dhe mĂ« pak i parashikueshĂ«m se sa njĂ« rrjet i konfiguruar fort me njĂ« shĂ«rbim tĂ« centralizuar. Gjithashtu, njĂ« artikull mbi matjen e metrikave tĂ« ndryshme interesante pĂ«r nodat Ethereum.
Në thelb, çdo peer në këto rrjete mban listën e vet dinamike të peers të tjerë, nga të cilët kërkon blloqet e informacionit që i adresohen sipas përmbajtjes. Kur merr një kërkesë, peer ose jep informacionin e nevojshëm, ose e transmeton kërkesën te një peer tjetër pseudopasur nga lista, dhe pasi merr përgjigjen, ia kalon atë kërkuesit dhe për një periudhë të caktuar e ruan në cache, duke e ofruar këtë bllok informacioni më herët herën tjetër. Kështu, informacioni popullor gjendet në një numër të madh cache-esh te një numër të madh peers, ndërsa ai jo-popullor gradualisht zëvendësohet. Peers mbajnë një llogari se kush i kalon sa informacion, dhe rrjeti përpiqet të stimulojë ata që shpërndajnë aktivisht, duke rritur renditjen e tyre dhe duke u siguruar një nivel më të lartë shërbimi, duke përjashtuar automatikisht pjesëmarrësit inaktivë nga listat e peers.
Pra, tani duhet të përhapet transaksioni në rrjet që të shihet nga block-producer-ët dhe të përfshihet në bllok. Noda aktivisht "shpërndan" transaksionin e ri të gjithëve që dëshirojnë dhe dëgjon rrjetin, duke pritur bllokun, në indeksin e të cilit do të shfaqet transaksioni i nevojshëm për të njoftuar klientin që po pret. Koha ndërsa rrjeti kalon informacionin për transaksionet dhe blloqet e reja në rrjetet p2p varet nga një numër shumë të madh faktorësh: numri i nodave të ndershme që punojnë afër (në aspektin e rrjetit), "ngrohja" e cache-ve të këtyre nodave, përmasat e blloqeve, transaksioneve, natyra e ndryshimeve, gjeografia e rrjetit, numri i nodave dhe shumë faktorë të tjerë. Matjet komplekse të metrikes së performancës në këto rrjete janë një punë e komplikuar, është e nevojshme të vlerësohet njëkohësisht koha e përpunimit të kërkesave si për klientët ashtu edhe për peers (nodat e blockchain). Problemet në ndonjë nga mekanizmat p2p, ndërrimi i gabuar dhe ruajtja e të dhënave, menaxhimi joefikas i listave të peers aktivë, dhe shumë faktorë të tjerë mund të jenë shkak për vonesa që ndikojnë në efikasitetin e gjithë rrjetit si një e tërë, dhe ky bottleneck është më të vështirë për t'u analizuar, testuar dhe interpretuar rezultatet.
Procesimi i zinxhirit të blloqeve dhe përditësimi i databazës së gjendjes
Pjesa më e rëndësishme e funksionit të blockchain-it është algoritmi i konsensusit, aplikimi i tij në blloqet e reja, të marra nga rrjeti dhe procesi i transaksioneve me regjistrimin e rezultateve në bazën e të dhënave të shtetit. Shtimi i një blloku të ri në zinxhir dhe zgjedhja e zinxhirit kryesor që vjen pas duhet të ndodhin sa më shpejt të jetë e mundur. Sidoqoftë, në jetën reale, "duhet" nuk do të thotë "funksionon", dhe mund të imagjinoni një situatë kur dy zinxhirë konkurrues të gjatë kërcejnë vazhdimisht midis tyre, duke ndryshuar metadatën e mijëra transaksioneve në pool në çdo kalim dhe duke prodhuar rikthime të vazhdueshme të gjendjes së bazës së të dhënave. Ky fazë, në aspektin e identifikimit të ngushticës, është më e thjeshtë se shtresa p2p rrjetor, pasi ekzekutimi i transaksioneve dhe algoritmi i konsensusit janë tërësisht të determinuar, dhe është më e lehtë të matësh gjithçka këtu.
E rĂ«ndĂ«sishme Ă«shtĂ« tĂ« mos ngatĂ«rrohet degradimi rastĂ«sor i performancĂ«s nĂ« kĂ«tĂ« fazĂ« me problemet nĂ« rrjet â nodet japin mĂ« ngadalĂ« blloqe dhe informacion rreth zinxhirit kryesor dhe pĂ«r klientin e jashtĂ«m, kĂ«tĂ« mund ta duket si njĂ« rrjet i ngadalshĂ«m, ndonĂ«se problemi ndodhet krejtĂ«sisht nĂ« njĂ« vend tjetĂ«r.
Për optimizimin e performancës në këtë fazë, është e dobishme të mblidhen dhe monitorohen metrikat nga vetë nodet dhe të përfshihen ato që lidhen me përditësimin e bazës së të dhënave të shtetit: numri i blloqeve të procesuar në nod, madhësia e tyre, numri i transaksioneve, numri i alternimeve midis bifurkave të zinxhirit, numri i blloqeve të pavlefshme, koha e funksionimit të makinerisë virtuale, koha e regjistrimit të të dhënave dhe të tjera. Kjo do të ndihmojë për të mos ngatërruar problemet rrjetore me gabimet në algoritmet e procesimit të zinxhirëve.
Makina virtuale që proceson transaksionet mund të jetë një burim i dobishëm informacioni që mund të optimizojë funksionimin e blockchain-it. Sasia e alokimeve të memories, numri i instrukcioneve read/write dhe metrika të tjera që lidhen me efikasitetin e ekzekutimit të kodit të kontratave mund të japin shumë informacion të dobishëm për zhvilluesit. Në të njëjtën kohë, kontratat inteligjente janë programe dhe prandaj në teori ato mund të konsumojnë çdo burim: cpu/memory/network/storage, kështu që procesimi i transaksioneve është një fazë mjaft e pasigurt, e cila gjithashtu ndryshon ndjeshëm gjatë kalimit midis versioneve dhe gjatë ndryshimit të kodit të kontratave. Prandaj, metrikat që lidhen me procesimin e transaksioneve janë gjithashtu të nevojshme për optimizimin e efektivitetit të performancës së blockchain-it.
Marrja e njoftimit nga klienti për aktivizimin e transaksionit në blockchain
Ky është faza përfundimtare e marrjes së shërbimit nga klienti i blockchain-it, krahasuar me fazat e tjera, këtu nuk ka shpenzime të mëdha, por gjithsesi duhet marrë parasysh mundësia e marrjes së një përgjigjeje voluminoze nga nodi (p.sh. kontratë inteligjente që kthen një array të dhënash). Në çdo rast, ky moment është më i rëndësishëm për ata që kanë bërë pyetjen "sa tps ka blockchain-i juaj?", sepse këtu e regjistrohet koha e marrjes së shërbimit.
Në këtë pikë është e nevojshme të dërgohet koha totale që i është dashur klientit për të pritur përgjigjen nga blockchain-i, kjo është koha që përdoruesi do të presë për të marrë konfirmimin në aplikacionin e tij, dhe optimizimi i saj është detyra kryesore e zhvilluesve.
PĂ«rfundim
Si rezultat, mund të përshkruhen llojet e operacioneve që kryhen në blockchain dhe t'i ndahen në disa kategori:
- transformime kriptografike, ndërtimi i provave
- networking peer-to-peer, replikimi i transaksioneve dhe blloqeve
- procesimi i transaksioneve, ekzekutimi i kontratave inteligjente
- aplikimi i ndryshimeve në blockchain në bazën e të dhënave të gjendjes, përditësimi i të dhënave rreth transaksioneve dhe blloqeve
- kërkesa read-only në bazën e të dhënave të gjendjes, API e nodit blockchain, shërbimet e abonimit
Në përgjithësi, kërkesat teknike për nodet e blockchain-eve moderne janë jashtëzakonisht serioze - kërkohen CPU të shpejtë për kriptografinë, një sasi të madhe kujtesë të shpejtë për të ruajtur dhe aksesuar shpejt bazën e të dhënave të gjendjes, ndërveprimi në rrjet që përdor një numër të madh lidhjesh të hapura njëkohësisht, dhe hapësirë të madhe ruajtjeje. Këto kërkesa të larta dhe varieteti i llojeve të operacioneve do të sjellin domosdoshmërish që resurset e nodve të mos mjaftojnë, dhe në atë rast, çdo një nga fazat e shqikuara më sipër mund të bëhet një ngushticë tjetër për performancën e përgjithshme të rrjetit.
Kur zhvilloni dhe vlerësoni performancën e bllokadave, do t'ju duhet të merrni parasysh të gjitha këto aspekte. Për këtë, duhet të mblidhni dhe analizoni metrika njëkohësisht nga klientët dhe nodet e rrjetit, të kërkoni korrelacione midis tyre, të vlerësoni kohën e shërbimit për klientët, të merrni parasysh të gjithë burimet kryesore: cpu/memorie/rrjet/shërbim, të kuptoni si përdoren dhe ndikojnë njëri mbi tjetrin. Të gjitha këto e bëjnë krahasimin e shpejtësive të bllokadave të ndryshme në formën e "sa TPS" një detyrë jashtëzakonisht të pafalshme, pasi ekziston një sasi e madhe konfiguracionesh dhe gjendjesh të ndryshme. Në sisteme të mëdha të centralizuara, klastera me qindra serverë, këto probleme janë gjithashtu të komplikuara dhe kërkojnë mbledhjen e një numri të madh metricash të ndryshme, por në bllokada, për shkak të rrjeteve p2p, makina virtuale, kontraktesh procesi, ekonomi të brendshme, numri i gradave të lirisë është shumë më i lartë, që e bën testimin, edhe në disa serverë, krejtësisht joindicues dhe të tregojë vetëm vlera tepër të përafërta, që kanë pak lidhje me realitetin.
Prandaj, gjatë zhvillimit në thelbin e bllokadës, për të vlerësuar performancën dhe për të përgjigjur pyetjes "a është përmirësuar krahasuar me herën e kaluar", ne përdorim një softuer mjaft të komplikuar, që orkestron nisjen e bllokadës me dhjetëra nyje dhe fillimin automatik të benchmark-ut dhe mbledhjen e metricave; pa këtë informacion është jashtëzakonisht e vështirë të depurosh protokollet që punojnë me shumë pjesëmarrës.
Kështu që, kur të merrni pyetjen "sa TPS ka bllokada juaj?", ofroni një filxhan çaji dhe sqaroni nëse ai është i gatshëm të njihet me një dhjetë grafika dhe gjithashtu të dëgjojë të gjitha tre kutitë e problemeve të performancës së bllokadave dhe propozimet tuaja për zgjidhjen e tyre...
Burimi: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish