Choosing a non-cryptographic hashing algorithm?

Question

Algorithms

For one self-written load balancer, you must select an algorithm (not cryptographic) for calculating checksums. The input data (string keys) is always exactly larger than 32 bytes.
I would love to hear the opinion of developers with a deep understanding of the topic. Which of the following algorithms would you recommend or caution against using?
What I managed to find myself:

• - fnv-1a - the most common description on the network;
  
• - lookup3 - what I tend to myself; in my opinion - the most optimal, but the lack of references to successful application in projects, like fnv, confuses;
  
• - MurmurHash2 - judging by the available tests - the fastest, there are application stories (libmemcached, Hadoop); but some inadequate situation with collisions on certain test sets - simon-says.vox.com/library/post/murmur-hash-very-f... - "...one pathological input sequence of 2^32 values ​​causes the algorithm to suffer from a rate of hash collision as high as 97.6%"
  

Answer 1

If you do not bother too much, then in the book "Programming Practice" by Kernighan and Pike there is a fairly simple algorithm:
enum { MULTIPLIER = 31 };
/* hash: calculate
the hash function of the string */
unsigned int hash(char *str)
{
unsigned int h;
unsigned char *p;
h = 0;
for (p = (unsigned char *)
str; *p != '\0'; p++)
h = MULTIPLIER * h +
*p; return h % NHASH; }

Answer 2

And why are numerous variations of CRC not suitable?