Continuing from our previous discussion, you can configure various parameters to optimize your application’s performance. Many of these parameters are outcomes of the system requirements such as the network size.  But a few parameters in your core Fabric configuration (see Chapter 3, Setting the Stage with a Business Scenario, in Network Components' Configuration Files section) can be adjusted to maximize performance. One of them is the block size. It’s possible to determine the precise block size (both in bytes and in the number of transactions) that you should set for your application through experimentation (or adjustment of the parameter until you achieve optimal throughput and latency). For example, measurements on a crypto-currency application called Fabcoin revealed an optimal block size of 2 MB (https://arxiv.org/abs/1801.10228). But the reader must keep in mind the trade-off discussed in the previous section whereby a larger number of transactions in a block may also result in higher conflict rates and transaction rejections.

Your selection of transaction endorsement policy will also have a significant performance impact. The more the signatures that need to be collected from endorsing peers, the more time it will take to validate the signatures at commitment time. Also, the more complex your policy (namely the more clauses it has), the slower the validation will be. Now there is a trade-off to be made here. More endorsers and a more complex policy will usually provide higher assurance (reliability as well as trust), but it will come at a cost to performance (both throughput and latency). Therefore, a blockchain application administrator must determine what service level as well as trust level are required and tweak the parameters accordingly.

There are various other factors that could affect the performance of a Fabric application: this includes overhead due to the gossip protocol among the peers to sync the ledger contents, the number of channels you use in your application, and the transaction generation rates. At the hardware level, performance is determined by the number and performance of CPUs available to the components. Generally, it can be stated that increasing the number of CPUs yields an increase in the performance of the components and of the overall blockchain network. If you are interested in more details, a good paper to read on this topic is Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains, EuroSys '18 (https://dl.acm.org/citation.cfm?id=3190538), also available at https://arxiv.org/pdf/1801.10228v1.pdf.