Reevaluating the log output generated from this instrumentation,
we've found that it wasn't all that useful in practice.
```
Caches multi read:
- views/david/2/4184ab71db6849621a4d8820fcd2c0ad
- views/david/2/4184ab71db6849621a4d8820fcd2c0ad
- views/david/3/4184ab71db6849621a4d8820fcd2c0ad
- views/david/3/4184ab71db6849621a4d8820fcd2c0ad
```
If rendering many templates the output is inscrutable, and it's impossible
to see how many cache misses there were.
Revert ca6aba7f30 and implement a better way later.
Fixes https://github.com/rails/rails/issues/22477.
When I improved the caching instrumentation in
edd33c08d98723ae9bb89cf7f019277117ed6414, I inadvertently changed the
order of AS notifications when there is a cache miss.
Currently `Rails.cache.clear` raises Errno::ENOENT if it's run just
after cloning a new Rails project. It should succeed without removing
files or directories.
This code was there just to convert entries generated in Rails
4.0.0.beta1 applications to a supported format.
It is almost unlikely that any existent application have this cache
entry format in their caches at the point that Rails 5 will be released
so we don't need this code anymore.
The current implementation of `fetch_multi` returns an array and has no
means to easily backtrack which names yielded which results. By changing
the return value to a Hash we retain the name information. Hash#values
can be used on the response if only the values are needed.
fixes#13547
The body may use the local cache during rendering. `call`ing the app
doesn't mean that rendering is finished, so we need to wait until
`close` is called on the body.
:mem_cache_store require dalli, rescue Dalli exceptions, and follow Dalli API.
Memcached gem, for instance, doesnt work anymore, as the API are different.
As we already require one client, we should make sure that client works, and not accept others, and if someone wants to use another memcache client they can write their own store adapter.
Previously, the cache size of `ActiveSupport::Cache::MemoryStore` was calculated
as the sum of the size of its entries, ignoring the size of keys and any data
structure overhead. This could lead to the calculated cache size sometimes being
10-100x smaller than the memory used, e.g., in the case of small values.
The size of a key/entry pair is now calculated via `#cached_size`:
def cached_size(key, entry)
key.to_s.bytesize + entry.size + PER_ENTRY_OVERHEAD
end
The value of `PER_ENTRY_OVERHEAD` is 240 bytes based on an [empirical
estimation](https://gist.github.com/ssimeonov/6047200) for 64-bit MRI on
1.9.3 and 2.0.
Fixes GH#11512 https://github.com/rails/rails/issues/11512
1. When comparing the directory to delete against the top level
cache_path, use File.realpath to make sure we aren't comparing two
unequal strings that point to the same path. This occurs, for
example, when cache_path has a trailing slash, which it does in the
default Rails configuration. Since the input to
delete_empty_directories never has a trailing slash, the comparison
will never be true and the top level cache directory (and above) may
be deleted. However…
2. File.delete raises EPERM when trying to delete a directory, so no
directories have ever been deleted. Changing the code to Dir.delete
fixes that.
