sodonnel commented on PR #5331:
URL: https://github.com/apache/ozone/pull/5331#issuecomment-1727981617
Thanks for adding some benchmark code.
Testing very small writes of 512 bytes will obviously show the buffered
reader as better. However varying the buffer sizes:
```
file output cost: 6009677083ns 512b writes
buffered output cost: 275302167ns 8MB buffer
file output cost: 1365136125ns 4kb writes
buffered output cost: 286801417ns 8MB buffer
file output cost: 564035208ns 16kb writes
buffered output cost: 336380791ns 8MB buffer
file output cost: 368352375ns 32kb writes
buffered output cost: 290840542ns 8MB buffer
file output cost: 352088292ns 32kb writes
buffered output cost: 209192667ns 1MB buffer
file output cost: 370499875ns 3kb writes
buffered output cost: 219296750ns 0.5MB buffer
file output cost: 253621584ns 32kb writes
buffered output cost: 264730833ns 64kb buffer
file output cost: 266869708ns 64kb writes
buffered output cost: 278883500ns 64kb buffer
```
From this it is clear that a 8MB buffer is much too large. The writes were
faster with a 0.5MB buffer and in the same area for even a 64KB buffer.
So the next question is - what are the size of the writes in the real
download, as they are coming over the network in chunks?
This change has modified GrpcReplicationClient which receives chunks of
CopyContainerResponseProto. This seems to come from
CopyContainerResponseStream, where we can see the constructor is passed a
BUFFER_SIZE:
```
CopyContainerResponseStream(
CallStreamObserver<CopyContainerResponseProto> streamObserver,
long containerId, int bufferSize) {
super(streamObserver, containerId, bufferSize);
}
```
If you look inside GrpcOutputStream, you can see it fills the buffer before
sending anything over the network, so that buffer size will determine the size
of the chunks at the receiver. In GrpcReplicationService it defines the buffer
size:
```
static final int BUFFER_SIZE = 1024 * 1024;
```
So its 1MB. Re-running the test before with 8MB buffer and 1MB writes:
```
file output cost: 293118958ns
buffered output cost: 330165959ns
file output cost: 201044125ns
buffered output cost: 360208875ns
file output cost: 242833833ns
buffered output cost: 363730708ns
```
I ran it 3 times, and each time the change here made it slower, as well as
requiring a new 8MB buffer for each stream, along with the 1MB buffer already
in use, making it 9MB of overhead per concurrent download stream.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
