-
Notifications
You must be signed in to change notification settings - Fork 1k
Sprint Release Notes
- Deploy Transaction calls chaincode
Initfunction - Invoke Transaction calls chaincode
Invokefunction - Query Transaction calls chaincode
Queryfunction Please see examples for more detail
The /chaincode endpoint was added to replace the original /devops/deploy, /devops/invoke, and /devops/query endpoints, which are now deprecated. Please see the documentation here for further explanation and examples.
https://github.com/hyperledger/fabric/blob/master/docs/API/CoreAPI.md#chaincode
The table below demonstrates the improvement in the transaction throughput enabled by the caching feature. Please note that these numbers are only at the ledger level and not for end-to-end system.
| Bucket-cache disabled | Bucket-cache disabled | Bucket-cache enabled | Bucket-cache enabled | % Improvement | ||
|---|---|---|---|---|---|---|
| NumReads | NumWrites | Benchmark Time (nanos) | Throughput (tx/sec) | Benchmark Time (nanos) | throughput (tx/sec) | |
| 1 | 1 | 19981045377 | 5004.74 | 15266998482 | 6550.08 | 30.88 |
| 1 | 4 | 62301879141 | 1605.09 | 46002859879 | 2173.78 | 35.43 |
| 4 | 1 | 25944935286 | 3854.32 | 21073280916 | 4745.35 | 23.12 |
The experiments are performed using golang's benchmark utility on a Mac book pro (Processor: 2.5 GHz Intel Core i7 - 4 cores, Memory: 16 GB 1600 MHz DDR3, SSD based storage).
Each row in the table represents one experiment. In each of the experiments, first, the Ledger is pre-populated with 1000,000 key-values and then 1000 batch of transactions are executed; each batch containing 100 transactions. Each of the transactions, performs a fixed numbers of reads and writes of pseudo-randomly selected keys (out of existing keys in the ledger). The size of the key-value used in the experiments is 100 bytes.
The first two columns in the table show the number of reads and writes performed by each of the transactions. The third and fourth columns show the performance numbers when the caching feature is not used. The third column shows the time reported by the benchmark utility of golang and the forth column shows the throughput numbers (derived as total transactions executed / time taken). The next two columns show the similar data when the caching feature is used and finally, the last column shows the improvement observed in the throughput.
As observed, that this feature is more helpful when the transactions are write heavy. For instance, in the table the maximum gain (35%) is observed in the second row which has a read to write ratio of 1:4. This is because, more writes cause modification in more data-buckets and hence cause more read requests for non-data buckets for recomputing of crypto-hashes. Similarly, the read heavy transactions (such as the third row in the table) reads more of the data keys than the non-data buckets and hence relatively a lower improvement (23%) is observed.
These experiments are performed by executing the script fabric/core/ledger/benchmark_scripts/ledger/randomTransactions.sh.