Github user arunmahadevan commented on the pull request:
https://github.com/apache/storm/pull/1217#issuecomment-200233334
Re-ran the exclamation topology with,
- no anchoring/acking
- TestWordSpout emitting a fixed word without any sleep
- spout, bolt parallelism = 1
- worker = 1
- Loglevel = error, conf.setDebug(false)
Throughput I observed :-
566 K tuples/sec (with eventlogger: nil)
569 K tuples/sec (with eventlogger: 0) roughly 0.5% improvement.
I then ran Jprofiler and saw **1.3%** time being spent in
send_to_eventlogger.
The profiler output itself might be offset due to the instrumentation
overhead. Jprofiler detects the following with send_to_eventlogger
`some methods with excessive instrumentation overhead has been detected.
They are called very frequently, their execution times are very short and the
time required for measuring those calls are dispropotional`
>I retired the throughput measurements with ackers=0 .. impact is even
greater ... its 25% faster when event.logger=0
Are you taking the measurements while the profiler is running or with the
debug flag turned on? I don't see this happening otherwise. Are you using the
latest Jprofiler (9.1.1) ? Are you using any extra plugins to instrument the
hashmap lookups (since I see the hashmap keys in your screenshot) ? If so that
itself might be skewing your results.
To avoid the persistentMap lookups, I also tried passing the **storm-id**
and **debug-atom** values as args to send_to_eventlogger and the percentage
reduced from 1.3 % to 1 % . You could try this change and see how it impacts
your topology.
I agree with @HeartSaVioR and don't think we need to set eventlogger to 0.
---
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.
---
