Checking if _admin_notice_post_locked should be called can slow down the post editing

[berislav.grgicak]

On wp-admin/edit-form-advanced.php:28, WordPress checks if multiple users exist to call _admin_notice_post_locked.

In some cases, plugins add additional filters to all get_users calls to ensure that a user role doesn't have access to private data.
If these checks use meta value comparisons, it can slow post-editing on sites with large user_meta tables.

The root cause of this issue is how WordPress stores and validates user capabilities, but the _admin_notice_post_locked check could be optimized without fixing the root cause.

Some suggestions on how to fix this would be:

• caching the $check_users value
• using a boolean option that is true if a site has multiple users
• adding a filter that allows manually setting $check_users to skip this check

[costdev]

Hi @berislavgrgicak, welcome to Trac!

I'm just modifying the ticket's parameters to help get this some more focus and help to track down when this was introduced.

---

This check was introduced in WordPress 4.9.

• Changeset: [41829]
• Ticket: #42119

[berislav.grgicak]

Thank you @costdev!

I would be happy to help with this, but I'm not sure what would be the best way to improve the performance.

[bor0]

@costdev we just ran into this again recently.

We're hosting WooCommerce.com, a huge WooCommerce store, and we are receiving about 1000 "MySQL server has gone away" errors per month because of this issue.

I submitted a patch that fixes it for us, but it'd be great if it makes it into core to potentially fix it for other users.

[bor0]

cc @sergeybiryukov as well :)

[SergeyBiryukov]

In 59522:

Editor: Check get_user_count() instead of get_users() for the locked post notice.

This aims to avoid slowing down the post editing by using a cached value instead of calling get_users(), which can be slow when plugins add various filters to all get_users() calls, especially with meta value comparisons on large user_meta tables.

Follow-up to [24304], [24543], [41829], [53011], [53018].

Props berislav.grgicak, bor0, costdev.
See #55958.

[SergeyBiryukov]

Replying to bor0:

I submitted a patch that fixes it for us, but it'd be great if it makes it into core to potentially fix it for other users.

Thanks for the ping! I think we can check get_user_count() here, see [59522]. Would that resolve the issue for you?

[bor0]

Wow, thanks a ton, this will fix it for us!

I totally missed get_user_count() - so elegant. And it also doesn't rely on get_users, which is neat. I knew pinging you was the right thing to do :)

Tested on both multisite and non-multisite instances.

[SergeyBiryukov]

Replying to bor0:

Wow, thanks a ton, this will fix it for us!

Great, thanks for the confirmation :)