Better model of request rates?

[brianfrankcooper]

Rusty pointed out that if we have a fixed number of client threads (say, 100), and the database is slow or down for a short period, then those 100 threads will wait and we'll see high latencies for 100 requests. But in reality, a real application would have a larger number of users with waits or timeouts, because they'll be waiting on the app server for a thread or a process but can't get one because all the threads/processes are busy. So we could enhance the request rate model to track requests that would have executed in a given time tick, but cannot because all the YCSB threads are busy. Possibly, this is equivalent to counting the number of requests that would have been executed by a given thread in a given 1 second period, but could not because the thread was waiting for the database.

[busbey]

I think #214 fixes this.