Bug Description
Statamic::isWorker() disables Statamic's in-process memoisation whenever the running command starts with queue: or horizon:. The intent is sound — a long-running worker must not serve stale data — but the switch is process-wide, so it also disables memoisation within a single job, where nothing can go stale that the job should have seen.
On a test site seeded with a 17,000-file asset container and 100 seeded entries sync driver is 29.2ms per search doc, redis is 2.0s/doc → ~68.5x slower
How to reproduce
On a site w/ many entries and assets, run a search update with sync driver then w/ redis and compare times.
Environment
Environment
Laravel Version: 13.24.0
PHP Version: 8.5.8
Composer Version: 2.10.1
Environment: local
Debug Mode: ENABLED
Maintenance Mode: OFF
Timezone: UTC
Locale: en
Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: NOT CACHED
Drivers
Broadcasting: null
Cache: redis
Database: sqlite
Logs: stack / daily
Mail: log
Queue: redis
Session: file
Storage
public/storage: NOT LINKED
Livewire
Livewire: v4.3.5
Statamic
Addons: 11
License Key: Set
Sites: 1
Stache Watcher: Disabled
Static Caching: half
Version: 6.26.0 PRO
Statamic Addons
aryehraber/statamic-captcha: 1.17.0
jacksleight/statamic-bard-mutator: 3.0.5
jacksleight/statamic-distill: 1.2.0
marcorieser/statamic-livewire: 5.3.1
statamic-rad-pack/typesense: 3.2.1
statamic/seo-pro: 7.13.0
transformstudios/events: 6.1.2
transformstudios/front: 3.1.2
transformstudios/github: 6.0.0
transformstudios/prime: 6.6.0
transformstudios/review: 6.0.0
Installation
Private site builder
Additional details
Statamic 6.26, ~2,600 entries, statamic.search.chunk_size of 100. Same site, same content, same search driver, warm caches, STATAMIC_STACHE_WATCHER=false.
|
per document |
full reindex |
QUEUE_CONNECTION=sync php please search:update |
~37ms |
~95 seconds |
Same jobs via php artisan queue:work |
~1.2s |
~24 minutes (26 jobs at ~55s) |
I confirmed this isn't the queue itself. Popping the same job payloads off Redis and calling $job->handle() in a plain script — where argv[1] is not queue:* — ran them at ~0.56s per 10-document job. The identical payloads under queue:work took ~16s each. The only difference is what isWorker() returns.
Bug Description
Statamic::isWorker()disables Statamic's in-process memoisation whenever the running command starts withqueue:orhorizon:. The intent is sound — a long-running worker must not serve stale data — but the switch is process-wide, so it also disables memoisation within a single job, where nothing can go stale that the job should have seen.On a test site seeded with a 17,000-file asset container and 100 seeded entries
syncdriver is 29.2ms per search doc,redisis 2.0s/doc → ~68.5x slowerHow to reproduce
On a site w/ many entries and assets, run a search update with
syncdriver then w/redisand compare times.Environment
Installation
Private site builder
Additional details
Statamic 6.26, ~2,600 entries,
statamic.search.chunk_sizeof 100. Same site, same content, same search driver, warm caches,STATAMIC_STACHE_WATCHER=false.QUEUE_CONNECTION=sync php please search:updatephp artisan queue:workI confirmed this isn't the queue itself. Popping the same job payloads off Redis and calling
$job->handle()in a plain script — whereargv[1]is notqueue:*— ran them at ~0.56s per 10-document job. The identical payloads underqueue:worktook ~16s each. The only difference is whatisWorker()returns.