Parallel Stache warming produces inconsistent Stache `_indexes`
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- php
- Domain
- backend, performance
Research direction
Start by reading the parallel Stache warming change in PR #12894, then enable parallel_processing with the fork concurrency driver and run the Stache warm command. Compare storage/framework/cache/data/stache/indexes/**/_indexes across repeated runs and with the v5.69.0 output. Done means the indexes are consistent between runs and the reported difference is addressed; the performance concern may need to be treated separately.
Written by the indexing model from the issue text.
Description
Bug description
After enabling the new parallel Stache warming (introduced in v5.70.0), the generated Stache _indexes become inconsistent between runs and differ from the output produced in the versions before the PR.
How to reproduce
- Enable parallel Stache warming (e.g. parallel_processing = true, concurrency_driver = fork) on 5.70.0.
- Run the Stache warm command and check
storage/framework/cache/data/stache/indexes/**/_indexes
v5.69.0:
Indexes are not changing when running the stache warm command multiple times.
9999999999a:1:{i:0;s:4:"path";}
v5.70.0:
Indexes are changing when running the stache warm command multiple times.
9999999999a:2:{i:0;s:4:"path";i:1;s:2:"id";}
Logs
Environment
5.70.0
Installation
Fresh statamic/statamic site via CLI
Additional details
Also it seems parallel processing does not improve stache warm performance (I don't see any significant difference in all of my projects). Because most entries live in collections, and collections are warmed in a single process (one store per process), the parallelization provides little / no real concurrency. The smaller stores finish quickly, leaving most cores idle while the main collection store warms sequentially..
- Dominant language
- PHP
- Stars
- 4.9k
- Forks
- 647
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 100
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from statamic/cms
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
There's a default crop when cropping imagesPossibly taken A pull request linked to this issue is open or already merged. Openassets
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
accessibility
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
antlers
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
WordPress/hosting-handbook#506 ·
Maintainers usually reply within 2 days
-
Installing a plugin with composer_packages installs dev dependencies and breaks the autoloader (Error 500)Possibly taken @Boy132 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
nginx: static-file locations drop the security headers, and the dotfile deny is matched after themOpenbug Low Security
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
backdrop-contrib/commerce#60 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100