Connect to database on first query

[spacedmonkey]

Currently there is the database connection is made in __construct method by calling db_connect method. However with sites with persistent object caching enabled, this connection to the database may not be needed. It is common now for requests to have no database queries at all if persistent object caching is setup.

Moving the db_connect call to the query method like this.

        public function query( $query ) {
                if ( ! $this->has_connected ) {
                       $this->db_connect();
                }
                if ( ! $this->ready ) {
                        $this->check_current_query = true;
                        return false;
                }

[spacedmonkey]

Would love the thoughts of @johnjamesjacoby @johnbillion on this one.

[johnbillion]

I pointed this out 11 years ago in #19372 but never followed up :D

If it's simple enough to achieve and has a performance benefit then I'm in favour.

[dd32]

One edge-case to consider is that currently WordPress will exit with a Site Unavailable type error when the DB is unavailable, with this potential change if the query isn't made until the Footer or mid-post-render the page may partially render before hitting a wp_die() condition (As you don't really want to return empty result-sets in the event of a DB-down scenario).

However, plugins like HyperDB and others do delay the DB connect until a query is made, so this might not be an actual issue that needs consideration.

That being said, If a persistent object cache is not in play, delaying until the first query will have very little change for most sites and scenario's.

[elrae]

Added a patch here based on the approach outlined in the ticket description

[spacedmonkey]

@dd32 @johnbillion Any recommendation on unit tests for this one?

[mukesh27]

This ticket was discussed during the Performance Bug Scrub meeting.

The patch requires both unit testing and manual testing. Therefore, we have decided to punt it to the next milestone. Please feel free to reassign it to the current milestone if it is ready for merging. Thank you.

Additional props to @joemcgill @spacedmonkey

[flixos90]

There hasn't been any activity on this in 1.5 years, so I wonder whether there's still appetite to move it forward.

SQL changes like this usually require specific domain knowledge only few committers have, so it can be tough to get traction.

@johnbillion @spacedmonkey Are you confident about this change to move it forward? If not, we may want to close it, e.g. as maybelater.