Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r130701047
--- Diff: conf/defaults.yaml ---
@@ -253,11 +244,15 @@ topology.trident.batch.emit.interval.millis: 500
topology.testing.always.try.serialize: false
topology.classpath: null
topology.environment: null
-topology.bolts.outgoing.overflow.buffer.enable: false
-topology.disruptor.wait.timeout.millis: 1000
-topology.disruptor.batch.size: 100
-topology.disruptor.batch.timeout.millis: 1
-topology.disable.loadaware.messaging: false
+topology.disruptor.wait.timeout.millis: 1000 # TODO: Roshan: not used,
but we may/not want this behavior
+topology.transfer.buffer.size: 50000
+topology.transfer.batch.size: 10
+topology.executor.receive.buffer.size: 50000
+topology.producer.batch.size: 1000
+topology.flush.tuple.freq.millis: 100
--- End diff --
Actually for now it should be set to 1ms, to be inline with the existing
setting for flusher. Not yet determined what is a reasonable default for the
new system.
**Batching:** I decided to provide the batching ability as option, just
like we have had it previously... although the code would be much simpler
without it. With batching disabled(batchSz=1), the degradation in throughput
that I have seen is relatively smaller for JCQueue...but nevertheless some
degradation exists.
When you disable batching, JCQueue updates internal metrics more
frequently which partly impacts throughput. Flush tuple Timer will not be
started if batchSz=1.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
