* cache: add sharded cache implementation
Add Cache impl and a few tests. This cache is 256-way sharded, mainly
so each shard has it's own lock. The main cache structure is a readonly
jump plane into the right shard.
This should remove the single lock contention on the main lock and
provide more concurrent throughput - Obviously this hasn't been tested
or measured.
The key into the cache was made a uint32 (hash.fnv) and the hashing op
is not using strings.ToLower anymore remove any GC in that code path.
* here too
* Minimum shard size
* typos
* blurp
* small cleanups no defer
* typo
* Add freq based on Johns idea
* cherry-pick conflict resolv
* typo
* update from early code review from john
* add prefetch to the cache
* mw/cache: add prefetch
* remove println
* remove comment
* Fix tests
* Test prefetch in setup
* Add start of cache
* try add diff cache options
* Add hacky testcase
* not needed
* allow the use of a percentage for prefetch
If the TTL falls below xx% do a prefetch, if the record was popular.
Some other fixes and correctly prefetch only popular records.
* middleware/cache: cache 0 will be capped at 5
cache 0 would return TTL=0 records, up that to the documented minimum of
5 seconds.
* middleware/cache: check for 0 TTL
Handle 0 TTL differently and return an error, we might need to
special case this in the future.
Rename: positive -> success
negative -> denial
There is a third (unused category) which is error. Start using these
new in the caching middleware and later in the logging middleware.
Make the cache memory bounded, by using a LRU cache. Also split the
cache in a positive and negative one - each with its own controls.
Extend the cache stanza to allow for this:
cache {
positive limit [ttl]
negative limit [ttl]
}
is now possible. This also add a cache_test.go in the toplevel test/
directory that exercises the caching path.
Fixes#260
