Use fnv64a instead of sha256 for cache keys

[hectorj]

I've done some benchmarks, and FNV is ~3 times faster than SHA256

https://gist.github.com/hectorj/8ac959c071d44ec4d718

I know it's only ~1 micro second by hashing, but it's also only a 3 lines change.

[lox]

Any idea what the impact would be in terms of cryptographic properties? Further down the track I'd like to implement cache peering, which would expose the cache keys to peers that requested them.

[lox]

Also, mind rebasing master for the test fixes?

[lox]

I'd be interested to see how MD5 compares, it's what Squid uses for cache peering: http://wiki.squid-cache.org/SquidFaq/CacheDigests

[hectorj]

I updated https://gist.github.com/hectorj/8ac959c071d44ec4d718 with MD5 & SHA1, and also added memory information to the results.

MD5 performs better than the SHA family, but is also known as being cryptographically insecure : https://en.wikipedia.org/wiki/MD5#Security

So if we need security I'd go with one of the SHA, and if we don't (and I don't think we do), FNV hands down

cache peering, which would expose the cache keys to peers that requested them

First time I hear about cache peering so I'm not sure, but peers are supposed to be trusted, no ?

[hectorj]

Rebased

[PSUdaemon]

What about SipHash?

https://en.wikipedia.org/wiki/SipHash

[lox]

I'm fine to merge this, any objections anyone?

[lox]

I'm doing some planning on a v2.0.0, I think this would be a good point to change the hashing algorithm on keys, as I plan to change the architecture of the backends.