A simple inspection of the Fabric architecture and transaction stages will reveal the possible bottleneck components. The ordering service is a prime and obvious example. Every transaction MUST pass through this service and get included in a block to have a chance at ledger commitment. But keep in mind that there is still no guarantee that a transaction will not be rejected at commitment time. Therefore, the performance of the ordering service, in a way, sets the baseline for your application's performance. Clearly, increasing orderer resources, either by adding more nodes or adding capacity to each individual node, may result in better performance. Other ordering mechanisms may also be used in place of the current Fabric default, which is Kafka. As the Fabric platform evolves, expect to see better and faster ordering algorithms.

Another system bottleneck lies at the ledger commitment stage when the transactions have to be evaluated both for authenticity of endorsements and to enforce database (ledger) consistency by managing read and write conflicts. Cryptographic operations are heavy by nature, and recent changes to Fabric (in v1.1, for example) have made signature validations more efficient. As a developer or a network engineer, you can streamline performance by minimizing the possibility of transaction failures because of invalid signatures or inter-transaction conflict. For the former, better validation at endorsement stage and during the request generation for the orderer should decrease the chances of failure.

To reduce conflicts, one needs to experiment with varying block sizes (remember that checks are made for conflicts among transactions within a block). Though larger blocks may result in higher throughput, conflicts may have the opposite effect. You can also design your chaincode in ways that will minimize the possibility of conflicts among different invoke transactions. For explanation of how Fabric detects and handles conflicts in blocks see Chapter 4, Designing a Data and Transaction Model with Golang, in the Multiversion concurrency control section.