[
https://issues.apache.org/jira/browse/SAMZA-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Riccomini updated SAMZA-548:
----------------------------------
Attachment: SAMZA-548-0.patch
Attaching patch. RB at:
https://reviews.apache.org/r/30781/
* Added stat-yarn-job.sh script to check the current status of a Samza job.
* Cleaned up negate-numbers.properties to eliminate useless config.
* Added a kafka-read-write-performance job config that uses TestPerformanceTask
to test read/write performance.
* Updated NegateNumbers to be more configurable (custom output path, and
maxMessages)
* Updated deployment.py to move job start/stop from deployment into individual
tests.
* Added an await() method to the Samza job deployer, which waits for a job to
finish.
* Added a performance_tests test suite.
* Moved Kafka helper methods into a util.py file that both perf and smoke tests
can share.
The new read/write test loads 1 million 200 byte messages into Kafka. The job
then starts, reads all 1 million, and writes them out to a new topic. No
serialization is handled in this test. The topics are both one partition, and
the job is a single container with one StreamTask in it. I ran some cursory
tests, and found:
* compression=none, linger.ms=0, acks=1, 166k msgs/sec, 33 MB/sec
* compression=none, linger.ms=0, acks=0, 200k msgs/sec, 40 MB/sec
I also observed that we go much faster than this (50-60 MB/sec) at peak, but
for first few seconds, the container is warming up (and \-server is kicking
in). There are a lot of deficiencies in this test:
# The test runs on just one machine (broker and job are all on one machine).
# The input and output topics are just one partition, with a replication factor
of 1.
# I didn't mess with linger.ms at all to see if it would go faster.
# Turning on GZip compression slowed things down dramatically.
# No tests were done to see how scaling up the container count would impact
performance.
# The messages/sec are logged to a file, but the test doesn't check it.
# The test only runs with 1 million messages.
Still, the numbers look tolerable. (1) can be remedied by addressing SAMZA-509.
With (5), it would be interesting to see if one container for every core would
result in saturating the NIC. I suspect it would. (6) would be nice, so we
could impose some minimum speed, and make sure that we don't regress on
performance when we apply patches. I didn't run with more than 1 million
messages (7) because the python producer was already pretty slow in loading 1
million messages into Kafka.
Anyway, I think this is a good starting point.
> Add performance test for container Kafka performance
> ----------------------------------------------------
>
> Key: SAMZA-548
> URL: https://issues.apache.org/jira/browse/SAMZA-548
> Project: Samza
> Issue Type: Bug
> Components: kafka, test
> Affects Versions: 0.9.0
> Reporter: Chris Riccomini
> Assignee: Chris Riccomini
> Fix For: 0.9.0
>
> Attachments: SAMZA-548-0.patch
>
>
> There was [some
> discussion|http://mail-archives.apache.org/mod_mbox/samza-dev/201502.mbox/%3CCANFmfeNfdGCRsj66-76prLy%3DreK7_q3bfKLNP5iKfX7G1X2sNg%40mail.gmail.com%3E]
> on the mailing list about Samza's read/write performance with Kafka. We
> don't currently have a performance test that measures a Samza container's
> read/write performance when using Kafka. We should write one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
