sync spaces in jsoncs3 concurrently

[butonic]

every test run creates a new space and that has accumulated.

now ListReceivedShares has to sync AFAICT 74 spaces.

• sync spaces in concurrently?

[butonic]

Hm 1 definitely is not the right concurrency. Maybe 10?

The code is already concurrent, but in the past we started as many goroutines as we needed to fetch spaces.

Then we initially limited it to 5 #10572

Then we limited it to 1 with https://github.com/owncloud/ocis/pull/10580/files#diff-0b152f7605595cf8986ba47f9ec12136e240c27124250ff619f7786b19cb6d76

And I had a draft to increase it to 5 again #10595

🤪

[butonic]

in a k8s cluster raising SHARING_USER_JSONCS3_MAX_CONCURRENCY from 1 to 10 decreases request duration from 18.47s to 5.82s:

in a single binary deployment raising SHARING_USER_JSONCS3_MAX_CONCURRENCY from 1 to 5 increases request duration from ~340ms to 1.28sec. We need to verify this ... something might be fishy in the ci.

[butonic]

@kobergj @wkloucek we should set SHARING_USER_JSONCS3_MAX_CONCURRENCY to eg 10 or 20 in the helm charts. 10 improves the sharedWithMe response time significantly (see above).

In ocis 5 we just start a goroutine for each space. This behavior can be restored by setting SHARING_USER_JSONCS3_MAX_CONCURRENCY=0 which produces a trace like this:

With SHARING_USER_JSONCS3_MAX_CONCURRENCY=10 and warmed up cahces the request takes 1.51s:

[butonic]

We are blocked until a decision is made

• how many concurrent go routines should be used to sync space metadata with SHARING_USER_JSONCS3_MAX_CONCURRENCY,
• We need to find out why the CI becomes slower when SHARING_USER_JSONCS3_MAX_CONCURRENCY is increased. see [k6-test] raise default concurrency to 5 #10595 (comment)

[d7oc]

Could we also add some more context to the documentation after the findings in here? For non-involved people it's hard to digest what the settings are for when just reading the current documentation. So in detail: What is more concurrent on the sharing service if we have more concurrency?