1,000,000 Products: Redis Object Cache On vs Off

A persistent Redis object cache makes no measurable difference to a Super Speedy Imports run. We imported the same 1,000,000 simple WooCommerce products with the object cache on and off, on both the Pro edition and the wp.org Lite edition. Like for like, Pro was 4.2% faster with the cache and wp.org Lite was 1.4% slower – opposite directions, run-to-run variance. Peak PHP memory was identical, and across roughly 16 million database rows moved, the cache itself grew by a few hundred housekeeping keys and (on the Pro run) 0.1 MB.

Summary

• Result: object cache on vs off is noise in both editions. Pro: 1,056.3s of import-stage time with cache vs 1,102.7s without. wp.org Lite: 5,026.7s vs 4,959.4s.
• Why: the import engine moves rows with bulk INSERT ... SELECT statements, from staging table to live table inside MySQL. WordPress’s APIs never see the rows, so neither does the object cache – in either direction. Nothing to invalidate, nothing to warm.
• What this means for you: if you run Redis or Memcached on your store (and for storefront browsing you probably should), you don’t need to disable it for imports, and you shouldn’t expect it to speed them up either.
• Memory: peak PHP memory unchanged – 206.73 MB (Pro) and 212.73 MB (wp.org Lite), cache on.

Results

The stages-vs-stages rows are the cleanest comparison – both measured identically by the plugin’s own per-stage timers. The no-cache totals come from the 2026-07-17 Pro vs Lite runs of the same dataset on the same server. Careful when comparing import benchmarks generally: quoting stage time against someone else’s wall clock (or vice versa) hides roughly four minutes of WooCommerce housekeeping and can fabricate a ~25% difference that isn’t there.

Object cache activity during the imports

We sampled the cache every minute or two throughout both runs. A million products came in; the object cache gained a few hundred keys of option and transient housekeeping. The Lite run’s Redis finished 20 MB above baseline – still trivial next to the data imported, and most likely a handful of large transients written by WooCommerce’s post-import housekeeping caught at a different moment than on the Pro run.

Per-stage breakdown (cache on)

The Pro/Lite gap is unrelated to caching: wordpress.org rules forbid proc_open, so the wp.org edition runs single-worker, and fix-attributes – the one heavy stage that parallelises well – accounts for 63 of its 84 stage-minutes. Same pattern as the no-cache runs.

How we enabled and verified the object cache

• Redis over a unix socket with the Redis Object Cache plugin (2.7.0), enabled via wp redis enable; wp redis status reported Status: Connected, Drop-in: Valid before each run.
• Cross-process proof: we wrote a value with wp_cache_set() in one WP-CLI process and read it back with wp_cache_get() from a second, separate process. That round-trip is only possible with a persistent object cache – the default in-memory cache dies with its process.
• We then sampled the cache’s key count and memory every minute or two for the duration of both imports.

Methodology

• Server: Hetzner cloud, 4 vCPU, 7.6 GB RAM, PHP 8.2, MariaDB, WooCommerce, WordPress. MariaDB temp files on disk. Restored to the same clean snapshot (0 products, 0 terms) before each run.
• Plugin: Super Speedy Imports 2.75.0 – Pro and wp.org Lite editions, both built from the same source the same day. --workers=4 --performance (the wp.org edition self-caps to a single worker).
• Baseline comparison: the 2026-07-17 no-cache runs of the same dataset, same server, same flags. One run per configuration (indicative, not averaged).

Dataset and reproduce

• Dataset (311 MB CSV): simple-products-1m.csv – 1,000,000 simple products with hierarchical category, brand, tags and five attributes (~10 million term relationships), external images.
• Config and taxonomies: the simple-products-1m folder in the super-speedy-imports-demo-data repo.

1. Install Redis + the Redis Object Cache plugin; wp redis enable and confirm wp redis status says Connected.
2. wp ssi import-taxonomies taxonomies.json
3. wp ssi create "1M Simple" product simple-products-1m.csv config.json
4. time wp ssi <id> --workers=4 --performance