Project

General

Profile

Actions

Bug #21031

open

Updating commons site seems slower than usual

Added by Raffi Khatchadourian 2 months ago. Updated about 2 months ago.

Status:
New
Priority name:
Normal
Assignee:
-
Category name:
-
Target version:
-
Start date:
2024-09-20
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

Very laggy.


Related issues

Related to CUNY Academic Commons - Bug #15242: Slugist siteReporter FeedbackBoone Gorges2022-02-02

Actions
Actions #1

Updated by Raymond Hoh 2 months ago

Actions #2

Updated by Raymond Hoh 2 months ago

Hi Raffi,

While looking through prior tickets, I see that you opened #15242 previously. Much of the same things Boone mentioned in that ticket can be applied to this one. When you are logged in as an administrator, the Subscribe2 and Gravity Forms plugins still do the "SHOW TABLES LIKE" DB queries. I've reapplied Boone's Gravity Forms fix from #15242, which was overwritten in a later update. This should help logged-out users, but not yourself though.

I also notice that the Gravity Forms plugin is doing a remote license check on every page with the following HTTP call:

https://gravityapi.com/wp-json/gravityapi/v1/licenses/XXX/check?site_url=https://khatchad.commons.gc.cuny.edu&is_multisite=1

This can slow page rendering down a bit. Perhaps we can look at disabling this HTTP call or limiting it to administrators.

Actions #3

Updated by Raffi Khatchadourian about 2 months ago

Hi Ray. Sorry for the delay. Whatever you did to re-nable that fix made it seem much faster. Could that fix be permanent?

I'll look into migrating Subscribe2 to something else.

If you can remove that check, that would be great. Thanks!

Actions #4

Updated by Raymond Hoh about 2 months ago

Whatever you did to re-nable that fix made it seem much faster.

I think at the time you were experiencing responsiveness issues, we were experiencing sitewide database issues due to a problematic plugin. So that could have been a partial reason for the slowness as well.

Could that fix be permanent?

Unfortunately, no. Boone contacted Gravity Forms about the fix back in #15242 two years ago, but they did not apply his recommended change so if Gravity Forms makes a plugin update and we forget to re-patch the fix afterwards, the same thing will occur. We can look to reach out to Gravity Forms again. Boone, would you mind reaching out to GV again?

If you can remove that check, that would be great. Thanks!

I can look to block the HTTP call without modifying the Gravity Forms plugin if GV is using core WP functions to do the HTTP call. Will see what can be done.

Actions #5

Updated by Boone Gorges about 2 months ago

Thanks for reapplying, Ray. I've sent a follow-up to my original GF ticket:

Hi Gravity Forms team,

Back in 2022, our team patched GF with the following: https://gist.github.com/boonebgorges/2f4b0a2310ae1a1b26d3dfdff1eb65af

It was later overwritten by subsequent updates, and the performance problems have come up again.

I thought I'd bump this ticket, with the patch above, as I think it'd be a safe and worthwhile improvement for your dev team to consider.

Boone Gorges

Not holding my breath on that one. If we thought it was worthwhile, we could run a 'query' filter to prevent this costly query, but that feels like a pretty big hammer.

Actions #6

Updated by Raffi Khatchadourian about 2 months ago

Thanks, Boone and Ray. I hope they respond soon :).

Actions

Also available in: Atom PDF