Optimaliseer, benchmark, slaag: verbeter de prestaties van uw Hyperledger Fabric
Het optimaliseren van de prestaties van een Hyperledger Fabric-netwerk vereist zorgvuldige overweging van verschillende componenten, configuraties en workflows. Dit zijn de belangrijkste overwegingen om de prestaties te verbeteren:
- Persistent Storage: Gebruik de snelste beschikbare diskopslag, aangezien Hyperledger Fabric uitgebreide disk-I/O uitvoert. Voor network-attached storage kiest u voor de hoogst mogelijke IOPS.
- Netwerkconnectiviteit: zorg voor een snelle verbinding (minimaal 1 Gbps) tussen knooppunten, aangezien het netwerk doorgaans over meerdere locaties is verdeeld.
- CPU en geheugen: Wijs voldoende CPU- en geheugenbronnen toe aan peer- en orderserviceknooppunten. Het monitoren van resourcegebruik is cruciaal; het is raadzaam om het gebruik onder de 70%-80% van de capaciteit te houden om prestatieverslechtering te voorkomen.
- Aantal peers: Door het aantal peers te verhogen, kunt u de netwerkprestaties verbeteren door transactie-goedkeuringsverzoeken over peers te verdelen.
- Kanalen per peer: elke peer kan meerdere kanalen verwerken, maar zorg ervoor dat er voor elk kanaal een CPU-kern beschikbaar is bij maximale belasting om de prestaties te optimaliseren.
- Concurrency Limits: Configureer concurrency limits in de peer-instellingen om te voorkomen dat het systeem wordt overspoeld met buitensporige verzoeken, wat de doorvoer kan beïnvloeden. De Peer Gateway Service, voor het eerst uitgebracht in v2.4 van Hyperledger Fabric, introduceerde de
gatewayServicelimiet met een standaardwaarde van 500. Deze standaardwaarde kan echter de TPS van het netwerk beperken, dus u moet deze waarde mogelijk verhogen om meer gelijktijdige verzoeken toe te staan
peer:
# Limits is used to configure some internal resource limits.
limits:
# Concurrency limits the number of concurrently running requests to a service on each peer.
# Currently this option is only applied to endorser service and deliver service.
# When the property is missing or the value is 0, the concurrency limit is disabled for the service.
concurrency:
# endorserService limits concurrent requests to endorser service that handles chaincode deployment, query and invocation,
# including both user chaincodes and system chaincodes.
endorserService: 2500
# deliverService limits concurrent event listeners registered to deliver service for blocks and transaction events.
deliverService: 2500
# gatewayService limits concurrent requests to gateway service that handles the submission and evaluation of transactions.
gatewayService: 500
- CouchDB-cache-instellingen: Als u CouchDB gebruikt, kunt u overwegen de cachegrootte voor vaak gebruikte sleutels te vergroten om het aantal databasezoekopdrachten te verminderen en de prestaties te verbeteren.
state:
couchDBConfig:
# CacheSize denotes the maximum mega bytes (MB) to be allocated for the in-memory state
# cache. Note that CacheSize needs to be a multiple of 32 MB. If it is not a multiple
# of 32 MB, the peer would round the size to the next multiple of 32 MB.
# To disable the cache, 0 MB needs to be assigned to the cacheSize.
cacheSize: 64
- Aantal orderers: De prestaties worden beïnvloed door het aantal orderende serviceknooppunten dat deelneemt aan consensus. Een goede gewoonte is om te beginnen met vijf knooppunten om fouttolerantie te garanderen zonder knelpunten te creëren.
- Batchconfiguratie: Pas parameters aan zoals
Max Message Count,Absolute Max BytesEnBatchTimeoutin de kanaalconfiguratie om block cutting en transactiedoorvoer te optimaliseren. - SendBufferSize: Verhoog de
SendBufferSizeparameter in de orderconfiguratie om meer berichten in de uitgangsbuffer toe te staan, waardoor de doorvoer wordt verbeterd.
Orderer: &OrdererDefaults
# Batch Timeout: The amount of time to wait before creating a batch.
BatchTimeout: 2s# Batch Size: Controls the number of messages batched into a block.
# The orderer views messages opaquely, but typically, messages may
# be considered to be Fabric transactions. The 'batch' is the group
# of messages in the 'data' field of the block. Blocks will be a few KB
# larger than the batch size, when signatures, hashes, and other metadata
# is applied.
BatchSize:
# Max Message Count: The maximum number of messages to permit in a
# batch. No block will contain more than this number of messages.
MaxMessageCount: 500
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch. The maximum block size is this value
# plus the size of the associated metadata (usually a few KB depending
# upon the size of the signing identities). Any transaction larger than
# this value will be rejected by ordering. It is recommended not to exceed
# 49 MB, given the default grpc max message size of 100 MB configured on
# orderer and peer nodes (and allowing for message expansion during communication).
AbsoluteMaxBytes: 10 MB
# Preferred Max Bytes: The preferred maximum number of bytes allowed
# for the serialized messages in a batch. Roughly, this field may be considered
# the best effort maximum size of a batch. A batch will fill with messages
# until this size is reached (or the max message count, or batch timeout is
# exceeded). If adding a new message to the batch would cause the batch to
# exceed the preferred max bytes, then the current batch is closed and written
# to a block, and a new batch containing the new message is created. If a
# message larger than the preferred max bytes is received, then its batch
# will contain only that message. Because messages may be larger than
# preferred max bytes (up to AbsoluteMaxBytes), some batches may exceed
# the preferred max bytes, but will always contain exactly one transaction.
PreferredMaxBytes: 2 MB
