getState() on IBM Blockchain v2: experiencing long load times

Question

I have deployed a single organization network on IBM Blockchain v2. I am experiencing very slow load times (always over 3 seconds for a single asset.)

I have bumped up specs on the Kubernetes cluster. I have also adjusted some of the resource allocations, but the load time didn't budge.

  async query(ctx, key) {
    console.info('query by key ' + key);
    let returnAsBytes = await ctx.stub.getState(key);
    console.info(returnAsBytes)
    if (!returnAsBytes || returnAsBytes.length === 0) {
      return new Error(`${key} does not exist`);
    }
    let result = JSON.parse(returnAsBytes);
    console.info('result of getState: ');
    console.info(result);
    return JSON.stringify(result);
  }

I am wondering if there is a way to get faster results. I also haven't found been able to find many resources on proper deployments for IBM Blockchain v2, so I'm unsure if I'm doing something incorrectly.

Can you provide details on how you are driving this and how you are measuring the times, not sure what you mean by load times — david_k, Jul 25 '19 at 19:44
Precisely what David said. Are you running the application from scratch (i.e. the connection has to be established), or is this an endpoint where the connection has already been established to the peer. More code and a lot more details will help provide an answer — lindluni, Jul 25 '19 at 19:55
@lindluni I have based my application off of this setup: https://github.com/IBM/blockchainbean2 I believe it creates a new connection every time a request is made. — , Jul 25 '19 at 20:38
@lindluni As for method of measuring load times, I am making a GET request to the REST server handling the Fabric connection (the REST server is running locally). I know that my own internet connection plays a role in the time so I'll move the connection to a remote server running in the same location as the blockchain instance. — , Jul 25 '19 at 20:40
In order to understand fully I would need to know how you determine the time frame when you start, what is done in between and when you end. For example if you measure the time as being the time it takes to create a gateway, connect it, submit a transaction and wait for that to complete, then disconnect the gateway then I would expect that to take a very long time. — david_k, Jul 25 '19 at 21:01
@david_k So this sounds like a typical timeframe (~3 seconds) for a request using this sort of method? Also, is there perhaps a better method? — , Jul 25 '19 at 21:27

david_k · Answer 1 · 2019-07-26T13:16:26.343

Unfortunately you haven't provided enough information, however one area which can have a performance impact is on the client side application where an incorrect pattern for every request used would be create gateway/connect gateway/submit transaction or evaluate transaction/disconnect gateway.

This jira https://jira.hyperledger.org/projects/FABN/issues/FABN-1319 provides some detail about the gateway lifecycle. But a quick one line suggestion is, don't create gateways all the time, cache them and use a stale policy to disconnect them after a period of non-use. Note gateways are bound to an identity so you would have a gateway for each identity

getState() on IBM Blockchain v2: experiencing long load times

1 Answers1