Benchmark MemCP vs. MariaDB on Wordpress - Revision history

Carli at 21:54, 9 September 2026

2026-09-09T21:54:02Z

Show changes

Carli: /* Host PHP directly: remove a round trip for every small query */

2026-09-09T21:44:50Z

Host PHP directly: remove a round trip for every small query

Show changes

Carli at 21:43, 9 September 2026

2026-09-09T21:43:07Z

← Older revision		Revision as of 23:43, 9 September 2026
Line 9:		Line 9:

	Measured on master [https://github.com/launix-de/memcp/commit/43d0c81401616fafeeb456b22f4a47d6e25361d6 43d0c8140], including the SQL literal-parameterization improvement in PR #873. All three columns use the same seven WordPress query shapes and data snapshot. These are '''warm database round trips''', not HTTP page-load times. Lower is better.		Measured on master [https://github.com/launix-de/memcp/commit/43d0c81401616fafeeb456b22f4a47d6e25361d6 43d0c8140], including the SQL literal-parameterization improvement in PR #873. All three columns use the same seven WordPress query shapes and data snapshot. These are '''warm database round trips''', not HTTP page-load times. Lower is better.

			'''Dataset size:''' 22,063 rows in wp_posts (including 2,000 generated articles and 20,000 revisions), 14,013 post-metadata rows, 6,001 comments and 503 options. Taxonomy data comprises 175 terms, 175 term-taxonomy entries and 7,701 object-to-taxonomy relationships. These are the measured snapshot's table counts, not the number of rows returned by each query.

	Each value is the median of 11 batch means, each containing 100 complete query executions, after 30 warmups. For SQL_CALC_FOUND_ROWS statements, the measured operation also includes the subsequent SELECT FOUND_ROWS() on the same connection.		Each value is the median of 11 batch means, each containing 100 complete query executions, after 30 warmups. For SQL_CALC_FOUND_ROWS statements, the measured operation also includes the subsequent SELECT FOUND_ROWS() on the same connection.
Line 100:		Line 102:

	{\| class="wikitable"		{\| class="wikitable"
	! Table !! Rows		! Table !! Contents !! Rows
	\|-		\|-
	\| wp_posts \|\| 22,063		\| wp_posts \|\| Posts, pages, revisions and other post types \|\| 22,063
	\|-		\|-
	\| wp_postmeta \|\| 14,013		\| wp_postmeta \|\| Post metadata \|\| 14,013
	\|-		\|-
	\| wp_comments \|\| 6,001		\| wp_comments \|\| Comments \|\| 6,001
	\|-		\|-
	\| wp_options \|\| 503		\| wp_options \|\| Site options \|\| 503
	\|-		\|-
	\| wp_terms \|\| 175		\| wp_terms \|\| Terms (category/tag names) \|\| 175
	\|-		\|-
	\| wp_term_taxonomy \|\| 175		\| wp_term_taxonomy \|\| Term assignments to taxonomy types \|\| 175
	\|-		\|-
	\| wp_term_relationships \|\| 7,701		\| wp_term_relationships \|\| Object-to-taxonomy relationships \|\| 7,701
	\|}		\|}

Carli at 21:39, 9 September 2026

2026-09-09T21:39:03Z

← Older revision		Revision as of 23:39, 9 September 2026
Line 19:		Line 19:
	\| Elementor metadata join + LIMIT \|\| 0.152 \|\| 0.108 \|\| '''0.079''' \|\| 1.93× \|\| Equal; 0 rows		\| Elementor metadata join + LIMIT \|\| 0.152 \|\| 0.108 \|\| '''0.079''' \|\| 1.93× \|\| Equal; 0 rows
	\|-		\|-
	\| Taxonomy DISTINCT/join, ordered by name \|\| 0.224 \|\| 0.245 \|\| '''0.142''' \|\| ~~Master timing~~ \|\| ~~Fix: [https://github.com/launix-de/memcp/pull/871 PR #871] (in CI)~~		\| Taxonomy DISTINCT/join, ordered by name \|\| 0.224 \|\| 0.245 \|\| '''0.142''' \|\| 1.58× \|\| Equal
	\|-		\|-
	\| Comment count with join \|\| 3.240 \|\| 0.222 \|\| '''0.153''' \|\| 21.14× \|\| Equal; 1 row		\| Comment count with join \|\| 3.240 \|\| 0.222 \|\| '''0.153''' \|\| 21.14× \|\| Equal; 1 row
Line 29:		Line 29:
	\| Monthly archive DISTINCT \|\| 0.718 \|\| 0.168 \|\| '''0.116''' \|\| 6.21× \|\| Equal; 10 rows		\| Monthly archive DISTINCT \|\| 0.718 \|\| 0.168 \|\| '''0.116''' \|\| 6.21× \|\| Equal; 10 rows
	\|}		\|}

			Timing values are from master 43d0c8140. Taxonomy result equality (all 15 rows, including their order) was verified separately with [https://github.com/launix-de/memcp/pull/871 PR #871].

	The two metadata queries return zero rows on this snapshot. Their times describe proving an empty result, not retrieving a populated plugin workload. Tiny differences in the smallest queries are sensitive to scheduling on this shared development machine. We do not average these seven unrelated query shapes into a single WordPress speedup.		The two metadata queries return zero rows on this snapshot. Their times describe proving an empty result, not retrieving a populated plugin workload. Tiny differences in the smallest queries are sensitive to scheduling on this shared development machine. We do not average these seven unrelated query shapes into a single WordPress speedup.

Carli at 21:36, 9 September 2026

2026-09-09T21:36:55Z

← Older revision		Revision as of 23:36, 9 September 2026
Line 2:		Line 2:
	<!-- SPDX-License-Identifier: AGPL-3.0-or-later -->		<!-- SPDX-License-Identifier: AGPL-3.0-or-later -->

	~~= Benchmark MemCP vs. MariaDB on Wordpress =~~		'''MemCP makes repeated WordPress database work faster.''' On current master, MemCP-JIT completes this fixture's search plus total-count query '''36.0× faster''' than MariaDB, its comment count '''21.1× faster''', and its archive query '''6.2× faster'''. MemCP-JIT has lower measured warm latency across all seven query shapes in this run.

	'''MemCP makes repeated WordPress database work faster.''' On current master, MemCP-JIT completes this fixture's search plus total-count query '''36.0× faster''' than MariaDB, its comment count '''21.1× faster''', and its archive query '''6.2× faster'''. ~~All six query shapes with matching results have~~ lower warm latency ~~with JIT~~ in this run~~. The seventh, a taxonomy query, is retained in the matrix with a clearly marked collation mismatch~~.

	MemCP speaks the MySQL protocol and can also '''host PHP directly in the database process'''. WordPress is our example application: the hosting interface is general purpose and is also intended for MediaWiki and other PHP software. Try MemCP with your PHP hosting and measure the queries your application actually runs.		MemCP speaks the MySQL protocol and can also '''host PHP directly in the database process'''. WordPress is our example application: the hosting interface is general purpose and is also intended for MediaWiki and other PHP software. Try MemCP with your PHP hosting and measure the queries your application actually runs.
Line 21:		Line 19:
	\| Elementor metadata join + LIMIT \|\| 0.152 \|\| 0.108 \|\| '''0.079''' \|\| 1.93× \|\| Equal; 0 rows		\| Elementor metadata join + LIMIT \|\| 0.152 \|\| 0.108 \|\| '''0.079''' \|\| 1.93× \|\| Equal; 0 rows
	\|-		\|-
	\| Taxonomy DISTINCT/join, ordered by name \|\| 0.224 \|\| 0.245 \|\| '''0.142''' \|\| ~~Diagnostic only~~ \|\| ~~See correctness notes below~~		\| Taxonomy DISTINCT/join, ordered by name \|\| 0.224 \|\| 0.245 \|\| '''0.142''' \|\| Master timing \|\| Fix: [https://github.com/launix-de/memcp/pull/871 PR #871] (in CI)
	\|-		\|-
	\| Comment count with join \|\| 3.240 \|\| 0.222 \|\| '''0.153''' \|\| 21.14× \|\| Equal; 1 row		\| Comment count with join \|\| 3.240 \|\| 0.222 \|\| '''0.153''' \|\| 21.14× \|\| Equal; 1 row
Line 118:		Line 116:

	The corpus contains 2,000 varied generated articles across 16 topics and 20,000 revisions. Titles, excerpts and bodies vary; body lengths range from 396 to 6,996 bytes (median 1,763). The search query uses realistic, present in 80 generated articles; the full query also considers other post types. Low-cardinality fields such as status and categories naturally repeat. This version-2 corpus must not be mixed with older version-1 measurements.		The corpus contains 2,000 varied generated articles across 16 topics and 20,000 revisions. Titles, excerpts and bodies vary; body lengths range from 396 to 6,996 bytes (median 1,763). The search query uses realistic, present in 80 generated articles; the full query also considers other post types. Low-cardinality fields such as status and categories naturally repeat. This version-2 corpus must not be mixed with older version-1 measurements.

	~~== Correctness and scope ==~~

	Six of the seven exact queries return matching results in all three modes, including the total counts: '''83''' for the search and '''0''' for the Yoast query. After import, rebuild and restart, all 22,063 post IDs, titles, excerpts and body texts also match a canonical SHA-256 comparison. The previously reported blob-content mismatch and search total of 82 were '''not reproduced in this fresh master run'''; they are not carried forward as current failures.

	The remaining difference is the taxonomy query. Its exact captured SQL '''does contain ORDER BY t.name ASC'''. Both engines return the same 15 projected rows, but in a different name order. MariaDB exposes wp_terms.name as utf8mb4_unicode_520_ci; this fresh MemCP import exposes utf8mb4. Therefore its timing is diagnostic and excluded from accepted speedup claims. This statement applies to this saved query, not to every WordPress taxonomy query. Without an ORDER BY, a different row order alone would not be a correctness failure.

	This benchmark does not include the unmerged type/collation fix in PR #871. It reports current master as measured. The taxonomy collation discrepancy remains a migration issue for this schema and should be resolved before relying on equivalent ordering.

	These are query-level correctness checks and a post-text integrity check, not an exhaustive application compatibility test. INSERT/UPDATE workloads, parallel PHP requests, maintenance costs, cold starts and HTTP page-load latency are outside this matrix.

	== Try MemCP with your PHP hosting ==		== Try MemCP with your PHP hosting ==

Carli at 21:36, 9 September 2026

2026-09-09T21:36:38Z

← Older revision		Revision as of 23:36, 9 September 2026
Line 3:		Line 3:

	= Benchmark MemCP vs. MariaDB on Wordpress =		= Benchmark MemCP vs. MariaDB on Wordpress =


	'''MemCP makes repeated WordPress database work faster.''' On current master, MemCP-JIT completes this fixture's search plus total-count query '''36.0× faster''' than MariaDB, its comment count '''21.1× faster''', and its archive query '''6.2× faster'''. All six query shapes with matching results have lower warm latency with JIT in this run. The seventh, a taxonomy query, is retained in the matrix with a clearly marked collation mismatch.		'''MemCP makes repeated WordPress database work faster.''' On current master, MemCP-JIT completes this fixture's search plus total-count query '''36.0× faster''' than MariaDB, its comment count '''21.1× faster''', and its archive query '''6.2× faster'''. All six query shapes with matching results have lower warm latency with JIT in this run. The seventh, a taxonomy query, is retained in the matrix with a clearly marked collation mismatch.
Line 118:		Line 117:
	\|}		\|}

	The corpus contains 2,000 varied generated articles across 16 topics and 20,000 revisions. Titles, excerpts and bodies vary; body lengths range from 396 to 6,996 bytes (median 1,~~764~~). The search query uses realistic, present in 80 generated articles; the full query also considers other post types. Low-cardinality fields such as status and categories naturally repeat. This version-2 corpus must not be mixed with older version-1 measurements.		The corpus contains 2,000 varied generated articles across 16 topics and 20,000 revisions. Titles, excerpts and bodies vary; body lengths range from 396 to 6,996 bytes (median 1,763). The search query uses realistic, present in 80 generated articles; the full query also considers other post types. Low-cardinality fields such as status and categories naturally repeat. This version-2 corpus must not be mixed with older version-1 measurements.

	== Correctness and scope ==		== Correctness and scope ==
Line 138:		Line 137:
	== Measurement artifacts and exact queries ==		== Measurement artifacts and exact queries ==

	Local artifact directory: <code>../wordpress-db-lab/measurements/wiki-master-43d0c8140/</code>. It contains results-master.json (raw batch means and complete query results), php-latency.json (all PHP samples), manifest.json, counts.json, server logs, and a copied benchmark.py. The SQL runner can be repeated against the same fixture; its WP_BINARY and WP_WORKTREE overrides are for separately labelled candidate checks. Candidate measurements are not included in this master matrix.		Local artifact directory: <code>../wordpress-db-lab/measurements/wiki-master-43d0c8140/</code>. It contains results-master.json (raw batch means and complete query results), php-latency.json (all PHP samples), manifest.json, counts.json, corpus.json, text-parity.json, server logs, and a copied benchmark.py. The SQL runner can be repeated against the same fixture; its WP_BINARY and WP_WORKTREE overrides are for separately labelled candidate checks. Candidate measurements are not included in this master matrix.

	Source queries: <code>../wordpress-db-lab/profiles/queries/</code>. They are reproduced below so that the benchmark shapes, including actual ORDER BY clauses, are unambiguous.		Source queries: <code>../wordpress-db-lab/profiles/queries/</code>. They are reproduced below so that the benchmark shapes, including actual ORDER BY clauses, are unambiguous.

Carli at 21:34, 9 September 2026

2026-09-09T21:34:24Z

Show changes

Carli: Created page with " = Benchmark MemCP vs. MariaDB on Wordpress = WordPress does more than fetch individual posts. Category pages, comment counters, search, archive lists, and plugin metadata queries repeatedly join and aggregate data. These are the places where a different database engine can make a noticeable difference. We compared '''MariaDB, MemCP, and MemCP with JIT''' using seven SQL..."

2026-09-08T18:50:50Z

Created page with "  = Benchmark MemCP vs. MariaDB on Wordpress = WordPress does more than fetch individual posts. Category pages, comment counters, search, archive lists, and plugin metadata queries repeatedly join and aggregate data. These are the places where a different database engine can make a noticeable difference. We compared '''MariaDB, MemCP, and MemCP with JIT''' using seven SQL..."

New page

= Benchmark MemCP vs. MariaDB on Wordpress =

WordPress does more than fetch individual posts. Category pages, comment counters, search, archive lists, and plugin metadata queries repeatedly join and aggregate data. These are the places where a different database engine can make a noticeable difference.

We compared '''MariaDB, MemCP, and MemCP with JIT''' using seven SQL queries captured from a WordPress installation. On the tested master revision, JIT-enabled MemCP completed the comment-count query '''25.5 times faster''' and the archive query '''4.8 times faster''' than MariaDB. A simple option lookup was effectively tied. Two small metadata queries still favored MariaDB.

For administrators, the takeaway is specific: '''MemCP offers substantial potential for recurring aggregates, but the right migration decision depends on your site's query mix, correctness, and cache behavior—not one headline multiplier.'''

{| class="wikitable"
| '''Status of this measurement — 8 September 2026'''
The tested master revision has two known correctness issues exposed by this fixture: a blob-reference decoding problem and lost collation in the grouped taxonomy plan. Search also returns an incorrect total count. The affected timings below are diagnostic only, not accepted speedup claims. This is a development benchmark supporting a staging evaluation, '''not a recommendation to replace a production WordPress database with this revision'''.
|}

== The results at a glance ==

The following values are '''warm end-to-end database latency''': sending SQL over an established TCP/MySQL connection and receiving the complete result. For the search and SEO queries, the time also includes a subsequent <code>SELECT FOUND_ROWS()</code> on the same connection.

'''Lower is better.''' The comparison column is MariaDB versus MemCP JIT—not JIT versus vanilla.

{| class="wikitable sortable"
! WordPress workload
! MariaDB
! MemCP
! MemCP + JIT
! MemCP JIT compared with MariaDB
! Result check
|-
| Option lookup (<code>siteurl</code>)
| 0.082 ms
| 0.116 ms
| 0.081 ms
| Effectively tied; approximately 1% lower latency
| Same single row
|-
| Plugin metadata join with LIMIT
| 0.141 ms
| 0.211 ms
| 0.200 ms
| 41.9% higher latency
| Same empty result
|-
| Taxonomy join and DISTINCT
| 0.222 ms
| 0.222 ms
| 0.179 ms
| Not scored: ordering differs
| Same 15 rows, different order
|-
| Comment COUNT with exclusion join
| 4.053 ms
| 0.173 ms
| '''0.159 ms'''
| '''25.5× faster; 96.1% lower latency'''
| Same aggregate result
|-
| WordPress search and total count
| 31.457 ms
| 2.192 ms
| 1.766 ms
| Not scored: total count differs
| Same first 10 rows; total 82 instead of 83
|-
| SEO metadata CAST/range join
| 0.177 ms
| 0.225 ms
| 0.198 ms
| 11.8% higher latency
| Same empty result and total of zero
|-
| DISTINCT year/month archive
| 0.666 ms
| 0.158 ms
| '''0.138 ms'''
| '''4.8× faster; 79.2% lower latency'''
| Same 10 ordered rows
|}

The empty metadata results are intentional disclosures, not successful-hit performance tests. They measure how quickly each engine establishes that there are no matching records in this snapshot. They do not establish performance for populated plugin result sets.

There is no combined “WordPress speedup” score. The frequency of these queries differs between sites, and a correctness failure must not be averaged into a favorable result.

== What this means for a WordPress administrator ==

=== Look for expensive repeated database work ===

A site dominated by indexed point lookups has less to gain from the results here: the option lookup took about 0.08 ms in both MariaDB and JIT-enabled MemCP. A site spending database time on counts, joins, and archive aggregates has a more promising starting point.

For example, the measured comment-count query saves approximately '''3.89 ms per execution'''. That can matter if the query is frequent or occurs repeatedly while rendering an uncached request. It does not imply that the entire PHP request becomes 25 times faster.

Use your own slow-query trace or query-monitoring output to identify the statements that dominate database time. Include frontend pages, administration screens, searches, and scheduled plugin work.

=== Understand what is warm ===

MemCP can reuse compiled query plans and incrementally maintained relational structures such as group caches and prejoins. These structures help avoid repeating a join or aggregate from scratch.

A warm read benchmark benefits from that reuse. It does '''not''' measure the complete cost of maintaining those structures under writes. New comments, imports, metadata updates, and bulk edits therefore belong in a separate staging test.

JIT is another part of execution: eligible code is compiled to native instructions. It is not permission to change SQL results, and it does not make every query faster. The vanilla column shows that much of the aggregate advantage is already present without JIT.

=== Budget for the first request ===

Fast warm responses do not imply that the first request is equally fast. In this run, selected first-query and warm values were:

{| class="wikitable"
! Query
! MemCP first query
! MemCP + JIT first query
! MemCP + JIT warm median
|-
| Plugin metadata join
| 42.3 ms
| 33.2 ms
| 0.200 ms
|-
| Comment COUNT
| 52.1 ms
| 66.2 ms
| 0.159 ms
|-
| WordPress search — correctness issue
| 1,957.7 ms
| 2,553.0 ms
| 1.766 ms
|-
| Archive
| 13,652.3 ms
| 14,560.0 ms
| 0.138 ms
|}

Preparation can also occur after the first execution. During the 20 warmup requests, the plugin metadata query had an approximately 650 ms outlier in each MemCP mode; the search had approximately 580 ms outliers.

These are '''observed first-query latencies after restarting each MemCP process''', not a controlled empty-cache comparison: persisted structures and operating-system caches were retained, and vanilla ran before JIT against the same data directory. Server startup itself is not included in these values.

For a migration rehearsal, measure first requests after restart, cache eviction, and representative writes separately. Do not use the warm table to set cold-start service-level expectations.

== A more useful WordPress fixture ==

The queries come from a WordPress installation using common plugins, including WooCommerce, Elementor, Yoast SEO, Advanced Custom Fields, and Contact Form 7. No plugin receives a special place in the scoring; the seven statements cover distinct kinds of database work.

The measured '''version-2 queryset fixture''' contains these seven tables—not the complete live WordPress installation:

{| class="wikitable"
! Table
! Rows
|-
| <code>wp_posts</code>
| 22,063, including 20,000 revisions
|-
| <code>wp_postmeta</code>
| 14,013
|-
| <code>wp_comments</code>
| 6,001
|-
| <code>wp_options</code>
| 503
|-
| <code>wp_terms</code>
| 175
|-
| <code>wp_term_taxonomy</code>
| 175
|-
| <code>wp_term_relationships</code>
| 7,701
|}

Version 1 repeated essentially the same search-bearing paragraph in every generated article. Version 2 replaces that with 2,000 different titles, excerpts, and article bodies across 16 topics. Article bodies range from 396 to 6,996 bytes, with a median of 1,764 bytes. Revisions retain their parent document's content with an editorial change; low-cardinality fields such as status and categories still repeat naturally.

The generator deliberately provides several search frequencies over the 2,000 generated articles:

* <code>nightjar</code>: 10 matches, or 0.5%;
* <code>realistic</code>: 80 matches, or 4%;
* <code>performance</code>: 240 matches, or 12%;
* <code>quasarless</code>: no matches.

These are corpus checks, '''not four separately timed search workloads'''. The captured search query uses <code>realistic</code>. Its SQL also considers pages and other post types and applies additional predicates, so its complete MariaDB total is 83 rather than 80.

This is a controlled synthetic dataset with real captured query shapes. It is not evidence of performance at millions of posts or under concurrent production traffic. The gains on counts and archives justify testing larger datasets; they do not replace that test.

== Correctness before speed ==

Results were compared across engines, including <code>FOUND_ROWS()</code> where applicable. Five query shapes agreed; two did not.

=== Taxonomy ordering ===

Both databases expose <code>wp_terms.name</code> with <code>utf8mb4_unicode_520_ci</code>. A direct ordered scan agrees, but the full DISTINCT/join plan loses that collation at its grouped sort. For example, MemCP places <code>Uncategorized</code> before lower-case tag names.

This is '''not an unspecified tie order'''. It is a correctness issue, and the taxonomy timing is excluded from speedup claims.

=== Blob content and search totals ===

Full table contents matched checksums immediately after import. After MemCP compaction, 33 long post-content values were observed as 32-byte blob hashes instead of their text. A hash beginning with <code>!</code> collides with the legacy escaped-string encoding.

For one affected post, MariaDB reports a text length of 5,327 bytes and MemCP reports 32. The search's first ten rows agree, but MemCP reports 82 total matches versus MariaDB's 83. Consequently the search timing is also excluded from accepted speedup claims.

These findings must be resolved and the affected workloads revalidated before using this revision for migration. No query was removed from the table to conceal them. All 21 measurements completed without a process crash.

== How the comparison was run ==

{| class="wikitable"
! Item
! Configuration
|-
| MemCP source
| [https://github.com/launix-de/memcp/commit/ce26bfb3deb883efc09272965cc1a3b9eb177e24 Master ce26bfb3d], including the merged Q1/Q3 planner improvements
|-
| Date
| 8 September 2026
|-
| MariaDB
| 10.11.14; query cache disabled; InnoDB buffer pool 128 MiB
|-
| MemCP builds
| Identical source, both built with the patched Go 1.27.0 toolchain; <code>GOEXPERIMENT</code> empty versus <code>GOEXPERIMENT=jit</code>
|-
| Host
| AMD Ryzen 9 7900X3D, 12 cores / 24 logical CPUs; approximately 62 GiB RAM
|-
| Client
| Python/PyMySQL over local TCP; established connections, autocommit
|-
| Sampling
| 20 warmup executions, then 11 batches of 100 executions per query and engine
|-
| Reported statistic
| Median of the 11 batch means, in milliseconds per query or query/FOUND_ROWS pair
|-
| Execution order
| MariaDB, MemCP vanilla, MemCP JIT
|-
| Run duration
| Approximately 93 seconds, excluding builds, fixture import, and investigation
|}

The host was shared with development work and was not isolated for benchmarking. Small percentage differences should not be overinterpreted. The results are not a memory-budget-matched or concurrency-throughput comparison.

The query-plan cache and normal execution behavior remained enabled. We did not substitute hand-written plans or force a special prejoin before timing. The setup contains no application-level page-cache measurement: this is database latency, not HTTP page-render time.

The measurements are specific to this master snapshot and fixture. Earlier version-1 numbers should not be mixed with this table or used to calculate an improvement attributable solely to a planner patch.

== A practical staging checklist ==

Before deciding whether MemCP will speed up your WordPress installation:

# '''Capture your workload.''' Include expensive frontend queries, admin pages, search, and the plugins your site actually uses.
# '''Use one consistent data snapshot.''' Preserve IDs, relationships, text, and collations. Compare contents after import and after compression/restart—not just table row counts.
# '''Check complete results.''' Validate ordering, pagination, NULL behavior, aggregates, and total counts, including <code>FOUND_ROWS()</code>.
# '''Separate first use from steady state.''' Record startup/cache-build spikes, warm medians, and tail latency.
# '''Exercise writes and concurrency.''' Test comments, edits, imports, plugin jobs, cache maintenance, and recovery. This read-only query benchmark does not establish their cost or compatibility.
# '''Measure whole requests too.''' PHP, plugin execution, network requests, and page caching can dominate total page time even when SQL becomes faster.
# '''Keep production unchanged until validation passes.''' Retain your MariaDB deployment and a tested backup/rollback path during evaluation. The known correctness issues above must be closed first.

MemCP's strongest result here is the reduction of recurring aggregate work from milliseconds to a fraction of a millisecond. For WordPress administrators, that is a concrete reason to evaluate it—but equivalent results and predictable operations remain the entry requirements for any speed claim.