Hello, when in Octopus UI we open dashboard for any tenanted project (app#/projects/{projectId}/overview), the UI loads the /api/projects/all resource. I suppose it does so to match project Id to project name. This is weird, because it can do this with a single call to /api/projects/{projectId}, which will be way faster.
I believe some clients won’t notice the difference, but for our setup there is a HUGE difference. We have ~3000 projects, and the /api/projects/all resource takes 20-30 seconds to load (from request to the end of response). Compressed it takes 500KB, but plain text ~ 9MB. And that’s not the only request that goes in the background, but that one is the largest one.
Moreover, the UI does this request twice!
Another long calls are:
-
/api/dashboard?projectId={projectId}&showAll=true, which takes ~7 seconds
-
/api/users/{userId}/permissions, which takes ~4 seconds.
Other requests are generally 0.1-0.5 seconds each.
Can this be improved?
Hi Dmitry,
Which version of Octopus are you running these days?
In 4.0 we introduced caching on /api/projects/all, so more often than not it should return a 304 - not modified response.
I’m sorry, that dashboard load-time is painfully slow for you. We do have caching on it, so hopefully you sometimes get a 304 returned for it as well (though you won’t if you refresh the browser)?
The problem is the cache invalidation for the dashboard is rather naive, and on super-large installations like yours the cache is invalidated way too often. I’m going to see if there’s something I can do about that.
Regarding /api/users/{userId}/permissions, on which page are you seeing this call being made?
Regards,
Michael
Hello Michael, we use 2018.2. And it’s not the general dashboard page, but the dashboard of some project. For general dashboard I understand why you might need the /api/projects/all call, but here I’m talking about the page when you select any project in UI and get to project details page (a list of it’s tenants with deployed versions for these tenants).
I do understand it’s the project dashboard. A couple of thoughts:
-
Are you seeing/api/projects/all being called each time you go to the project dashboard? It does get called to populate the project-switcher in the top nav-bar, but this should only happen once.
-
In that version, api/projects/all should be cached. Even when it does get called, I would hope you would see a 304 returned most times? This should be fast, because it doesn’t have to transfer the data.
We implemented caching on most of our ../all endpoints: /projects/all, /tenants/all, /environments/all, etc. This was with customers with large datasets, such as you, in mind. We are certainly interested to know if this helped (or more importantly, if it didn’t help). You should generally see 304 on these endpoints?
Hello.
When We open project by direct url like:
https://our.deploy.server.local/app#/projects/our-cool-project/process
UI do many (9!) requests to ‘process/all’ and gets each time response 200 and all contents for all projects (it are about 4000 items):
And some of this run in parallel
Hi Andrei,
Thank-you for the extra information.
I think you’ll find only the first two of those calls are to /api/projects/all (the two 447kb calls). The rest will be to /api/environments/all, /api/tenants/all, etc.
But those first two are the ones causing the problem. And actually, I just did some testing and found that it is only one of them that is preventing the UI from rendering (the other will happen asynchronously in the background).
I have just pushed a change that should result in this call no longer being made for you. This will be available in version 2018.3.1. I am hopeful that this will reduce the load time of this page for you.
I’d love to hear the results once you have a chance to upgrade.
