NYM read slower than credential accumulator update?

Hi

I’m investigating some performance aspects of Indy I noticed something interesting that I don’t understand:

In my setup the average NYM read request from a specific Indy ledger takes around 500ms but the updating of the credential accumulator on the ledger with a new credential (RevocRegEntryRequest update) takes around 150ms.

How can reading a NYM be considerably slower than writing to the ledger with a new credential accumulator?

Thanks

The performance of Indy depends A LOT on network characteristics and on the size and connectivity characteristics of the pool, plus the configuration options for the indy network you’ve deployed. Thus, I am hesitant to speculate in detail based on the info in the description. However, I do agree that it’s odd that you’re seeing a read take much longer than a write. It sounds like you are having to collect read responses from multiple nodes and confirm that they agree, instead of reading a single response that includes a state proof to short-circuit the consensus check. But even then, I can’t explain why writes would be faster.

FWIW, there has been extensive and formal testing of Indy performance. I don’t know if it’s summarized in a single tidy place, but there is hard data. I would ask for it on #indy in Hyperledger’s RocketChat.

Thanks for reporting this.
Read requests should be faster than write as they don’t require consensus and can be get from one Node only. However they require more validation on the client side (check correct signatures and state proofs). Another reason could be that state proofs (get requests from 1 Node) doesn’t work for some reasons. The reasons can be: very incompatible versions (very old?); a lot of nodes in the pool down; etc.
Can you please provide more info about

  • Is it a custom pool or one of Sovrin Pools? If latter, then is it BuilderNet, StagingNet or MainNet?
  • What version of client do you use?
  • What version of pool do you use (if this is a custom pool)?

Thanks for the responses both.

@alexander.sherbakov - My local Indy setup is quite simple: 1 Ubuntu 14.04 VM contains 4 ledger nodes (https://github.com/bcgov/von-network) and a second Ubuntu 14.04 VM (in the same network) fires read/write transactions (latest version of indy-sdk via node.js wrapper). Network latency between the ledger nodes themselves should be minimal/zero since they are on the same VM. Read transactions appear to be signed by 3 of the 4 ledger nodes.

@danielh - *“It sounds like you are having to collect read responses from multiple nodes and confirm that they agree, instead of reading a single response that includes a state proof to short-circuit the consensus check”

In my setup the reads do bounce between 3 of the 4 ledger nodes (editing the poolconfig to contact fewer nodes for a read doesn’t change that). For a write, do you know if the consensus process is concluded before the state proof is sent back?

Nevertheless, my assumption is that the write+consensus process should be slower than a single read bounced between a few nodes…

Paul