Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening the Media Library in the Gallery block causes server overload when there are a lot of images uploaded to the website #28563

Closed
rafaucau opened this issue Jan 28, 2021 · 4 comments · Fixed by #28621
Assignees
Labels
[Block] Gallery Affects the Gallery Block - used to display groups of images [Feature] Media Anything that impacts the experience of managing media [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@rafaucau
Copy link

rafaucau commented Jan 28, 2021

Description

I have 110k images uploaded to my website.
Opening the Media Library in the Gallery block causes server overload when there are a lot of images uploaded to the website.
Images load normally at first, but the entire site is very slow for all users, and finally starts throwing 524 Timeout errors. In the network tab in dev tools, I found that in the background some request to admin-ajax.php is pending, which contains such data:
image
In the Image block and on the Media page, this problem does not occur.

Perhaps it's because of this arg: query[posts_per_page]: -1

I checked on a clean WordPress installation by uploading several thousand images and then opening the Media Library in the Gallery block and this query has a large TTFB. The more images the longer TTFB. It also causes very high CPU usage.

Step-by-step reproduction instructions

  1. Upload several thousand images

  2. Add a new post and a Gallery (not Image!) block inside

  3. Click "Media Library" in the Gallery block
    image

  4. The CPU consumption on the server will increase and the entire website will start to run slowly

Expected behaviour

There shouldn't be a request that puts so much load on the server when there are a lot of images uploaded.

Actual behaviour

The website runs very slowly after calling this request and finally throws timeouts. The website is unusable for several minutes. This makes it very difficult to use WordPress because galleries are often used on my site.

Screenshots or screen recording (optional)

image
image
net2
image
err524

WordPress information

  • WordPress version: 5.6.0
  • Gutenberg version: Not Installed - built-in
  • Are all plugins except Gutenberg deactivated? Yes
  • Are you using a default theme (e.g. Twenty Twenty-One)? Yes
@talldan
Copy link
Contributor

talldan commented Jan 29, 2021

Yeah, I think there's something wrong here. The images shown in the media library do use paging, only fetching a small number at a time. That can be seen visually by the way more images are loaded when scrolling in the media library.

Additionally there's the post__in query you mention, which is supposed to fetch any images that are currently added to the gallery so they can be shown. Initially when the gallery block is empty, the block editor uses wp.media.query passing in an empty array, which results in no requests being made and an empty collection of attachments being created for the media library:

const getAttachmentsCollection = ( ids ) => {
return wp.media.query( {
order: 'ASC',
orderby: 'post__in',
post__in: ids,
posts_per_page: -1,
query: true,
type: 'image',
} );
};

But then there's some logic in the media library that triggers a query due to the collection being empty.
https://github.com/WordPress/wordpress-develop/blob/8d7e7d03ff8ad036678851f959792f76d9759025/src/js/media/views/attachments.js#L386-L391

The this.collection.more() call fetches more attachments, but actually fetches every image in one request (the post__in query).

Checking out the classic editor, it doesn't seem possible to create an empty gallery, so it might be a side effect of the block editor using code that wasn't designed to work this way, or maybe the block editor is doing it wrong. Either way it seems that we need a way to pass in an empty collection and not have another request triggered.

I'm not all that familiar with media library code so will ask some of the maintainers for help.

@talldan talldan added [Block] Gallery Affects the Gallery Block - used to display groups of images [Feature] Media Anything that impacts the experience of managing media [Type] Bug An existing feature does not function as intended labels Jan 29, 2021
@rafaucau

This comment has been minimized.

@rafaucau
Copy link
Author

rafaucau commented Jan 29, 2021

I have a temporary solution to this issue:

add_filter('ajax_query_attachments_args', 'disable_unlimited_images_load', 10, 1);
function disable_unlimited_images_load($args) {
    if ($args['posts_per_page'] == -1) {
        $args['posts_per_page'] = 0;
    }

    return $args;
}

@talldan
Copy link
Contributor

talldan commented Feb 1, 2021

@rafaucau That temporary solution might lead to some undesired side effects. I'm not sure what a value of 0 does. You probably don't want it to be 0 when the query post__in param is specified properly. e.g. when the gallery or image block has images added to it already:
Screenshot 2021-02-01 at 3 38 26 pm

☝️ This query only returns two items due to the specified ids (179, 180).


I've put a fix together here for the bug here - #28621.

Unfortunately this has just missed the window for being included in WordPress 5.7. Hopefully there will be a 5.7.1 that it can be included in.

If you use the Gutenberg plugin, this fix should hopefully be in v10 of that in just over two weeks time (though I still need to get it reviewed and merged).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Gallery Affects the Gallery Block - used to display groups of images [Feature] Media Anything that impacts the experience of managing media [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants