UI spams backend with requests

[ctron]

To me, it looks like the frontend spams the backend with continuous requests, although just the search results page is opened:

This problem is, that a single UI instance seems to bring down the backend already:

For example, it continously re-requests information about PURLs: GET https://trustify.dentrassi.de/api/v2/purl/8384d853-38ff-5bd9-bb7b-07b0b49c6bf5

Why is it doing that?

[carlosthe19916]

The UI is calling the endpoints for populating the tables every 10 seconds so the user visualizes its data if there is any change in the backend without the need to refresh the browser manually.

I expect the server supports at a minimum a couple of hundred of users and the fact that the server was killed because of this should make us investigate the bottom of the real problem.

In the context of the Search Page:

• There are 4 tabs then there should be 4 requests every 10 seconds BUT:
• Each table view requires relationships. E.g. In the context of the SBOM Table. The UI needs to render not just the SBOM but also the Vulnerabilities associated to that SBOM.
  • GET /api/v2/sbom?limit=10&offset=0 gives the list of SBOMs but with this info it is impossible for the UI to render Vulnerabilities for each SBOM. It is needed to fetch GET /api/v2/sbom/{id} to get Advisories and then render Vulnerabilities. The same logic applies to all the other TABS/Tables on the Search Page. I hope this explains why there are calls to both GET /some_entity?offset=0&limit=10 and also to multiple GET /some_entity/{id}; this approach can not be avoided with the current rest endpoints.

Having said that, I will reserve some time to double-check which calls can be optimized

[ctron]

Right. How often to we expect data to change? How many requests per second will keeping a UI open like this cost? Is that worth the effort?

Doing the math: 4 tabs, times 10 results each, leads to 40 requests every 10 seconds. For data that most likely doesn't change. I'd say, that's not worth it.

True, we can deal with this on the backend, e.g. by just caching results and giving the UI the impression it just performed a request. Downside of this: this would cause additional work on the backend, and it would give users not spamming the backend, stale data.

So I'd say, we do better, and optimize the UI.

[JimFuller-RedHat]

A few observations:

• prodsec probably max 20-30 concurrent users is a good starting expectation.

• web ux should (does it do it today ?) parameterise any cache/refresh type settings ? Could be useful to play around to find good defaults.

• Making these individual calls faster is always a good thing - though we may also elect to aggregate all paged calls and 'paint' the data into the UX (instead of spawn 10+ additional http requests).

• Do we know what the state of our web serving is modulo things like keep-alive ... towards that do we think a load balancer (ex. nginx) in front of trustify will be a common infra scenario ? I would prefer avoiding additional complexity by considering things like websockets - at least until we have agreed on what performance expectations are for single instance versus instance running in openshift with #n web pods.

• A default instance of trustify has modest settings in terms of # of database conns ... we may have to provide guidance in the form of documentation to say 'tweak this' to get more performance if using as single instance.

• Making a single standalone instance of trustify better performing is different then ensuring we make trustify horizontally scale eg. by adding web pods we should get more parallelism to the database (as well as avoid throttling from any single web pod ip address). We should try to make trustify faster in the single instance but for prodsec we are interested in ensuring a 'big boy' instance scales horizontally.

[PhilipCattanach]

Thanks James, you make lots of good points above.

Before do any analysis work I think we need to get to a stable data model.

If we can get an upstream 0.2.2 release published today, then we can build a new downstream from that, and use that to start analyzingperformance.

There are other issues that are concerning 303 and 1236.

If we have a lot of duplicates in the database the performance is bound to suffer.

[JimFuller-RedHat]

Thanks James, you make lots of good points above.

Before do any analysis work I think we need to get to a stable data model.

the data model is not going to change very much from here on out - there are defo optimisations we can make to speed up parity work (and ingestion) which I have ignored in priority of other work ... after external references I plan to work with the team on that.

If we can get an upstream 0.2.2 release published today, then we can build a new downstream from that, and use that to start analyzingperformance.

I believe that is happening right now.

There are other issues that are concerning 303 and 1236.

If we have a lot of duplicates in the database the performance is bound to suffer.

I believe those issues probably addressed by trustification/trustify#1237 (and now in main and will go into todays release).