Skip to content
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.

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

Idea: Increase granularity of expiry timestamps from 1 second to milliseconds/nanoseconds? #417

Open
TysonAndre opened this issue Mar 4, 2021 · 0 comments

Comments

@TysonAndre
Copy link
Contributor

TysonAndre commented Mar 4, 2021

And separately from that, potentially allow floats for ttls in addition to integers.

Internally, APCu currently uses time_t. I believe this means that a key will expire at X seconds and .000000000 nanoseconds.

  • i.e. currently, if I set a key with a TTL of 100 seconds at time X.123, then APCu stores it with an expiry of (X+100).000 with no fractional seconds, but I'd want it to expire closer to (X+100).123 instead

This would mean that for an application with a lot of frequently accessed, short lived keys backed by some (potentially slow) external service or db, there'd be a lot more requests to the external service at X.0 seconds than at X.5 seconds than at X.9 seconds , and if there's a bottleneck in the external service, requests at X.0 seconds would take longer to complete than requests at X.9 seconds.

  • There's potentially workarounds such as storing the pair [$value, float $ttl] in apcu_store instead of just $value (or raising ttls) but that would not be as efficient as a native solution

Compared to when APCu was initially published in 2013, or APC in 2003

  • PHP 7/8 is much faster than PHP 5 and has much lower memory usage per process
  • Server CPUs can have many more cores
  • CPUs have higher clock speeds and more ram

This can be done with gettimeofday and by changing times to be int64 and tp.tv_sec * 1000000 + tp.tv_usec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant