No, and no. I’m sorry but you are completely ignoring constant factor overhead of just having a request, on the client side and on the server side but in this case especially on the client. Once the per-request overhead is paid, the more work that request produces the faster your throughput will be. One million small requests per second is not at all the same as 1000 request per second where each request produces 1000x the amount of output as each of the million small ones.
I’m going to try explaining this with a non-FDB example in hopes it will help. The concept of per-request overhead and the idea of maximizing per-request output to reduce overhead and maximize throughput is not unique to FDB.
Imagine you have a file sitting in Amazon S3. That file is 500 Mbytes in size. You have a client running in AWS, very close to S3 in terms of network latency and throughput, and you want to use that client to read that file. You open an HTTP connection to the S3 service and then do one of these two things:
- A) Issue a single Read request to the file data with (offset 0, length 500 million)
- B) Issue 1 million Read requests in a row, on that same HTTP connection, each requesting the next consecutive 500 bytes of the file. In other words, (offset 0, length 500) then (offset 500, length 500), then (offset 1000, length 500) and so on.
Does it make sense to you that these will not run at the same speed? B will be far, far slower than A. The B approach is incurring per-request overhead a million times. This overhead is significant compared to the work of returning 500 sequential bytes from the file once the request is parsed and the location in the file is reached.