There is indeed an automated performance test that runs nightly that would catch any performance regressions.
We saw a small perf improvement (~10%) when going from Fabric v1.4 to Fabric v2.0, due to the new CouchDB cache in the peer that services key-based reads (not JSON queries).
We saw no change when going from CouchDB 2.3.1 to CouchDB 3.1.0.

Note however that while these performance tests utilize CouchDB JSON data, they do not perform rich JSON queries, for a few reasons:
- The JSON query performance is extremely sensitive to the data and query, and therefore users will need to test with their own data and queries.
- The JSON query performance drivers are entirely within CouchDB, not Fabric. This is something the CouchDB community already regression tests.
- JSON query is not meant to be used in update transactions. It is meant to be used for read-only queries against the ledger. If you have a high load of queries that you expect will impact the transactional workload, you should consider off-loading those queries to another peer or downstream data store.

I believe some people are working to socialize the performance results each release, they may be able to speak to the current progress...


Dave Enyeart

"Bharg Pvr" ---08/13/2020 12:56:49 PM---Dear Dave and community, My apologies for coming out with this question - this bad:

From: "Bharg Pvr" <pvrbharg@...>
To: fabric@...
Date: 08/13/2020 12:56 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Re. CouchDB - Performance Optimization Best Practices for indexing and searching in the context of HLF solution - V2.2.0 & CouchDB 3.1.0
Sent by: fabric@...

---

Dear Dave and community,

My apologies for coming out with this question - this bad:

>>> You are asking an impossible question, and to the wrong community :-)

First the question is always in the context of Hyperledger Fabric and not a CouchDB performance or scaling question.
I understand - this is not what we do in this forum and in our community.
I already have an answer for your concern.

A correctly designed solution that scales and performs using CouchDB can be learnt from CouchDB community or books - such as:
https://learning.oreilly.com/library/view/couchdb-the-definitive/9780596158156/ch23.html
https://docs.couchdb.org/en/3.1.0/maintenance/performance.html?highlight=performance#


Regarding your comments:

>>> It is impossible to answer because there are too many variables. Only you can answer this question based on trials using your specific data schema, data volume, hardware, indexes, queries, and query load.
>>> And it is a CouchDB performance question, not a Fabric performance question. Test against CouchDB without Fabric

I could agree and understand the above response.
So the question becomes - is this more CouchDB capability to support KV versioned object store for rich queries role/scaling needs or are we dealing with a BigData and/or BigQuery kind of ask.
This is a good point and I would not know unless I further qualify the domain use case and context.

I can also accept and understand - experiment, fail fast and adjust response - perhaps Caliper may play a role and we can suggest this concept [basically we can not provide ready answers and need investigation].

If you look at my last referenced URL - Senthil's paper - that actually has a focused guidance and insights gained - when using CouchDB versus LevelDB.

This is what I was wondering in the context of my question - especially moving from v2.3.1 to 3.1.0 - have we seen performance improvements [by replication or with caching or by exploiting newer capabilities], etc.

So - a better way to ask perhaps - do we have a performance regression harness - that shows some understanding of how CouchDB performs - between releases with newer features and between CouchDB and LEVELDB.

Do we have a follow-up to Senthil's paper - that features current release insights?

Thank you for your offchain DB design pointer and I am aware of it - but did not bring it in since it is a valid proposition.

Best wishes.