hgzimmerman / rocket-file-cache Goto Github PK

Currently, Cache::new() makes some opinionated choices for the user, which should be covered by a Default impl instead.

By default:

• The size should be unbounded.
• No Min size
• No Max size
• Default priority function
• Accesses per refresh should not be provided (never refresh).

Possibly a warning should be logged indicating that users of the method should use the builder instead.

Alternatively:

Don't replace it at all.
Force users to use the builder, which would have the same outcome as the Default impl anyways.

Expose a parameter in the cachebuilder that will allow consumers of the crate to specify that the cache should refresh a file every n accesses.

This should be useful in mitigating bit flips that will eventually accumulate in non ECC ram.

By default, this should not be active.

Some users of the cache may want to have some files that cannot be removed from the cache.
These files could be added to the cache manually and marked to prevent invalidation.

Would you mind to add a CHANGELOG.md to the repo?

Consider implementing a custom Result that contains 3 variants:

• CacheHit - file was found in the cache.
• CacheMiss - File was not found in cache, but was found in the filesystem.
• Err - File was not found in either the cache or the fs.

An ok() method could resolve this back to the existing Option, or this Err case could be rolled into the existing CachedFile implementation and would redirect to the 404 handler when responding, meaning that get() would return just a plain CachedFile.

Remove symbols around Intel processor specs.
Remove unneeded clone in the cache example block for the file path.

I was just looking into caching with Ngnix and Rocket when I found this instead. I’m new to Rust and Rocket itself. I have a working app serving static files that I implemented following the static_files example on Rocket’s github. Can you duplicate the same example using your crate?

https://github.com/SergioBenitez/Rocket/blob/master/examples/static_files/src/main.rs

Thanks.

Mitigate Mutex lock contention by creating multiple caches that are pooled together.
If the number of threads is equal to the number of caches in the pool, then there should not be any latency waiting for locks.

That said, there would be an increase in memory consumption equal to the size of one cache times the number of caches in the pool.

This is a problem with the implementation of the tests, the disk read should always be a little faster.

The stats for priority, access times, and size can be stored in the file_map alongside the files themselves.

This will simplify the implementation, while probably not having a significant impact on performance.

Use this as reference https://github.com/SergioBenitez/Rocket/pull/485/files#diff-6b4eceaf6fbfc4c538cc51311c5b4d11R91

Currently, the access counts are stored in a concurrent hashmap and are represented as AtomicUsizes.

They should use one or the other, but not both.

Currently the cache is limited by the number of files it can hold.
This should be changed to be limited by the total number of bytes the cache can hold.

This is an API breaking change, and should have high priority.

Allow consumers of the crate to specify in the CacheBuilder a function that will execute every n accesses for the whole cache that will alter every file's access count and therefore priority.

Make the n an AtomicUsize. Given the ConcurrentHashmap implementation, it should be possible to iterate through all entries without depriving

This should work, as the the Cache already uses AtomicUsize for holding the counters.
Because there isn't a need for the locks in the ConcurrentHashMap, transitioning back to a HashMap should make sense.

Because performance degrades as files get bigger, it may make sense to prevent large files from being cached.

Actually creating the in-memory file requires a copy.
Serializing the file to a request requires another copy.
That first copy should be avoided if possible.

So to bring cache misses more or less in parity with normal file reads do the following.

• Get the size using https://doc.rust-lang.org/std/fs/struct.Metadata.html
• Determine if an insertion is required using just the size and the path.
  • This will remove the required space.
• If an insertion is required, then insert and return the sized file.
• If not, get a file handle, similar to the NamedFile in Rocket and return that instead.
• Return an Either<SizedFile,NamedFile> to be used in the CachedFile.

Also rename everything.