1) I didn't include it in the plot since I found it to remain constant, at ~300 requests/second. But yes, perhaps it would show a nice contrast to batching if graphed along with it.
2) This is an interesting question. I think it depends on how a non-batching solution is implemented: A) if each client obtains its own file handle, fsync()s can theoretically be issued 'slightly more concurrently'; B) if a unique file handle is the only one upon which fsync()s are called, this is essentially my solution with a dedicated thread, but which only writes one update at a time.
For A I'd guess a client would have to wait less for not-very concurrent environments, while in B wait time grows longer for "unlucky" concurrent threads. But I think a batching solution would overtake A for even moderately concurrent environment, since -- as you say -- it reduces the burden of serialisation.
Given time I'll try to revisit the code and try out different kinds of tests!
Comments
Thank you!
1) I didn't include it in the plot since I found it to remain constant, at ~300 requests/second. But yes, perhaps it would show a nice contrast to batching if graphed along with it.
2) This is an interesting question. I think it depends on how a non-batching solution is implemented: A) if each client obtains its own file handle, fsync()s can theoretically be issued 'slightly more concurrently'; B) if a unique file handle is the only one upon which fsync()s are called, this is essentially my solution with a dedicated thread, but which only writes one update at a time.
For A I'd guess a client would have to wait less for not-very concurrent environments, while in B wait time grows longer for "unlucky" concurrent threads. But I think a batching solution would overtake A for even moderately concurrent environment, since -- as you say -- it reduces the burden of serialisation.
Given time I'll try to revisit the code and try out different kinds of tests!