You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 16, 2024. It is now read-only.
I have tested two different bookkeeper, which is distributedlog-0.3.51-RC1 + bookkeeper 4.3.4-TWTTR and distributedlog-0.3.50 + bookkeeper 4.5.0. what confused me is that bookkeeper 4.5.0 has a worse performance compared with bookkeeper 4.3.4-TWTTR, and here is my test report:
Addition:
I changed bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/Journal.java line 548 to get less group time: //this.maxGroupWaitInNanos = TimeUnit.MILLISECONDS.toNanos(conf.getJournalMaxGroupWaitMSec()); this.maxGroupWaitInNanos = 100;
The above results are tested from same computer with the same config(MSG_SIZE=256, MAX_RATE=40000, output-buffer-size=16384). My confusion is below:
Different bookkeeper shows different mean_rate under a same config. Maybe the new distributedlog 0.3.50 changes the rate of transmit package to achieve higher performance? Or bookkeeper 4.5.0 has new mechanism to deal with the package?
Compared with bookkeeper 4.3.4, bookkeeper 4.5.0 costs more 20us to deal with the request. Is this caused by different rate? Or what cause a worse performance?
Is there anyone meet this question? Can anyone explain that? It is troubled me for a long time.
Thank you very much for your time and patience !!! And forgive my pool English ^_^
The text was updated successfully, but these errors were encountered:
I think the bk 4.5.0 (using v3 protocol) has slightly increased gc due to bytestring needs to copy memory. there is a change recently bumping the protobuf to 3.x, which will help the situation.
You might consider using latest DL master with 4.5.0, which it leverages the netty 4.x ByteBuf for managing the memory for output buffer. It would have better latency and throughput.
I will have a performance comparison report soon for describe the differences between versions.
Firstly, thank you very much for your answer!!!
I am sorry that I made a mistake in my "QUESTION": Actually I used latest DL master with BK 4.5.0, and DL-0.3.51-RC1 with BK 4.3.4-TWTTR, and the results are above, shows that 4.5.0 costs more 20us to deal with the request. I don't know what cause this strange result, config ? Or something else...
@zjflike - I think the slight increased 20us is coming from the v3 (protobuf) protocol. using 2.x protobuf, there is no memory-copy-free method to serialize the bytestring into protobuf structure. I need to check more to confirm.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
QUESTION
I have tested two different bookkeeper, which is distributedlog-0.3.51-RC1 + bookkeeper 4.3.4-TWTTR and distributedlog-0.3.50 + bookkeeper 4.5.0. what confused me is that bookkeeper 4.5.0 has a worse performance compared with bookkeeper 4.3.4-TWTTR, and here is my test report:
in bookkeeper 4.3.4-TWTTR:
in bookkeeper 4.5.0:
Addition:
I changed bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/Journal.java line 548 to get less group time:
//this.maxGroupWaitInNanos = TimeUnit.MILLISECONDS.toNanos(conf.getJournalMaxGroupWaitMSec()); this.maxGroupWaitInNanos = 100;
The above results are tested from same computer with the same config(MSG_SIZE=256, MAX_RATE=40000, output-buffer-size=16384). My confusion is below:
Different bookkeeper shows different mean_rate under a same config. Maybe the new distributedlog 0.3.50 changes the rate of transmit package to achieve higher performance? Or bookkeeper 4.5.0 has new mechanism to deal with the package?
Compared with bookkeeper 4.3.4, bookkeeper 4.5.0 costs more 20us to deal with the request. Is this caused by different rate? Or what cause a worse performance?
Is there anyone meet this question? Can anyone explain that? It is troubled me for a long time.
Thank you very much for your time and patience !!! And forgive my pool English ^_^
The text was updated successfully, but these errors were encountered: