Slow site Since D10 Upgrade

I don't see how the CAS module would contribute to this. If you log in without CAS (using a local Drupal user account that's not CAS-associated), do you also experience the issue? If you uninstall the CAS module too?

I agree with you, i don't understand the source of the error.
And yes if im anonymous / logged in with a Drupal original account there is absolutly no probleme.

Only if im logged with a SSO User, and after logged in every page the user is loading take 10 secs to respond.

If i uninstall the SSO it will work (as its forking for a standard account).
Does something related to CAS SSO is done at every requests ?

Update: i think i find a good way to explore, it might have a conflict in code With access Check. Wich is in phase with Drupal 10.

Stay tuned for more

I finally found that the original site builder used a dumb module, wich is responsible of this error.
I close this issue since its not a CAS related problem.

Ps: but i dont understand why SSO user only are affected in my case.

Im opening back this issue.
It appears that since Drupal 10 add mandatory ->accessCheck() on entityQueries usage, it seems their is a conflict with CAS Server.

Every accessCheck added on a page is adding signitificative page loading time when the user is connected by SSO.

It really seems like SSO queries are done on every accessCheck triggerd to load a certain page.

In my case when the page is cached, their is no problem. But i have site using a cache per User so that really annoying.

Does the SSO queries plug on the accessCheck process ?

Thanks in advance for you investigations.

Can you be more specific? What code exactly in this module is responsible for your slow down?

We are using https://www.drupal.org/project/entity_access_by_role_field → (which is doing a lot access check to manage permission on each node).

User logged throught SSO:

Without entity_access_by_role_field module, loading a Page is taking +- 12s (it was < 12s before D10 migration) for a User logged as SSO, after activation of restrict_access module it raise to 27s for this same User.

User logged normaly

Whithout entity_access_by_role_field (1.52s loading)
Whith entity_access_by_role_field (1.75s loading)

I suspect there's something deeper going on here, but I don't really have enough information to help diagnose this further. Can you pinpoint a specific line or area of code in the CAS module that is contributing to this problem? Logging in via CAS vs logging in as a normal user doesn't have much difference.

The CAS module will store some session variables to the user's session data, like "is_cas_user" and "cas_username". Do you have other code that's interacting with those session variables or something?

Can you dump the output of `drush cget cas.settings`?

_core:
default_config_hash: 2z_THKqotLn7-Fl5rKmZkNmZph-IVfv-8q1ShRZAqBY
login_link_enabled: false
login_link_label: 'CAS Login'
login_success_message: 'You have been logged in.'
server:
version: '3.0'
protocol: https
hostname: sso.xxxxx
port: 443
path: ''
verify: 0
cert: ''
gateway:
enabled: false
recheck_time: -1
paths:
id: request_path
negate: false
pages: ''
method: server_side
forced_login:
enabled: false
paths:
id: request_path
negate: false
pages: ''
user_accounts:
prevent_normal_login: true
auto_register: true
email_assignment_strategy: 1
email_hostname: ems.post
email_attribute: email
auto_assigned_roles: { }
restrict_password_management: false
restrict_email_management: false
error_handling:
login_failure_page: ''
message_validation_failure: 'There was a problem logging in, please contact a site administrator.'
message_no_local_account: 'There was a problem logging in, please contact a site administrator.'
message_subscriber_denied_reg: 'There was a problem logging in, please contact a site administrator.'
message_subscriber_denied_login: 'There was a problem logging in, please contact a site administrator.'
message_account_blocked: 'There was a problem logging in, please contact a site administrator.'
message_username_already_exists: 'There was a problem logging in, please contact a site administrator.'
message_prevent_normal_login: 'This account must log in using CAS.'
message_restrict_password_management: 'The requested account is associated with CAS and its password cannot be managed from this website.'
logout:
cas_logout: true
logout_destination: ''
enable_single_logout: false
single_logout_session_lifetime: 25
proxy:
initialize: false
can_be_proxied: false
proxy_chains: ''
advanced:
debug_log: false
connection_timeout: 10

And for your first question,

The website in case is really a simple website. Displaying static data and no more.
In my opinion the SSO is the more complex functionnality at it, so i think there is nothing in interaction with "is_cas_user" and "cas_username" session data.

When monitoring ressources during a SSO user page loading, the process CPU progressivly raise to 100% and fall down to < 1% after serving the page. Really look like something is looping in the process, in combination of this Bug is coming after D10 migration, thats why accessCheck() trouble is my guess.

I am experiencing the same issue. When logged in with the administrator role, I do not encounter the lag. This makes me think it might be related to cache management for non-admin users.
I doubt it’s a permissions issue causing the lag, but it could be how caching is handled differently for administrators.

Any idea ?

Bug is coming after D10 migration, thats why accessCheck() trouble is my guess.

As I remember, when we've added D10 compatibility, we've preserved the previous accessCheck() behaviour. I doubt that it could be an issue with that. Maybe you can profile and detect the bottleneck?