samjuk / m2-module-cache-debounce
Debounce FPC cache purges to a set schedule
SamJUK_CacheDebounce
This module debounces/defers/delays FPC cache purge requests to occur on a set schedule. Allowing you to make a trade off between cache accuracy and backend load.
Particularly useful for a ERP solutions that like to issue significant stock updates, in turn flushing cache regularly especially for common parent categories.
If you require a more aggressive solution, such as disabling Cache Flushes entirely then Hypershop_SpikePerformance might be a better solution for you.
Proof Of Concept
The module was tested on a fresh Luma store with Sample Data, running on CPX31 VPS (4vCPU, 8GB Memory).
Traffic was generated via a golang based sitemap crawler running back to back.
A stock management integration was mocked by, setting a random QTY on a random Sku every 1 second via the PUT StockItems route.
[image: Before and After Metrics for a POC store]
Installation
composer config repositories.samjuk-m2-module-cache-debounce vcs [email protected]:SamJUK/m2-module-cache-debounce.git
composer require samjuk/m2-module-cache-debounce:@dev
php bin/magento setup:upgrade && php bin/magento cache:flush
Configuration
Configuration can be handled via System configuration, from within the Cache Debounce menu of the SamJUK Tab.
Or can be set via the CLI with the command
php bin/magento config:set <path> <value>
| Option | Config Path | Default | Description |
|---|---|---|---|
| Enabled | samjuk_cache_debounce/general/enabled |
0 |
Feature flag to toggle functionality of the module |
| Flush Schedule | samjuk_cache_debounce/cron/flush_schedule |
*/5 0 0 0 0 |
Cron schedule to run the scheduled flush |
Will this help my store?
The performance improvement comes from improving cache performance by reducing the amount of cache purge requests in turn reducing system load.
To check how many cache invalidations your system is issuing, you can enable debug logging, which will add some cache invalidate entries to your var/log/debug.log file.
php bin/magento setup:config:set --enable-debug-logging=true && php bin/magento cache:flush
If you do not want to enabling debug logging in production for some reason, maybe log ingest limitations. You can patch the invalidation logger to change the log level to info, so they appear within the system.log file.
--- vendor/magento/framework/Cache/InvalidateLogger.php
+++ vendor/magento/framework/Cache/InvalidateLogger.php
@@ -43,7 +43,7 @@
*/
public function execute($invalidateInfo)
{
- $this->logger->debug('cache_invalidate: ', $this->makeParams($invalidateInfo));
+ $this->logger->info('cache_invalidate: ', $this->makeParams($invalidateInfo));
}
/**
No changelog yet
The vendor hasn't published a changelog. Tagged releases appear in the Versions tab.
Requires 1
| Package | Constraint |
|---|---|
| php | ^7.0|^8.0 |
Requires-dev 2
| Package | Constraint |
|---|---|
| phpstan/phpstan | ^1.12 |
| phpunit/phpunit | ^10.5 |
Compatibility
Each Magento release line is installed on its supported PHP versions, then the module is built (DI compilation + static-content deploy) and its unit and integration suites are run. The matrix shows the lines and PHP versions the module is confirmed to install and run on. Code-quality results further down (phpstan, phpcs, …) are reported separately and never affect compatibility.
Code Quality
Advisory checks against the module's source. Static analysis runs once across the whole module; PHPStan re-runs per Magento + PHP version because resolvable symbols differ between releases. These NEVER affect the Compatibility badge. A phpcs finding can't make a module incompatible.
Static analysis
Coding standards (phpcs), mess detection (phpmd), copy-pasted code (cpd), PHP cross-version compatibility, composer.json validity. Each runs once for the whole module.
PHPStan
Type-checks the module's PHP against a real Magento install at the configured gate level. Re-runs per Magento and PHP version because resolvable symbols differ between releases.
Tests
Unit and integration suites, run for each applicable Magento and PHP version. A test failure speaks to the module's behaviour, not its compatibility with a Magento line, so it is reported here separately and never reddens the compatibility matrix.
Security
Security checks run directly against the module: an audit of its declared dependencies for known vulnerabilities (composer audit) and a scan of its source for malware and web-shell signatures. Each runs once. A malware detection fails the version outright.
More from samjuk
View vendorAdds ability to set fetch priority attributes, preload/prefetch links for admin content. As well as a public API for extension from 3rd party modules
Adds a verbose mode to the setup:db:status command, to assist with debugging DB schema differences
Turn an existing module into recurring revenue.
If you already maintain a Magento 2 module on GitHub or GitLab, listing it on Packagento takes about five minutes. We mirror your tags, handle distribution signing, and route paid licenses through Stripe Connect, so you can keep shipping the way you already do.