Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module Proposal: SQLite Persistent Object Cache #625

Open
OllieJones opened this issue Jan 18, 2023 · 1 comment
Open

Module Proposal: SQLite Persistent Object Cache #625

OllieJones opened this issue Jan 18, 2023 · 1 comment
Labels
[Focus] Object Cache Issues related to the Object Cache focus area Needs Discussion Anything that needs a discussion/agreement Performance Lab Plugin Issue relates to work in the Performance Lab Plugin only [Type] (Legacy) Module Proposal A new module proposal (legacy)

Comments

@OllieJones
Copy link
Contributor

OllieJones commented Jan 18, 2023

Overview

  • Proposed module name: SQLite Persistent Object Cache
  • Proposed module slug: sqlite-object-cache
  • Proposed module owner Github usernames: @OllieJones , @tillkruss, others?

About the Module

Purpose

This module persists the WordPress Object Cache using SQLite and php's SQLite3 extension. SQLite3 is enabled on many hosts' php configurations, enabling sites to use persistent object caches even when their hosts do not provision caching servers such as redis or memcached. Persistence is good for site performance: it lightens the load on the MariaDB or MySQL database server and delivers page views and requests to users faster.

Background

WordPress has a well-developed and heavily used Object Cache mechanism, accessible via the WP_Object_Cache class and via functions like wp_cache_set() and wp_cache_get(). Since version 3, WordPress has supported external persistent object caches. To do this, a drop-in module placed in .../wp-content/object-cache.php provides a custom cache implementation. Various plugins, notably Redis Object Cache and Memcached Object Cache, provide persistence via an external redis or memcached server.

Without persistence in its object cache, every WordPress page view and API request must use the MariaDB or MySQL database server to retrieve everything it needs about the site. When a user requests a page, WordPress starts from scratch and gets everything it needs from the database server. Only then can it deliver content to the user. With a persistent object cache, WordPress has much more immediate access to much of the information it needs.

Scope

  • Single-site and multi-site (network) support? Yes.
  • Useful to 80% or more of sites? Yes. If a site's host has php with SQLite, and also no cache server, this module will be useful to that site. Note: I don't have exact numbers, and so my "Yes" is a guess.
  • Potential for inclusion in core? Yes. (It will have to autoconfigure based on host provisioning, of course.)

Operation

If the host php configuration offers the igbinary serializer / deserializer for serializing php variables, this module uses it. That saves a lot of cache space, especially for large and complex cached objects.

If the SQLite3 extension does not exist, or its sqlite has a version prior to 3.7, the module cannot be used, and should not activate.

When activated this module puts its drop-in into .../wp-content/object-cache.php.

These are the drop-in's functions:

  • It handles, transparently, the creation of the .sqlite database file containing the necessary table to hold the cache.
  • It handles writing to, reading from, and deleting cache entries based on calls to wp_cache_set, wp_cache_get, and other WordPress core functions.
  • Exception handling. If it detects that the .sqlite database file is corrupt it transparently deletes and recreates the file. To the rest of WordPress this simply looks like the persistent object cache is flushed.
    This exception handling is necessary because the drop-in uses SQLite's MEMORY journal mode to reduce file-system IO. That journal mode, though significantly faster than the ACID-safe WAL mode, is more vulnerable to corruption on program crashes.
  • Controlled by an option setting, it records a log of the timing of its operations.
  • It offers function calls to
    • purge the cache (delete all its entries)
    • clean up the cache (delete expired entries)
    • retrieve entries from the timing log.
    • delete all entries from the timing log.

These are the functions of the module code managing the drop-in:

  • Install the drop-in on activation and remove it on deactivation.
  • Handle setting of options for:
    • Cache entry lifetime (expiration).
    • Controlling recording the timing log.
  • Use WP_Cron to regularly clean up the cache.
  • Summarize and display the content of the timing log.
  • Flush the timing log (delete all its entries).

Proof of concept

The proposed module is based on the code in the SQLite Object Cache plugin by @OllieJones. The source code to the current version of the plugin's object_cache.php drop-in is here.

@OllieJones OllieJones added [Focus] Object Cache Issues related to the Object Cache focus area Needs Discussion Anything that needs a discussion/agreement [Type] (Legacy) Module Proposal A new module proposal (legacy) labels Jan 18, 2023
@OllieJones
Copy link
Contributor Author

How well does the proof-of-concept perform? Here are some preliminary results. https://www.plumislandmedia.net/wordpress-plugins/sqlite-object-cache/benchmarks/

If you have a suggestion for how to test performance, please don't hesitate to suggest them, either here or at https://github.com/OllieJones/sqlite-object-cache/issues

@felixarntz felixarntz added the Performance Lab Plugin Issue relates to work in the Performance Lab Plugin only label Jul 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Object Cache Issues related to the Object Cache focus area Needs Discussion Anything that needs a discussion/agreement Performance Lab Plugin Issue relates to work in the Performance Lab Plugin only [Type] (Legacy) Module Proposal A new module proposal (legacy)
Projects
None yet
Development

No branches or pull requests

2 participants