Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Cache] Prevent stampede at warmup using apcu_entry() for locking #27028

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

[Cache] Prevent stampede at warmup using apcu_entry() for locking #27028

wants to merge 1 commit into from
+57 −3

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Apr 24, 2018 •
edited
Loading

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -

When a cache is cold, all concurrent processes will end up recomputing the same value, which can be slow at best and can create a cascading failure at worst.

By leveraging apcu_entry(), we can ensure only one process per front is actually computing the value.

In theory, you might wonder if this could be implemented in a generic way using e.g. the Lock component. This would allow using distributed locking, thus allow locking the computation across a cluster of fronts.

But in practice, apcu_entry() is the only primitive that works, because it knows when to not compute the callback when it waited for a concurrent process, which is something really hard to achieve with other locking mechanisms (if possible at all without all sort of race conditions.) Also, computing only once per-front is already a significant improvement. People having more advanced needs could still create a proxy to handle the distributed lock.

For core, relying on apcu_entry() to provide this behavior is what I propose here.

@nicolas-grekas nicolas-grekas added this to the next milestone Apr 24, 2018
@nicolas-grekas nicolas-grekas force-pushed the cache-apcu-lock branch 4 times, most recently from 0225318 to ec2b4c0 Compare April 24, 2018 14:36
@nicolas-grekas nicolas-grekas mentioned this pull request Apr 24, 2018
Merged
@webnet-fr
Copy link
Contributor

apcu_entry seems a good choice. Anyway, what do you think about using Symfony's lock component? Something like:

$store = new \Symfony\Component\Lock\Store\FlockStore(sys_get_temp_dir());
$factory = new \Symfony\Component\Lock\Factory($store);

$lockId = 'cache';
$lock = $factory->createLock($lockId);
$needToGenerate = $lock->acquire(); // not blocking

if ($needToGenerate) {
    sleep(5); // heavy work. Calls passed generator function
    echo 'Heavy generator is launched. Result is cached.<br>';
} else {
    $lock->acquire(true); // blocking
    echo 'Did not launch heavy generator. Result is got from a cache.<br>';
}

$lock->release();

@nicolas-grekas
Copy link
Member Author

nicolas-grekas commented Apr 30, 2018 •
edited
Loading

@webnet-fr that'd be great if it could work, but I don't think that's possible: this code is full of race conditions, and the sleep(5) (or any other value) is a no-go also...

@nicolas-grekas nicolas-grekas mentioned this pull request May 18, 2018
Closed
@nicolas-grekas nicolas-grekas force-pushed the cache-apcu-lock branch 3 times, most recently from c60f631 to 1789e42 Compare June 11, 2018 13:11
fabpot added a commit that referenced this pull request Jun 11, 2018
@fabpot
feature #27031 [Cache] Use sub-second accuracy for internal expiry ca…
205d161 
…lculations (nicolas-grekas)

This PR was merged into the 4.2-dev branch.

Discussion
----------

[Cache] Use sub-second accuracy for internal expiry calculations

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | not really
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

Embeds #26929, #27009 and #27028, let's focus on the 4th commit for now.

This is my last significant PR in the Cache series :)

By using integer expiries internally, our current implementations are sensitive to abrupt transitions when time() goes to next second: `$s = time(); sleep(1); echo time() - $s;` *can* display 2 from time to time.
This means that we do expire items earlier than required by the expiration settings on items.
This also means that there is no way to have a sub-second expiry. For remote backends, that's fine, but for ArrayAdapter, that's a limitation we can remove.

This PR replaces calls to `time()` by `microtime(true)`, providing more accurate timing measurements internally.

Commits
-------

08554ea [Cache] Use sub-second accuracy for internal expiry calculations
@nicolas-grekas nicolas-grekas force-pushed the cache-apcu-lock branch 4 times, most recently from e31510c to 6ed5db7 Compare June 11, 2018 19:43
@nicolas-grekas
Copy link
Member Author

I'm closing because I'm not convinced we can plug APCu at this central place.

@nicolas-grekas nicolas-grekas deleted the cache-apcu-lock branch June 14, 2018 13:35
@nicolas-grekas nicolas-grekas mentioned this pull request Jun 14, 2018
Merged
fabpot added a commit that referenced this pull request Jun 18, 2018
@fabpot
feature #27604 [Cache] Prevent stampede at warmup using flock() (nico…
137dd76 
…las-grekas)

This PR was merged into the 4.2-dev branch.

Discussion
----------

[Cache] Prevent stampede at warmup using flock()

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

Replaces #27028

This PR protects against cache stampede by wrapping the computation of items in a pool of locks.

For each apps, there can be at most 20 concurrent processes that compute items at the same time and only one per cache-key.

Commits
-------

0ac2777 [Cache] Prevent stampede at warmup using flock()
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.2 Nov 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
Cache Feature Status: Needs Work
Projects
None yet
Milestone
4.2
Development

Successfully merging this pull request may close these issues.
3 participants
@nicolas-grekas @webnet-fr @carsonbot