wp-graphql
Timeout and Performance Issues with Media Items
Description
Hi, I reported some performance issues to the Gatsby team in the discussion here, and figured I'd report the same here. Since upgrading to WP-GraphQL 1.12, we've experienced very slow performance when sourcing images. I've tried a mix of solutions, including object caching and adjusting concurrency of requests, but the performance is the same each time, even when the data for our site is cached. Looknig at the logs, I thought that the Guttenberg/ACF plugins were to blame, but after upgrading and disabling those, the performance for the source images/media step remained the same.
https://github.com/gatsbyjs/gatsby/discussions/37166
Steps to reproduce
Run Gatsby develop or build using the Gatsby Source Wordpress plugin with WPGraphl queries.
Additional context
No response
WPGraphQL Version
1.13
WordPress Version
v5.8.1
PHP Version
7.4.28
Additional enviornment details
No response
Please confirm that you have searched existing issues in the repo.
- [X] Yes
Please confirm that you have disabled ALL plugins except for WPGraphQL.
- [X] Yes
- [ ] My issue is with compatibility with a specific WordPress plugin, and I have listed all my installed plugins (and version info) above.
@stevepepple is this an issue with Gatsby sourcing data, or WPGraphQL resolving the data?
My hunch is that it's an issue with gatsby / gatsby-source-wordpress, and in that case, I'd recommend opening an issue with Gatsby.
If you believe it's an issue with WPGraphQL and not Gatsby, please provide steps to reproduce. How can I get my site to behave in the same way? How did it behave before and how does it behave now? What version worked and what version caused the performance decrease?
The more information I have to reproduce your scenario, the better I would be able to help.
Hey @jasonbahl, thanks for the response! We'll do our best to provide more info here.
The reason we suspect it's on the Wordpress end is because the step became slower after upgrading WPGraphQL. And Wordpress often times out with a 504. But certainly it could be something else. I'll report to the Gatsby team. And the fact that caching on the Wordpress side of things doesn't help could also suggest that it's Gatsby. It's just odd, because the sourcing step for images is exponentially longer (Not downloading, just sourcing.)
Any pointer for debugging GraphQL resolving the data?
I suppose I can call the same queries that gatsby-source-wordpress does, but any other suggestions are appreciated.
Hey @stevepepple any chance you're still running into this in the latest versions of WPGraphQL (v1.21.0 as of writing, but keep in mind WPGatsby hasn't been updated in a few years and it's possible it's not compatible with some newer versions).
Any pointer for debugging GraphQL resolving the data? I suppose I can call the same queries that gatsby-source-wordpress does, but any other suggestions are appreciated.
Sadly, that and using Gatsby's logging + WPGraphQL's trace debugging to try and identify the bottlenecks are really the only approach. Gatsby does a lot of "magic" behind the scenes, so first step is to try and isolate where this is coming from?
@jasonbahl I'm wondering if this is actionable from WPGraphQL or if this should be transferred to the WPGatsby repo?
In order for this to be actionable, we'd need more information and be able to reproduce isolated from Gatsby.
If this could be reproduced in WPGraphQL alone given specific queries to execute and examples of how fast/slow they were/are now, etc then perhaps there would be something to address.
I'm going to close this based on the age of the issue and the fact that it isn't necessarily a WPGraphQL specific issue (and I've not had general reports of media items being slower outside of Gatsby 🤷♂)