CiviCRM plugin causes a ~ 30 second login delay

Question

Just upgraded to CiviCRM 5.54.1, on WordPress 6.0.3 (self-hosting on a virtual private host running CentOS 9, PHP 7.4.32 using php-fpm). For a really long time now, I think since the beginning to be honest, there's been a roughly 25 second delay after a user clicks login before the login is accepted and the login page starts to be processed on the server. Once that happens things are quick.

Browser debugging has the wait squarely on admin-ajax.php. Enabling custom logging on my SSL request log confirms that the request to that URL takes 30 seconds on login (most of the time it's logged as 0 seconds, as it only logs in units of integer seconds).

It's not OS resource related, it's not traffic related. I don't think it has anything to do with database performance as there isn't much traffic or activity at all, and no SQL queries are showing as suspicious (unable to tell if there are just a bajillion of them adding up with my view though). I can't find anything in any error log even with debugging turned on that helps me figure out what's going on.

Disabling the CiviCRM plugin causes logins to be instantaneous. Re-enabling brings back the login delay. While I know that the two WordPress tests around REST API timeout and active PHP session are deemed harmless and there are posted workarounds to disable those tests, I can't help but wonder if while the tests may be testing the wrong thing, the underlying issue may be valid.

Searched this group and the internet in general several times, trying different search terms, to no avail. No help on the WordPress StackExchange group either.

So, does anyone have any ideas what it may be or how I could narrow the culprits down a bit?

Thank you.

Michael

Answer 1

Update: when the combination below is present (at least with some JetPack paid plans), it seems that JetPack’s ‘Dedicated Sync’ thread which gets called on login is somehow blocked by CiviCRM’s session management giving the 30s timeout. I’ve been working with JetPack engineers for a while now, taking traces to narrow things down. The workaround is for them to disable the Dedicated Sync thread, but I’m not sure what is lost when you do that. That warning in WordPress’s system health about an active PHP session is probably not as harmless as has been mentioned here…

It seems like this was related to something going on with the JetPack plugin, in the end. CiviCRM + JetPack + all the themes I tried that didn't come with WordPress = slow login. CiviCRM + JetPack + included WordPress themes = fast login, but the layout options weren't what I wanted. Change any of those and logins were fast. JetPack Support noticed an unknown-cause, not fully understood by me sync discrepancy, fixed it, and now any login after the first one (per user, per browser, so, session cookie updating) is fast. Given that there will always be something going wrong unexpectedly, I'm hoping they'll take my suggestion and make the JetPack plugin a bit more robust, assuming that was in fact the root cause.

Answer 2

I am unsure if this is an 'answer' but I have seen this before and I have always tracked it down to another plugin waiting on a request. That plugin on it's own is not the issue, but as it's unaware of CiviCRM the combination is the issue.

I'd start by disabling all plugins except CiviCRM, go to a default theme and see if the problem is still there. If it is I'd look at the server/fpm settings.

If CiviCRM loads on a clean site, I'd enable the theme, test. If no issues I'd move to plugins one by one until I found the issue.

I've just tested on a cpanel server (closest I have to your config) and with a theme we use on most sites (Kadence) and about 20 plugins - login is nearly instant.

My enviornment is WP 6.0.3, CiviCRM 5.54, php 7.4-fpm, CentOS and WHM/cPanel