WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#14796 closed defect (bug) (duplicate)

start_post_rel_link() makes 3 DB queries; too much for what it offers

Reported by: demetris Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Performance Keywords:
Focuses: Cc:

Description

I think 3 DB queries is far too much for what start_post_rel_link offers (printing in the doc HEAD a relational link to the first post of the blog).

Is this function (or the one it uses, or the one that uses) as optimal as we can get it?

If yes, isn’t there anything else we can do about that? Like, say, storing the value as an autoloaded transient option?

Change History (11)

comment:1 demetris4 years ago

adjacent_posts_rel_link_wp_head is worse.

When on a Page, i.e. on a post of the page type, it seems to be making up to 9 queries to do its job.

comment:2 dd324 years ago

See also: #15028 - Removed the term & postmeta queries related to the posts queried.

comment:3 demetris4 years ago

Thanks, dd32!

As far as I can tell, r15701 brings a huge improvement:

start_post_rel_link now takes 1 query. (It took 3 before.)

adjacent_posts_rel_link_wp_head for posts of type page now takes up to 4 queries. (It took up to 9 before.)

comment:4 dd324 years ago

adjacent_posts_rel_link_wp_head for posts of type page now takes up to 4 queries. (It took up to 9 before.)

Can you paste the queries? (Ie. is it anything more than > POST_DATE LIMIT 1, and < POST_DATE LIMIT 1?)

comment:5 follow-up: demetris4 years ago

Maybe I was wrong when I said adjacent_posts_rel_link_wp_head added 4 queries, because I cannot reproduce that again. Now I see it adding three (3) queries.

The two are for post_date, as you said. E.g.:

SELECT p.* FROM wp_posts AS p
WHERE p.post_date < '2010-02-28 14:28:19' AND p.post_type = 'page' AND p.post_status = 'publish' ORDER BY p.post_date DESC LIMIT 1
SELECT p.* FROM wp_posts AS p
WHERE p.post_date > '2010-02-28 14:28:19' AND p.post_type = 'page' AND p.post_status = 'publish' ORDER BY p.post_date ASC LIMIT 1

The third extra query is like this:

SELECT `post_parent` FROM wp_posts WHERE ID = 534 LIMIT 1

Which seems to run a second time when adjacent_posts_rel_link_wp_head is on.

(Here is how I check, in case I do something wrong: I first comment out all four rel nav actions in default-filters.php. Then I switch them individually and watch the queries with the SQL Monitor plugin.)

comment:6 dd324 years ago

Cheers, i'll have another look at that, i'll see if i can spot why that 3rd query is running multiple times..

comment:7 in reply to: ↑ 5 demetris3 years ago

Replying to demetris:

The third extra query is like this:

SELECT `post_parent` FROM wp_posts WHERE ID = 534 LIMIT 1

Which seems to run a second time when adjacent_posts_rel_link_wp_head is on.

I confirmed that this third query appears with the default theme too. (Just wanted to make certain it was not something wrong with my own theme, and that I did not bother people with non-existent issues.)

comment:8 jeremyclarke3 years ago

  • Cc jer@… added

+1 for making the rel links require less queries. I had no idea they were there until I had to reverse engineer their presence based on the inane queries they generate (which were clogging my MySQL queue during a high-stress/outage period).

All of these queries are simple and relatively fast if everything is okay, but as far as I can tell on my database (>60k published posts and >250k rows in wp_posts) ANY queries affecting wp_posts contribute to a cpu trashing everything-is-broken state.

Caching such things in a transient is probably a good idea, espcially the 'start' one, which will never ever ever change after the blog is installed. Having a query on every single.php for it is nuts.

comment:9 nacin3 years ago

  • Milestone changed from Awaiting Review to Future Release

comment:10 Elpie3 years ago

  • Cc Elpie added

Please also see https://core.trac.wordpress.org/ticket/18128

Everything except link rel='prev' and link rel='next', that are output by adjacent_posts_rel_link_wp_head, are unsupported by browsers and assistive technologies. In the HTML5 spec they are explicitly not allowed. In XHTML and older versions of HTML they do nothing so the number of queries can be reduced by removing the superfluous link types.

comment:11 nacin3 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Closing as a duplicate then. Let's deal with this in #18128.

Note: See TracTickets for help on using tickets.