[wp-trac] [WordPress Trac] #31018: Persistent database connections with mysqli

[WordPress Trac]

#31018: Persistent database connections with mysqli
-------------------------------------+------------------------------
 Reporter:  blobaugh                 |       Owner:
     Type:  enhancement              |      Status:  reopened
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Database                 |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by pento):

 * keywords:  has-patch needs-testing dev-feedback => has-patch needs-
               testing


Comment:

 Replying to [comment:9 blobaugh]:
 > Could you explain why this is? It seems new settings are warranted as
 there is no other way to modify how the database connection works.

 New settings are almost never warranted - I think the last one we added
 was `WP_MAX_MEMORY_LIMIT`, added in r17749, released in WordPress 3.2.

 > Uh huh, so does setting DB_HOST or DB_CHARSET or WP_CONTENT_DIR or any
 number of other settings. They can all break a user's site. That is why
 they are in the settings file and not exposed in the UI for users to play
 with. That argument does not seem to stand up to the test of other
 settings.

 Of course you can break your site by messing up your other settings. The
 difference is that `DB_PERSISTENT` would allow you to break your site in
 an inconsistent manner, just by enabling it. Persistent connections are
 kind of like MySQL's query cache in this regard - they were very useful to
 improve performance in MySQL 4.0, and can even give performance benefits
 today. They'll keep giving performance benefits, right up until they
 explode.

 In the case of persistent connections, that explosion point is when a PHP
 process dies without releasing all of its locks. Those locks will be held
 until the connection is recycled, and `mysqli` forces all locks to be
 released. In the intervening time, your site is locked with no obvious
 reason why. For this reason alone, I'd want to actively discourage users
 from enabling persistent connections, by specifically not supporting it in
 core.

 > Yes this is one option, however it is not a good option because core
 changes how connections work periodically. The site owner would need to be
 aware that core was changing so they could hire a dev to update their
 drop-in file. It is not realistic for a site owner to track that. They
 should only have to enjoy their site. We are already seeing many instances
 of this happening with IIS based installs. The plugin jtsternberg
 mentioned goes to some length to capture this but is ultimately a bad hack
 and very fragile but it is currently how I have seen adding persistent
 connections to WordPress recommended (though I do agree it is horrible).

 That's the deal with DB drop-ins - they need to be maintained.

 Well, that's not entirely true. When we change WPDB, we keep drop-ins in
 mind, so that we don't suddenly cause them to stop functioning. They
 really only need to be updated to take advantage of new features (see
 HyperDB, which functions quite well without having added `mysqli`
 support).

 Regarding [attachment:31018-2.diff], this will create severe maintenance
 problems - even if we were to switch these functions to `protected`,
 instead of `public` (so that plugins don't start calling them), we'd still
 need to support them for DB drop-ins, like the one being suggested. If we
 were to move to a DB driver system, for example, we'd likely be stuck with
 these driver-specific functions on the global API.

 This ticket comes down entirely to where we want the maintenance burden to
 rest - on core, to maintain support for persistent connections, or on a DB
 drop-in, to maintain feature parity with core. Given the extremely limited
 audience of this feature, it seems to me that core isn't the right place
 for this.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31018#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform