[wp-trac] [WordPress Trac] #56040: Port Persistent Object Cache Health Check from performance plugin to core

[WordPress Trac]

#56040: Port Persistent Object Cache Health Check from performance plugin to core
-------------------------------------------------+-------------------------
 Reporter:  furi3r                               |       Owner:  furi3r
     Type:  enhancement                          |      Status:  closed
 Priority:  normal                               |   Milestone:  6.1
Component:  Site Health                          |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests has-dev-    |     Focuses:
  note                                           |  performance
-------------------------------------------------+-------------------------

Comment (by KnowingArt_com):

 I don't see this as a software problem that can be solved with a ticket,
 as much as it is a vision/perspective problem. WordPress is popular today
 because it was easy to install and because PHP was universally supported
 by the thousands of hosting companies out there. More or less that is
 still true today.

 If this change is allowed to continue, you're essentially changing the
 installation requirements to include Redis (because apparently nobody is
 using the memcache plugin.) Adding a whole new database as a requirement
 for WordPress is not a small thing. It is difficult enough maintaining
 MySQL/MariaDB. Small example, a new version of MySQL came out recently
 that required upgrading all WordPress databases to a new format.
 https://pjbrunet.com/upgrade-from-10-7-4-to-10-8-3-crashes-mysql-mariadb/

 As a WordPress host, I have many pages of notes that keep growing over the
 years, and that includes tons of MySQL documentation, which involves
 memory management, caching, monitoring, swapping, backups, etc. It's not
 easy. I'm not looking to make everything more complicated than necessary
 by adding Redis, unless there is a very good reason. And it's not just me.
 Working for a billion-dollar startup, I saw firsthand that MySQL is a huge
 painpoint for other companies, even companies using 3rd party services
 like Pantheon.

 In a perfect world, WordPress would not need a database and would manage
 its own data, but I have sacrificed a significant portion of my life to
 learn to use and maintain MySQL/MariaDB, and to keep it running however I
 can, which is frankly why I had to learn Linux in the first place.

 I disagree that large blogs "can not stay in memory." If that is
 happening, the hosting company is overselling its hardware. For example, a
 blog with 30,000 posts will easily fit into small amount of InnoDB memory
 without swapping. It's just text. Even in extreme cases, when I had a blog
 with millions of posts in MySQL, the entire database fit into a few
 gigabytes of ram.

 I hear what you're saying, I think. But IMO you don't want bloggers
 nagging their sysadmin to install Redis. That is not a small request, and
 the benefit is not really there. In most cases it will create worse
 problems.

 I think I agree with you this kind of recommendation only makes sense in
 certain scenarios, like organizations with unlimited budgets. (Or "This
 nag is sponsored by Google Cloud, yay more technology to buy!") But I
 don't think traffic has anything to do with it. Doesn't the "Query
 Monitor" plugin already monitor database performance?

 If somebody is actually struggling with a slow database, I'd assume their
 host is "overselling" the hardware, or is at the wrong data center, or has
 a lot to learn about the basics: php-fpm, mysql, hosting, linux,
 virtualization, etc.

 Replying to [comment:35 knutsp]:
 > Good points. Cache isn't for ground speed. With a large database indexes
 and data can not stay in memory. With high traffic, it saves database
 queries. So it's about what Health Check tests before recommending, I
 havn't studied yet. But I have seen a lot of small and low traffic sites
 getting this recommendation, I think it's a bad approach and needs
 discussion. But
 >
 > > This ticket was closed on a completed milestone.
 > > If you have a bug or enhancement to report, please open a new ticket.
 Be sure to mention this ticket, #56040.

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