It all depends on how much more efficient this really is? Can you quantify it?

The caching was put in place to make it inexpensive to query greenwave. It would cost a lot the first time to get "all the results", but subsequent queries would be fast / cached.

We can remove the caching, but, how much faster is it now?

I think we need to err on the side of being gentle to Resultsdb because it continues to suffer from overloading woes. And Bodhi is still polling Greenwave decisions (albeit only every 6 hours) not listening for messages so I think if we took away the caching it would result a net increase in requests going to Resultsdb. Which is probably not good.

Also, do we know if Resultsdb can handle these kinds of queries any better than individual item-type pairs? I am guessing that it actually produces a slower query which takes longer, and the only benefit is we save on repeated round-trip time... so basically it is also trading extra load on Resultsdb for less wall time waiting in Greenwave. Which is again, not nice to Resultsdb.

I'm testing this locally and trying to get same results as before the change. The problem is that since now greenwave is asking resultsdb for many more results in one batch, the limit needs to be increased also.

Running this locally, I get about the same performance (~15secs for getting decision for FEDORA-2018-5a6cc3f4a2 Bodhi update). Making single request could help when requesting data from remote server but I don't think the improvement will be big.

I'm closing this for now (I'll open another PR to fix the results/waivers listed with verbose flag).

I did some tests against the staging environment.

Tested decision forFEDORA-2018-5a6cc3f4a2 bodhi update (56 koji builds).

Requesting all Waivers always performs better then requesting them one-by-one (I'll create new PR for this later if needed).

Locally requests take about 12s.

On stage by number of items/koji-builds in single request (very rough estimates):
- 1-by-1: 1m 20s
- all: 30s
- by-4: 50s
- by-8: 40s
- by-10: 38s
- by-16: 35s

Default timeout for gunicorn is 30s and timeout for each request is 15s
(REQUESTS_TIMEOUT in configuration).

I'm trying to use asyncio, it works and is fast but I'm fighting the dogpile cache stuff (the code for invalidating resultsdb cache should be refactored).

What advantage does asyncio bring? Is that just a way for Greenwave to smash Resultsdb with even more concurrent requests?

I think the key thing here is that we need to not just reduce the wall time for a given Greenwave request (at the expense of hitting other services harder), we need to figure out where the biggest inefficiencies are and fix them in whatever service that is (for example if it's an inefficient query in Resultsdb let's fix it there). Otherwise we only making the problem worse not better.