Re: What changes have improved the performance between v2.0.1 and v2.1.0? #fabric #hyperledger-fabric


Brett T Logan <brett.t.logan@...>
 

Yoojin,
 
There a many things that influence performance of a network, some things to consider are:
 
How many times have you executed the performance test? Were they executed on a common host, i.e. were all components on the same host? Were they executed on a shared environment, i.e., was the network running on a non-dedicated cloud system, or was it running in a non-dedicated kubernetes environment and was the proper anti-affinity applied to ensure overcrowding didn't occur? Are the hosts co-located with local storage? Were you communicating on internal private vlans or external through the internet? When you moved from 2.0 to 2.1, did you ensure the components launch on the same hosts (did VM1 contain peer1 in 2.0 and did VM1 also contain peer1 in 2.1)?
 
Senthil, have you seen this in your performance testing? I took a look at the system test performance benchmarking, and at best I can say its inconclusive. There isn't a wide enough range to say the variation is enough to warrant saying this occurred. We've even on occasion recorded very small swings in the opposing direction where 2.1 performs ever so slightly slower than 2.0.
 
The takeaway from this is, there are a million factors that influence the performance of the network, the key to performance testing is repeatability, for every variation in the test setup, it takes time (and lots of log analysis) to say for sure what caused the variation in the results.
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Senthil Nathan" <cendhu@...>
Sent by: fabric@...
To: cendhu@...
Cc: Yoojin Chang <arashi213@...>, fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] What changes have improved the performance between v2.0.1 and v2.1.0? #fabric #hyperledger-fabric
Date: Tue, Jun 9, 2020 12:51 AM
 
   https://github.com/hyperledger/fabric/commit/78c4e58c318715249253ce85facaf120b8d9e6fd could be the cause of improvement if you are not using the new lifecyle feature for the chaincode deployment. This commit hasn't been backported to v2.0.1 At least when we use CouchDB as the state database, we know for sure that this commit improved the performance as it reduced one entry in the read-set. 
 
This is actually backported to v2.0.1 (sorry for the confusion). Please ensure whether your test setup has this commit.  
 
Regards,
Senthil
 
On Tue, Jun 9, 2020 at 10:14 AM Senthil Nathan via lists.hyperledger.org <cendhu=gmail.com@...> wrote:
Hi Yoojin,
 
   https://github.com/hyperledger/fabric/commit/78c4e58c318715249253ce85facaf120b8d9e6fd could be the cause of improvement if you are not using the new lifecyle feature for the chaincode deployment. This commit hasn't been backported to v2.0.1 At least when we use CouchDB as the state database, we know for sure that this commit improved the performance as it reduced one entry in the read-set. 
 
   If that is not the case, can you share the request arrival rate so that we can check whether it is due to FAB-14761: Limit concurrent requests to endorser and deliver services that indirectly help in reducing the overloaded situation?
 
Regards,
Senthi 
 
On Tue, Jun 9, 2020 at 9:39 AM Yoojin Chang <arashi213@...> wrote:

I recently tested and compared the performance of Fabric between v2.0.1 and v2.1.0 using Caliper.

As a result, Fabric v2.1.0 shows better performance than v2.0.1  when setting peer with leveldb and calling a very simple chaincode.

(invoke TPS increased by 10% , query TPS increased by 27%)

 

Does anyone know what features or fixes has improved the performance?

v2.1.0 release document : https://github.com/hyperledger/fabric/releases/tag/v2.1.0

 

(It seems that a change in the version of go grpc would have affected the performance, but I’m not sure.)
 

 

 

 

 

 

Join fabric@lists.hyperledger.org to automatically receive all group messages.