Current behavior

Previously we had a bug on searches endpoint degradation https://jira.onap.org/browse/CPS-1085
In frame of that the new id-seraches endpoint performance was corrected and it was good enough for us
Currently with the latest master version it seems to be slow again
When we tested the CPS-1085 solution we were able to list 10k cmhandles in few seconds

At the end of our discovery process we have 10k cmHandles from one subSystem
Each cmHandle has 162 yang resources, 7 private properties and 1 public property

Tried to query the cmhandles:

POST https://<ncmp_url>/ncmp/v1/ch/id-searches
{
"conditions": [
{
"name": "hasAllModules",
"conditionParameters": [

]
}
]
}

Query time in case of 400 cmHandles 24sec
Query time in case of 1500 cmHandles 54sec

Expected behavior

With previous version we used the searches endpoint. Expected performance should be at least the same
Previous version was:
https://gerrit.onap.org/r/gitweb?p=cps.git;a=commit;h=806d31aed57c798cba0ecc33d92e5b43fa1d957b
Measurements with previous version when we used search endpoint:
5000 cmHandles search time 2.28 sec
7000 cmHandles search time 3.29 sec
10000 cmHandles search time ~5 sec

Reproduction

Register huge amount of cmhandles and try to search them.

In our environment it was:
~1500 cmHandles
Each cmhandle had 162 yang resources
Each cmhandle had 1 public property
Each cmhandle had 7 private property

Try to query all of them
POST https://<ncmp_url>/ncmp/v1/ch/id-searches

{
"conditions": [
{
"name": "hasAllModules",
"conditionParameters": [
{"moduleName": "ericsson-enm-GNBDU"}
]
}
]
}
}

CPS version

https://gerrit.onap.org/r/gitweb?p=cps.git;a=commit;h=060499cb5a89a0fd3d8480132ed82d2e291839dc