I have been looking at some of the performance issues in Inventory from the outside, and I noticed a few things. I apologize in advance for the verbosity of this issue.

I was looking in the Network tab in the Developer tools for Firefox, trying to understand what takes so much time. This is one find.

Steps to reproduce:

1. Go to https://bugfest.folio.ebsco.com/inventory/view?qindex=all&query=computers&sort=Title

2. Hit F12 on your browser and choose Network

3. Refresh the page

4. In the developer tools pane, locate the first inventory/instances?limit=30&query=... request. Note it's duration.

5. When the page has loaded, perform a different search using the regular search form, just substitute the query for something else. Look again at developer tools-> Network and note the time.

Expected results: The time for a search should be the same, and for recently performed searches perhaps a bit quicker due to caching.

What actually happens: The second search takes in most cases ~10X (4s vs .4s) the time for the first search. Even if they are the same.
First "search" (reload of the page:

Second search (from the search form):

In order to reproduce this behaviour, I wrote a bash script that first fires away a number of queries and times the response. It then sends the same queries again, but this time there is a 11second delay between each request. I think the results replicates some of the above mentioned behaviour, but not all of it.

Script print out:

There is no other difference between the calls than the 11s delay, and it seem to show a delay of 3x the requests that happen immediately after another.

Is this due to some overhead inside OKAPI? It seems from this, that the actual searches actually are pretty fast, but that there is some strange overhead to a request.

EDIT:
This seems to be related to the fact that the permissions Cache is expired after 10 seconds. (for details, see the #performance thread on Slack).
If this is the case, this happens in all user interaction that takes less than 10 seconds between each interaction.

The numbers from the CURL calls might also be significantly higher in real life. The above tests, repeated in the browser and Postman, would suggest. this See screen shots.