You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Jay Kreps (Commented) (JIRA)" <ji...@apache.org> on 2011/10/26 20:25:32 UTC
[jira] [Commented] (KAFKA-171) Kafka producer should do a single
write to send message sets
[ https://issues.apache.org/jira/browse/KAFKA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13136193#comment-13136193 ]
Jay Kreps commented on KAFKA-171:
---------------------------------
Attached is a draft patch which turns the request into a single write. This is just a draft if this actually improves performance we should change Receive to use ScatteringByteChannel for consistency and also clean up a few more files with the same trick.
On my mac laptop I do see a change in tcpdump which seems to eliminate the 4 byte send. However I don't see any positive result in performance for synchronous single-threaded sends of 10 byte messages (which should be the worst case for this). I think this may just be because I am testing over localhost.
Here are the details on the results I have:
TRUNK:
jkreps-mn:kafka-git jkreps$ sudo tcpdump -i lo0 port 9093
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes
10:32:30.128938 IP jkreps-mn.linkedin.biz.56953 > jkreps-mn.linkedin.biz.9093: S 323648854:323648854(0) win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 377871870 0,sackOK,eol>
10:32:30.129004 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56953: S 526915069:526915069(0) ack 323648855 win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 377871870 377871870,sackOK,eol>
10:32:30.129013 IP jkreps-mn.linkedin.biz.56953 > jkreps-mn.linkedin.biz.9093: . ack 1 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.129022 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56953: . ack 1 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.129306 IP jkreps-mn.linkedin.biz.56953 > jkreps-mn.linkedin.biz.9093: P 1:5(4) ack 1 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.129319 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56953: . ack 5 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.129339 IP jkreps-mn.linkedin.biz.56953 > jkreps-mn.linkedin.biz.9093: P 5:41(36) ack 1 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.129350 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56953: . ack 41 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.151892 IP jkreps-mn.linkedin.biz.56953 > jkreps-mn.linkedin.biz.9093: F 41:41(0) ack 1 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.151938 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56953: . ack 42 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.151946 IP jkreps-mn.linkedin.biz.56953 > jkreps-mn.linkedin.biz.9093: . ack 1 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.152554 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56953: F 1:1(0) ack 42 win 65535 <nop,nop,timestamp 377871870 377871870>
10:32:30.152571 IP jkreps-mn.linkedin.biz.56953 > jkreps-mn.linkedin.biz.9093: . ack 2 win 65535 <nop,nop,timestamp 377871870 377871870>
PATCHED:
jkreps-mn:kafka-git jkreps$ sudo tcpdump -i lo0 port 9093
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes
10:35:40.637220 IP jkreps-mn.linkedin.biz.56993 > jkreps-mn.linkedin.biz.9093: S 1456363353:1456363353(0) win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 377873772 0,sackOK,eol>
10:35:40.637287 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56993: S 1260172914:1260172914(0) ack 1456363354 win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 377873772 377873772,sackOK,eol>
10:35:40.637296 IP jkreps-mn.linkedin.biz.56993 > jkreps-mn.linkedin.biz.9093: . ack 1 win 65535 <nop,nop,timestamp 377873772 377873772>
10:35:40.637306 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56993: . ack 1 win 65535 <nop,nop,timestamp 377873772 377873772>
10:35:40.657848 IP jkreps-mn.linkedin.biz.56993 > jkreps-mn.linkedin.biz.9093: P 1:41(40) ack 1 win 65535 <nop,nop,timestamp 377873773 377873772>
10:35:40.657886 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56993: . ack 41 win 65535 <nop,nop,timestamp 377873773 377873773>
10:35:40.711399 IP jkreps-mn.linkedin.biz.56993 > jkreps-mn.linkedin.biz.9093: F 41:41(0) ack 1 win 65535 <nop,nop,timestamp 377873773 377873773>
10:35:40.711430 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56993: . ack 42 win 65535 <nop,nop,timestamp 377873773 377873773>
10:35:40.711437 IP jkreps-mn.linkedin.biz.56993 > jkreps-mn.linkedin.biz.9093: . ack 1 win 65535 <nop,nop,timestamp 377873773 377873773>
10:35:40.762640 IP jkreps-mn.linkedin.biz.9093 > jkreps-mn.linkedin.biz.56993: F 1:1(0) ack 42 win 65535 <nop,nop,timestamp 377873774 377873773>
10:35:40.762678 IP jkreps-mn.linkedin.biz.56993 > jkreps-mn.linkedin.biz.9093: . ack 2 win 65535 <nop,nop,timestamp 377873774 377873774>
TRUNK:
bin/kafka-producer-perf-test.sh --topic test --brokerinfo zk.connect=localhost:2181 --messages 300000 --message-size 10 --batch-size 1 --threads 1
...
[2011-10-26 10:33:58,458] INFO Total Num Messages: 300000 bytes: 3000000 in 13.636 secs (kafka.tools.ProducerPerformance$)
[2011-10-26 10:33:58,459] INFO Messages/sec: 22000.5867 (kafka.tools.ProducerPerformance$)
[2011-10-26 10:33:58,459] INFO MB/sec: 0.2098 (kafka.tools.ProducerPerformance$)
PATCHED:
jkreps-mn:kafka-git jkreps$ bin/kafka-producer-perf-test.sh --topic test --brokerinfo zk.connect=localhost:2181 --messages 300000 --message-size 10 --batch-size 1 --threads 1
...
[2011-10-26 10:38:03,965] INFO Total Num Messages: 300000 bytes: 3000000 in 13.254 secs (kafka.tools.ProducerPerformance$)
[2011-10-26 10:38:03,965] INFO Messages/sec: 22634.6763 (kafka.tools.ProducerPerformance$)
[2011-10-26 10:38:03,966] INFO MB/sec: 0.2159 (kafka.tools.ProducerPerformance$)
> Kafka producer should do a single write to send message sets
> ------------------------------------------------------------
>
> Key: KAFKA-171
> URL: https://issues.apache.org/jira/browse/KAFKA-171
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.7, 0.8
> Reporter: Jay Kreps
> Assignee: Jay Kreps
> Fix For: 0.8
>
> Attachments: KAFKA-171-draft.patch
>
>
> From email thread:
> http://mail-archives.apache.org/mod_mbox/incubator-kafka-dev/201110.mbox/%3cCAFbh0Q1PYUj32thBaYQ29E6J4wT_mrG5SuUsfdeGWj6rmEx9Gw@mail.gmail.com%3e
> > Before sending an actual message, kafka producer do send a (control) message of 4 bytes to the server. Kafka producer always does this action before send some message to the server.
> I think this is because in BoundedByteBufferSend.scala we do essentially
> channel.write(sizeBuffer)
> channel.write(dataBuffer)
> The correct solution is to use vector I/O and instead do
> channel.write(Array(sizeBuffer, dataBuffer))
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira