admin管理员组文章数量:1122846
I understand that having less data being downloaded improves the experience to the end user, but my question is related to the actual server performance, would the response be faster?
I am fetching posts like this:
;per_page=20&categories=9
It returns a fairly large object for each post, but I only need the id, title, excerpt, featured image and permalink.
Would adding _fields[]=id&_fields[]=title
, etc... to the above url improve server performance?
I understand that having less data being downloaded improves the experience to the end user, but my question is related to the actual server performance, would the response be faster?
I am fetching posts like this:
https://example.com/wp-json/wp/v2/posts?_embed&per_page=20&categories=9
It returns a fairly large object for each post, but I only need the id, title, excerpt, featured image and permalink.
Would adding _fields[]=id&_fields[]=title
, etc... to the above url improve server performance?
- 2 I like this question. My assumption has always been that this is probably better but am really hoping someone that's tested this answers. Great question AndreVitorio. :-) – Tony Djukic Commented Jan 30, 2021 at 15:45
- I think Query Monitor will give feedback on REST API requests, did you try this? - github.com/johnbillion/query-monitor#rest-api – Q Studio Commented Jan 30, 2021 at 15:53
- Thanks @TonyDjukic! @QStudio No, I haven't tried query monitor. Thanks for the suggestion. Honestly, I am just filtering the entire set of results. I'm not too concerned about performance since the fetching I am currently working on happens on the backend, so only admins would be affected by it. But I got curious and decided to ask here. :) – AndreVitorio Commented Jan 30, 2021 at 18:53
1 Answer
Reset to default 6I understand that having less data being downloaded improves the experience to the end user, but my question is related to the actual server performance, would the response be faster?
Would adding _fields[]=id&_fields[]=title, etc... to the above url improve server performance?
No it would not, and for several reasons.
When you ask for a post it fetches the entire post row in the database, and it also fetches any post meta and terms so that they're fetched all at once in bulk rather than lots of inefficient smaller queries. This speeds up subsequent queries that ask for posts even if they don't use the same fields, and can even prime caches in advance for future requests.
So when you ask for only a subset of those fields, you don't save any database time or memory, and you add a tiny amount of processing to filter it just to the parts you want.
On top of this, you're asking for a bespoke couture one of a kind response specific just to you. This means we can't easily cache the result and reuse it hundreds or thousands of times. As a result, our scalability can be significantly reduced, as well as potential new queries to grab the data we filtered out because they're now needed on the client side.
There are savings in bandwidth at the server end, but the server end will be in a data centre with a fat network pipe, so this advantage is negligible in comparison to CPU savings. There are also sometimes developer time savings. You can pay the price of performance and scalability to save time when typing out code by using APIs such as GraphQL to dramatically simplify the process of querying for data from a code point of view.
Steps can be taken to mitigate this, such as making sure that the client can only request a small number of unique queries so that caching is feasible.
Otherwise, there's a very real risk that the time/speed savings of a smaller network transfer to the client are dwarfed by the extra time taken at the server to generate the response. A larger cached response may take more time to transfer, but that transfer can begin immediately, and the browser can process it while it's downloading.
There is also the risk that you need to make additional queries because you need extra fields that your first request didn't ask for.
So take real life measurements and compare. If the size of a response is large and has realworld measurable impacts on performance in your use case that are improved by getting smaller responses then it might make sense.
But what if I built custom endpoints that made optimised database calls?
Still no, even if you hardcode the response so that no database queries are happening, the server still has to load WordPress. It can never compete with a dedicated cache such as Varnish, or caching options that load early and exit before WP can fully load such as Batcache.
Likewise, you would also miss out on all the benefits of object caching. When WP fetches posts terms and meta, they're put in WP_Cache
so that they aren't fetched multiple times in the same request. If an object cache is present, then this cache persists across multiple requests in main memory, speeding things up even more. A site with such a cache may make no database calls because the data is already fetched.
版权声明:本文标题:wp api - Are there server performance benefits to fetching only specific fields when querying the REST API? 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.betaflare.com/web/1736307031a1933171.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论