Partitioned memory pools

[benaadams]

The increase in use of memory pools is leading to and will inevitably lead to greater and greater contention.

This loosens the contention on the memorypool by partitioning ProcessorCount times and choosing the first pool to try as ManagedThreadId % ProcessorCount.

Also steals from other pools when preferred pool is empty.

[davidfowl]

Not a fan of this being in the ctor. It could be in a factory method though

[benaadams]

Going to change it up then...

[benaadams]

@halter73 give this a go?

Taken @rynowak's round robining idea from #390 (comment); but using ManagedThreadId % ProcessorCount rather than Interlocked.Increment which would be an obvious choice; however would put contention on a single numeric; though lighter than CAS.

Hopefully it will still provide enough distribution.

[DamianEdwards]

Rebased on 7e8a405 and measured. This one seems totally broken. It gets slower with each run and leaves the dnx process eating CPU even when not serving requests.

[benaadams]

Yeah found it to be broken last night ;-(

[benaadams]

@DamianEdwards is fixed

[AspNetSmurfLab]

Measured again. It's very slightly up from the dev branch baseline (~499k):

Running 10s test @ http://10.0.0.100:5001/plaintext
  32 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     6.30ms    7.52ms 100.86ms   92.93%
    Req/Sec    15.84k     1.39k   32.81k    88.84%
  5071775 requests in 10.10s, 638.46MB read
Requests/sec: 502177.87
Transfer/sec:     63.22MB

[benaadams]

This is more a pre-solution for the contention that will happen with more memory pool use with SocketOutput and the pre-computed Headers change

[benaadams]

See @halter73 is working on something far better; closing this...