-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Remove extra flush events to increase performance #43363
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
Conversation
48b6395
to
5eabd3e
Compare
Closes keycloak#43362 Signed-off-by: Alexander Schwartz <alexander.schwartz@ibm.com>
5eabd3e
to
49dbbc5
Compare
@shawkins - may I ask you to review this PR, or should I ask a different team? Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just added a couple of general thoughts. Ideally we can revisit the excess flushing more systematically. If I recall it was roughly doubling the time that it takes to perform an import.
action.setPriority(model.getPriority()); | ||
realm.getRequiredActionProviders().add(action); | ||
em.persist(action); | ||
em.flush(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems fine. In general there are a lot of flushes in RealmAdapter that seem ad hoc beyond the pattern of persist / flush / detach.
Set<ClientScopeClientMappingEntity> clientScopeEntities = clientScopes.stream() | ||
.filter(clientScope -> !existingClientScopes.containsKey(clientScope.getName())) | ||
.filter(clientScope -> { | ||
if (clientScope.getProtocol() == null) { | ||
// set default protocol if not set. Otherwise, we will get a NullPointer | ||
clientScope.setProtocol(OIDCLoginProtocol.LOGIN_PROTOCOL); | ||
} | ||
return acceptedClientProtocols.contains(clientScope.getProtocol()); | ||
}) | ||
.map(clientScope -> { | ||
ClientScopeClientMappingEntity entity = new ClientScopeClientMappingEntity(); | ||
entity.setClientScopeId(clientScope.getId()); | ||
entity.setClientId(client.getId()); | ||
entity.setDefaultScope(defaultScope); | ||
em.persist(entity); | ||
return entity; | ||
}).collect(Collectors.toSet()); | ||
if (!clientScopeEntities.isEmpty()) { | ||
em.flush(); | ||
clientScopeEntities.forEach(entity -> em.detach(entity)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In situations where you have less direct control over the transitive calls, the pattern using the EntityManagers logic looks like:
Set<ClientScopeClientMappingEntity> clientScopeEntities = clientScopes.stream() | |
.filter(clientScope -> !existingClientScopes.containsKey(clientScope.getName())) | |
.filter(clientScope -> { | |
if (clientScope.getProtocol() == null) { | |
// set default protocol if not set. Otherwise, we will get a NullPointer | |
clientScope.setProtocol(OIDCLoginProtocol.LOGIN_PROTOCOL); | |
} | |
return acceptedClientProtocols.contains(clientScope.getProtocol()); | |
}) | |
.map(clientScope -> { | |
ClientScopeClientMappingEntity entity = new ClientScopeClientMappingEntity(); | |
entity.setClientScopeId(clientScope.getId()); | |
entity.setClientId(client.getId()); | |
entity.setDefaultScope(defaultScope); | |
em.persist(entity); | |
return entity; | |
}).collect(Collectors.toSet()); | |
if (!clientScopeEntities.isEmpty()) { | |
em.flush(); | |
clientScopeEntities.forEach(entity -> em.detach(entity)); | |
} | |
EntityManagers.runInBatch(session, () -> { | |
clientScopes.stream() | |
.filter(clientScope -> !existingClientScopes.containsKey(clientScope.getName())) | |
.filter(clientScope -> { | |
if (clientScope.getProtocol() == null) { | |
// set default protocol if not set. Otherwise, we will get a NullPointer | |
clientScope.setProtocol(OIDCLoginProtocol.LOGIN_PROTOCOL); | |
} | |
return acceptedClientProtocols.contains(clientScope.getProtocol()); | |
}) | |
.forEach(clientScope -> { | |
ClientScopeClientMappingEntity entity = new ClientScopeClientMappingEntity(); | |
entity.setClientScopeId(clientScope.getId()); | |
entity.setClientId(client.getId()); | |
entity.setDefaultScope(defaultScope); | |
em.persist(entity); | |
}); | |
}, true); |
However that will generally result in 2 flushes though, rather than the single flush that is done here.
@shawkins - thank you for reviewing; this was just about some small improvements I found while working on something else. |
Yes, that is clear from the issue. Just thought it was worth mentioning how broadly flush calls are being used, and another approach that also prevents the accumulation of entities in the peristence context. |
I'll handle this another time when I have more time to dive into this. |
@mposolda / @pedroigor / @vramik - as we've briefly discussed it in the chat today: These seem to be some small changes and the CI still passes. So I want to proceed with this changes, but don't introduce any other changes beyond that. This is an attempt to make use of some analysis I did to test how Keycloak performs with a lot of realms, so I didn't want to waste it as the result was already there. Please let me know if you agree, and if this PR should be merged as is. Any additional work should be tackled in a different issue and should be planned for separately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unreported flaky test detected, please review
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.account.AccountRestServiceTest#listApplicationsWithoutPermissionKeycloak CI - Java Distribution IT (windows-latest - temurin - 17)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unreported flaky test detected, please review
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.account.AccountRestServiceTest#listApplicationsWithoutPermissionKeycloak CI - Java Distribution IT (windows-latest - temurin - 17)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you @ahus1 for preparing the PR
Closes #43362