-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
perf(app-framework): Make app middleware registration even lazier #36298
perf(app-framework): Make app middleware registration even lazier #36298
Conversation
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.
Looks good 👍
I was scared this would break global middlewares, turns out
:D |
Signed-off-by: Joas Schilling <[email protected]>
Since talk is using middleware, I triggered a CI run at nextcloud/spreed#8598 so we can see it in action |
CS is failing |
f2f4e6e
to
4033249
Compare
Before this patch, app middlewares were registered on the dispatcher for every app loaded in a Nextcloud process. With the patch, only middlewares belonging to the same app of a dispatcher instance are loaded. Signed-off-by: Christoph Wurst <[email protected]>
4033249
to
907ff68
Compare
Integration tests of talk passed as well https://drone.nextcloud.com/nextcloud/spreed/11370 |
Summary job is stuck, but
@skjnldsv, circa 2023-01-25T16:35:32Z |
Summary
Before this patch, app middlewares were registered on the DI container of each app loaded in a Nextcloud process. With the patch the registration is moved to a later point. Only middlewares of the created dispatcher will be loaded.
This allows me to work on a new middleware feature: #36310
Benchmarks
Blackfire and wall time measurements show no improvements. After all we are just moving around class names. That stuff is fast.
Checklist