-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
slow /v3/roles call. #278
Comments
ran this though a formatter:
is this part of the Role model craziness? https://github.com/cloudfoundry/cloud_controller_ng/blob/4bc537c9ff2b01c46c2bdcfa4de480198c954875/app/models/runtime/role.rb#L8 |
That query makes my head hurt. |
When I had a look at the @sethboyles I think this |
Yeah, I agree that it's probably safe to remove the RoleGuidPopulate invocation now. |
FYI, we worked around this issue with some database machinations. We currently use mysql v5.7.38 in RDS. 5.7 seems to have an in-memory temp table limit of 16M. I was noticing that all of the role queries temp tables were being moved to disk, so we set our temp table limit to 128M. This seems to have beneficial impact over all, and especially on these roles queries. The settings we changed were Do the Cloud Foundry developers use mysql v5.8? It seems 5.8 has a different pooled mechanism for temp table limits such that you may have never run into this problem. |
We're seeing issues with this endpoint as well, and but changing Some random findings, not on this endpoint specifically but using the It seems the UNION ALL queries are particularly inefficient when applying a WHERE clause after generating the union of all the tables VS including a WHERE clause on each separate UNION. Example: Current query:
Including separate WHERE clauses:
Although this query will be removed entirely with cloudfoundry/cloud_controller_ng#3043, I believe this general rule will apply to the We could bypass Sequel entirely for this query, and fill out our own models from a SQL query. It could just be a simple Ruby object we instantiate to pass to the presenters. Another idea is to migrate the individual role tables (e.g. |
I've opened a draft PR (cloudfoundry/cloud_controller_ng#3068) that moves most of the WHERE conditions into the individual SELECTs. Please head over to the PR/commit description for details. When following this path we might also get rid of |
I'm going to close this issue as the Optimize Role model/dataset PR has been merged and is released as part of CAPI 1.144.0. @pusherofbrooms - you should see a significant performance improvement with the latest CAPI version. |
Issue
/v3/roles calls which look like:
/v3/roles?types=space_developer&space_guids=90775432-527f-4771-a1cc-17a4751de041&user_guids=26c20682-0ec5-4e13-817d-f64d6f580563
seem to be expensive if multiple of them stack up.Context
Our environment has 231 organizations, several thousand users, and about 20TB of applications running.
cf-deployment version is v21.9.0
CAPI version is v1.136.0
The query in the database looks like this:
At least I think this is the related query.
Steps to Reproduce
I'm not sure how to reproduce it yet except to say this only happens in our largest environment with many concurrent queries.
Expected result
swift return of the query, like less than a second.
Current result
The call can take up to 30 seconds to return if many are stacked up.
Possible Fix
I can't give a fix, but I suspect the related query has an unindexed field.
The text was updated successfully, but these errors were encountered: