You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: high-throughput/README.md
+57-27
Original file line number
Diff line number
Diff line change
@@ -107,56 +107,86 @@ Change back into the `high-throughput` directory in `fabic-samples`. Start the n
107
107
108
108
If successful, you will see messages of the Fabric test network being created and the chaincode being deployed, followed by the execution time of the script:
109
109
```
110
-
Total setup execution time : 141 secs ...
110
+
Total setup execution time : 81 secs ...
111
111
```
112
112
113
113
The `high-throughput` chaincode is now ready to receive invocations.
114
114
115
115
### Invoke the chaincode
116
-
All invocations are provided as scripts in `scripts` folder. You can use these scripts to create and remove assets that you put on the ledger.
116
+
117
+
You can invoke the `high-througput` chaincode using a Go application in the `application-go` folder. The Go application will allow us to submit many transactions to the network concurrently. Navigate to the application:
118
+
```
119
+
cd application-go
120
+
```
117
121
118
122
#### Update
119
-
The format for update is: `./scripts/update-invoke.sh name value operation` where `name` is the name of the variable to update, `value` is the value to
120
-
add to the variable, and `operation` is either `+` or `-` depending on what type of operation you'd like to add to the variable. In the future,
121
-
multiply/divide operations will be supported (or add them yourself to the chaincode as an exercise!)
123
+
The format for update is: `go run app.go update name value operation` where `name` is the name of the variable to update, `value` is the value to add to the variable, and `operation` is either `+` or `-` depending on what type of operation you'd like to add to the variable.
122
124
123
-
Example: `./scripts/update-invoke.sh myvar 100 +`
125
+
Example: `go run app.go update myvar 100 +`
124
126
125
-
#### Get
126
-
The format for get is: `./get-invoke.sh name` where `name` is the name of the variable to get.
127
+
#### Query
128
+
You can query the value of a variable by running `go run app.go get name` where `name` is the name of the variable to get.
127
129
128
-
Example: `./scripts/get-invoke.sh myvar`
130
+
Example: `go run app.go get myvar`
129
131
130
132
#### Prune
131
-
Pruning takes all the deltas generated for a variable and combines them all into a single row, deleting all previous rows. This helps cleanup
132
-
the ledger when many updates have been performed.
133
+
Pruning takes all the deltas generated for a variable and combines them all into a single row, deleting all previous rows. This helps cleanup the ledger when many updates have been performed.
133
134
134
-
The format for pruning is: `./scripts/prune-invoke.sh name` where `name` is the name of the variable to prune.
135
+
The format for pruning is: `go run app.go prune name` where `name` is the name of the variable to prune.
135
136
136
-
Example: `./scripts/prune-invoke.sh myvar`
137
+
Example: `go run app.go prune myvar`
137
138
138
139
#### Delete
139
-
The format for delete is: `./delete-invoke.sh name` where `name` is the name of the variable to delete.
140
+
The format for delete is: `go run app.go delete name` where `name` is the name of the variable to delete.
140
141
141
-
Example: `./scripts/delete-invoke.sh myvar`
142
+
Example: `go run app.go delete myvar`
142
143
143
144
### Test the Network
144
-
Two scripts are provided to show the advantage of using this system when running many parallel transactions at once: `many-updates.sh` and
145
-
`many-updates-traditional.sh`. The first script accepts the same arguments as `update-invoke.sh` but duplicates the invocation 1000 times
146
-
and in parallel. The final value, therefore, should be the given update value * 1000. Run this script to confirm that your network is functioning
147
-
properly. You can confirm this by checking your peer and orderer logs and verifying that no invocations are rejected due to improper versions.
148
145
149
-
The second script, `many-updates-traditional.sh`, also sends 1000 transactions but using the traditional storage system. It'll update a single
150
-
row in the ledger 1000 times, with a value incrementing by one each time (i.e. the first invocation sets it to 0 and the last to 1000). The
151
-
expectation would be that the final value of the row is 999. However, the final value changes each time this script is run and you'll find
152
-
errors in the peer and orderer logs.
146
+
The application provides two methods that demonstrate the advantages of this system by submitting many concurrent transactions to the smart contract: `manyUpdates` and `manyUpdatesTraditional`. The first function accepts the same arguments as `update-invoke.sh` but runs the invocation 1000 times in parallel. The final value, therefore, should be the given update value * 1000.
153
147
154
-
There are two other scripts, `get-traditional.sh`, which simply gets the value of a row in the traditional way, with no deltas, and `del-traditional.sh` will delete an asset in the traditional way.
148
+
The second function, `manyUpdatesTraditional`, submits 1000 transactions that attempt to upddate the same key in the world state 1000 times.
149
+
150
+
Run the following command to create and update `testvar1` a 1000 times:
151
+
```
152
+
go run app.go manyUpdates testvar1 100 +
153
+
```
155
154
156
-
Examples:
157
-
`./scripts/many-updates.sh testvar 100 +` --> final value from `./scripts/get-invoke.sh testvar` should be 100000
155
+
The application will query the variable after submitting the transaction. The result should be `100000`.
156
+
157
+
We will now see what happens when you try to run 1000 concurrent updates using a traditional transaction. Run the following command to create a variable named `testvar2`:
158
+
```
159
+
go run app.go update testvar2 100 +
160
+
```
161
+
The variable will have a value of 100:
162
+
```
163
+
2020/10/27 18:01:45 Value of variable testvar2 : 100
164
+
```
158
165
159
-
`./scripts/many-updates-traditional.sh testvar` --> final value from `./scripts/get-traditional.sh testvar` is undefined
166
+
Now lets try to update `testvar2` 1000 times in parallel:
167
+
```
168
+
go run app.go manyUpdatesTraditional testvar2 100 +
169
+
```
170
+
171
+
When the program ends, you may see that none of the updates succeeded.
172
+
```
173
+
2020/10/27 18:03:15 Final value of variable testvar2 : 100
174
+
```
175
+
176
+
The transactions failed because multiple transactions in each block updated the same key. Because of these transactions generated read/write conflicts, the transactions included in each block were rejected in the validation stage.
177
+
178
+
You can can examine the peer logs to view the messages generated by the rejected blocks:
179
+
180
+
181
+
`docker logs peer0.org1.example.com
182
+
[...]
183
+
2020-10-28 17:37:58.746 UTC [gossip.privdata] StoreBlock -> INFO 2190 [mychannel] Received block [407] from buffer
184
+
2020-10-28 17:37:58.749 UTC [committer.txvalidator] Validate -> INFO 2191 [mychannel] Validated block [407] in 2ms
185
+
2020-10-28 17:37:58.750 UTC [validation] validateAndPrepareBatch -> WARN 2192 Block [407] Transaction index [0] TxId [b6b14cf988b0d7d35d4e0d7a0d2ae0c9f5569bc10ec5010f03a28c22694b8ef6] marked as invalid by state validator. Reason code [MVCC_READ_CONFLICT]
186
+
2020-10-28 17:37:58.750 UTC [validation] validateAndPrepareBatch -> WARN 2193 Block [407] Transaction index [1] TxId [9d7c4f6ff95a0f22e01d6ffeda261227752e78db43f2673ad4ea6f0fdace44d1] marked as invalid by state validator. Reason code [MVCC_READ_CONFLICT]
187
+
2020-10-28 17:37:58.750 UTC [validation] validateAndPrepareBatch -> WARN 2194 Block [407] Transaction index [2] TxId [9cc228b61d8841208feb6160254aee098b1b3a903f645e62cfa12222e6f52e65] marked as invalid by state validator. Reason code [MVCC_READ_CONFLICT]
188
+
2020-10-28 17:37:58.750 UTC [validation] validateAndPrepareBatch -> WARN 2195 Block [407] Transaction index [3] TxId [2ae78d363c30b5f3445f2b028ccac7cf821f1d5d5c256d8c17bd42f33178e2ed] marked as invalid by state validator. Reason code [MVCC_READ_CONFLICT]
0 commit comments