Server response lag when using openid-connect-generic #516
Comments
|
Are you certain this isn't delays caused by IDP responses? I will look at seeing about trying to log response times in the debug logging to assist with tracking this. The QA team at the agency I work for had flagged a seemingly slow response time with logging into sites some time ago but I had no wider reports from the public that this was a real issue. So your report at least confirms that there may be something more too it. The thing to be aware of is that there is a bouncing out to the IDP and back to the sites that is not necessarily visible and sort of presents itself as just a delay on the WordPress site itself. If you open your browser Dev Tools and monitor the network requests you should see this travel from the WordPress site to the IDP and back again. |
timnolte
added
the
needs analysis
|
We reached out to our team that supports IDP and they said the lag is when the request is coming back from the server and not from their federation authentication provider. With that we figured it could likely have something to do with the plugin itself that we are using for that authentication handshake, so we wanted to check every avenue. |
|
@ChristinaK0127 so after the initial return from the IDP there are additional requests to the IDP, for things like authentication token requests and user info requests, so there could be delays with that as well. I'll get something into the plugin to attempt to track these to get a better picture of where the delays are that can either reveal where in the code changes might need to be made or more information so that something can be additionally checked on the IDP side. |
|
Great, thank you! |
|
Hi Tim, just as a follow up. What sort of timeline would those changes be potentially added to the plugin if at all? |
|
Hope to carve out some time within the next week. |
|
Ok great, thank you very much! |
|
Just a heads up that I have code changes in place and I'm just wrapping up writing some unit tests and running some manual tests. |
- Supports #516 - Updates the logging to also allow for tracking processing time of actions. - Refactors logging to allow for unit testing. - Adds unit tests for logging. - Updates Composer dependencies to the latest versions. - Changes GitHub Actions unit testing to reduce failures. - Updates Dev Container to be less noisy and remove false positive errors during startup.
…522) - Supports #516 - Updates the logging to also allow for tracking processing time of actions. - Refactors logging to allow for unit testing. - Adds unit tests for logging. - Updates Composer dependencies to the latest versions. - Changes GitHub Actions unit testing to reduce failures. - Updates Dev Container to be less noisy and remove false positive errors during startup.
|
Hi Tim, thanks for working on this. I see updates being made here in this thread. Is there any action we need to take on our side at this point? |
|
@ChristinaK0127 I'm just waiting on some updates for a couple of other PRs in the hopes to get those included with the next release. If you want to test out the changes early you should be able to download the GitHub zip archive of the |
|
Hi Tim, thanks for all of your assistance so far. I do have a quick question that I am hoping you might know. How does the OpenID plugin interact with the WordPress database during an authentication request? We are trying to see if having a very large user table might also impact a lag in response time using the plugin. We added the additional logging from the change you made, but didn't see anything in there that answered that question. Thanks in advance! |
|
@ChristinaK0127 yes, the plugin does interact with the users in the database. There are user meta fields that are written to/read from as well as looking for existing WordPress users when logging into match existing and/or create new users. I may need to look further to add additional logging into the plugin. To some degree I mostly update the existing logging points to try and track processing time. I can see about adding some more logging into additional places around user reads/writes/lookups. |
|
@ChristinaK0127 I didn't want to delay the next release any further so I've deployed the latest release with only the initial performance tracking changes I've made. I'll work on adding some more performance tracking in the next release. |
|
@timnolte Thank you! Appreciate the help! |
Checking to see if there is a known issue with using the openid-connect-generic plugin for SSO authentication for WordPress and server response lag time. We are using the openid-connect-generic plugin for SSO authentication and authenticate using ping federate. When a user accesses a website there is about a good 15 second lag in response time. The client request seems to be pretty quick, but the server response seems to lag. We are trying to figure out if there could be something with the plugin or the settings themselves that are causing this issue.
The text was updated successfully, but these errors were encountered: