WooCommerce 11 exposes controls around POS catalog chunk generation. A larger chunk can reduce request count but increase PHP memory, serialization time, object-store size, CDN transfer, client parsing time, and retry cost. A smaller chunk can overload queues and create long sync windows. The correct setting depends on catalog shape, variation count, metadata, images, infrastructure, and the slowest supported device.
Use this for stores synchronizing products to point-of-sale devices, especially catalogs with many variations, custom fields, price lists, or frequent inventory changes. Test with a production-like sanitized catalog and at least one lower-powered supported device.
Quick answer
Choose three or four candidate chunk sizes, freeze a representative catalog snapshot, and generate a full catalog plus an incremental update for each setting. Measure server duration, peak memory, query count, queue depth, object size, transfer time, client parse and apply time, retries, missing products, stale prices, and total sync completion. Select the smallest setting that meets the operational sync target with comfortable headroom.
What to check first
- Record product, variation, category, attribute, image, custom meta, multilingual, price-list, and inventory-update counts in the benchmark snapshot.
- Capture PHP workers, memory, database, object cache, Action Scheduler, storage, CDN, network, device CPU and memory, and POS app version.
- Benchmark cold full generation, warm regeneration, one-product update, one-variable-product update, price batch, and inventory burst for each chunk size.
- Measure p50 and p95 generation, peak memory, database queries, queue delay, chunk bytes, transfer, parse, apply, retry count, and end-to-end freshness.
- Compare source catalog IDs and revision markers with the device catalog after every run, including interruption and resume.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze a representative catalog snapshot | Record product, variation, category, attribute, image, custom meta, multilingual, price-list, and inventory-update counts in the benchmark snapshot. | Every candidate uses the same catalog revision and infrastructure. |
| Benchmark several chunk sizes cold and warm | Capture PHP workers, memory, database, object cache, Action Scheduler, storage, CDN, network, device CPU and memory, and POS app version. | Server and device p95 values stay below operational thresholds. |
| Measure server, network, and device costs | Benchmark cold full generation, warm regeneration, one-product update, one-variable-product update, price batch, and inventory burst for each chunk size. | Interrupted sync resumes without duplicate, missing, or stale records. |
| Test interruption and incremental freshness | Measure p50 and p95 generation, peak memory, database queries, queue delay, chunk bytes, transfer, parse, apply, retry count, and end-to-end freshness. | The selected setting has alerts for queue delay, retries, age, and catalog mismatch. |
Why this usually happens
- Variation-heavy products make equal product counts produce very different payload sizes.
- Custom metadata and multilingual fields increase serialization and client parsing cost.
- A timeout can leave a valid object in storage while the queue marks the job failed and retries it.
- CDN or object cache behavior can make warm tests look better than first-run rollout.
- A powerful desktop test device can hide memory and apply-time limits on store hardware.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
run_id: WC11-POS-CHUNK-06
catalog_products: 42000
variations: 118000
chunk_size: 250
chunks_created: 168
server_p95_seconds: 8.4
peak_memory_mb: 312
chunk_p95_mb: 3.8
device_apply_p95_seconds: 2.7
retries: 0
missing_products: 0
stale_prices: 0
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Freeze a representative catalog snapshot
- Benchmark several chunk sizes cold and warm
- Measure server, network, and device costs
- Test interruption and incremental freshness
- Choose a setting with monitored headroom
Decision rule
Choose the largest chunk that stays below documented server and device limits with enough headroom for catalog growth, while meeting the total sync target and producing zero missing or stale records. Average build time alone is not a safe decision metric.
What to tell the client or owner
Give the site owner the affected version, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Every candidate uses the same catalog revision and infrastructure.
- Server and device p95 values stay below operational thresholds.
- Interrupted sync resumes without duplicate, missing, or stale records.
- The selected setting has alerts for queue delay, retries, age, and catalog mismatch.
Mistakes to avoid
- Do not benchmark only ten simple products.
- Do not select a chunk size from server time while ignoring client parsing.
- Do not compare cold and warm runs as if they were equivalent.
- Do not change chunk size in production without a rollback value and freshness monitor.
Questions teams ask during testing
Is a larger chunk always faster?
No. It can reduce request count while increasing processing, transfer, parsing, and retry cost. Measure end-to-end completion.
What should trigger a rollback?
Repeated timeouts, memory pressure, growing queue age, device parse failures, or any product, price, and stock mismatch should return the system to the last proven setting.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, benchmark a WooCommerce catalog.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references