-
Notifications
You must be signed in to change notification settings - Fork 391
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
Multisite: wp-admin timeout for some network sites after WordPress 6/PHP 8 upgrade #618
Comments
Querying the S3 CloudTrail logs shows thousands of |
For comparison, the site with ~4000 objects that doesn't time out made less than 100 |
Hmm I'm not sure what we should do here. S3 Doesn't have a good way to calculate space used with a given prefix. So I'm not sure we can support the |
I think this is best left in the control of those using S3 Uploads rather than within the plugin itself? |
@rmccue If there was a way for Either way it should probably be documented as a known issue. |
This can be filtered with I could imagine this functionality may be in use by some users, so I'm not sure if it's a good default for us to include, hence my suggestion that it could be better for users to add this rather than us. (When I say "user", I don't necessarily mean end-users, I mean those who are installing S3 Uploads.) That said, as @joehoyle says there's fundamentally no way for us to do this in a performant way so we may be best off forcing it off. |
I think this issue may be addressed by my fix in #661 |
We recently pushed a couple updates:
After which
wp-admin
started timing out on 3-4 of the sites on our multisite network with around 50 sites. This happened with all other plugins disabled except fors3-uploads
.Looking through the AWS X-Ray traces, it appears to be happening when WordPress looks up the available total upload space for a given site with
get_upload_space_available()
:The above screenshot is from a site that isn't affected by the timeout issue, since the X-Ray traces for affected sites get stuck in a "pending" state without any segments... Those requests time out after 60s without any information in the logs. I haven't tried increasing the 60s timeout to see if it would eventually complete.
At first we thought maybe it had something to do with the number of media objects the affected sites had. Total objects for these sites range from around 1500-15000. But the trace above is from a site with 4000 objects and still works.
As a temporary workaround, disabling
Site upload space
in network settings seems to have resolved the issue. But I'm worried that the bug will be triggered by some other operation that usesS3_Uploads\Stream_Wrapper::dir_readdir
.The text was updated successfully, but these errors were encountered: