Therefore, a blockchain application's performance is affected by similar factors to those affecting a traditional DBMS-based transaction processing application. First, we must constantly monitor the health of the hardware resources that are hosting the application components. For every machine that is running a peer or orderer or CA, we need to track basic health indicators, such as CPU usage, memory usage, disk I/O speeds, network bandwidth, latency, and jitter, and available storage space (this is not meant to be an exhaustive list). These factors, especially CPU usage for processing-heavy systems, determine whether the application is running at optimal performance levels.

As we have seen in this book, a Fabric network can be started in a variety of configurations, from a single dedicated machine (physical or virtual) for each peer and orderer to a single-machine setup running each component in an isolated docker container (like our trade network setup in this book). In the latter case, you will need to monitor the health of not only the machines but also each container. Also remember that each Fabric chaincode instance always runs in a docker container rather than on a dedicated machine. Plus, when it comes to understanding (or profiling) applications, the CPU, memory, and I/O usage of application components are of the most relevance. We will look at some tools to measure container and application performance later in this section.

Moving from the external factors to the application itself, the performance of a Fabric application (just like any other transaction processing application) is defined by two characteristic metrics:

• Throughput: This is the number of transactions per unit time that your system can yield. As Fabric is a loosely coupled system and a transaction has multiple stages (see Chapter 5, Exposing Network Assets and Transactions, for examples in our trade scenario), we can measure throughputs for the different stages. But the overall throughput, from the time a client constructs a transaction proposal for endorsement up to the time when an event indicating ledger commitment is received, provides the best overall picture of how your application performs. On the other hand, if we want to measure just the orderer throughput, we would need to collect statistics just for the part where the client sends an endorsed transaction envelope to the orderer and gets back a response.
• Latency: As most Fabric applications will ultimately be user-facing, it's not just the processing capacity or volume that will matter in a real-world scenario but also how long each transaction takes. As in the case of throughput, we can measure different latencies—chaincode execution and endorsement, ordering and block creation, transaction validation and ledger commitment, and even event publishing and subscription. We can also measure inter-component communication latency in an effort to understand the limitations of the communication infrastructure.

There are other important things to measure, such as the time taken to synchronize ledger states across peers (using the gossip protocol), but from a transaction processing perspective, the preceding two metrics are of prime importance. When we measure these factors, we get an understanding of how the overall application is performing, and also its constituent parts such as the ESCC and VSCC in a peer and the Kafka service in an orderer.