IMO one second of interval is not small enough for context switching to be a problem. You can try increasing the heartbeat interval and see if it affects the throughput. Though for it to be possible, the topology has to have a high load for sure.
On Sat, Jan 9, 2016 at 8:59 PM, John Yost <[email protected]> wrote: > HI Abhishek, > > Good points, thanks! I guess to phrase my question more precisely, if > there are Java threads dedicated to sending messages to zookeeper that are > constantly in a running mode, I am thinking that would lead to more context > switching for the Bolt and Spout threads actually doing work, which I am > thinking would decrease throughput. Do you think this a valid concern, or > am I worrying about something that's really not a big deal? :) > > Please confirm--thanks again for your thoughts! > > --John > > On Sat, Jan 9, 2016 at 9:59 AM, Abhishek Agarwal <[email protected]> > wrote: > >> Heartbeats are lightweight operations on zookeeper. In the topology, so >> long heartbeats are happening in a different thread, 1 second interval >> isn't much of a performance bottleneck. >> >> A contrasting example is zookeeper state update in kafka spout. Now there >> the interval is directly related to performance because it is a write >> operation (costly in zookeeper) and it happens in the same thread which >> generates the tuples. >> >> >> >> On Sat, Jan 9, 2016 at 6:11 PM, John Yost <[email protected]> wrote: >> >>> Hi Everyone, >>> >>> During the course of profiling (actually sampling) a worker process with >>> jvisualvm I noticed the executor and worker zk send threads are always >>> active. I then checked the heartbeat settings on my topology and noted that >>> the default executor heartbeat is 1 second. >>> >>> Question: is this a potential performance bottleneck? Would it make >>> sense to bump this up to 5 or 10 seconds? Would like to see what y'all >>> think. >>> >>> Thanks >>> >>> --John >>> >> >> >> >> -- >> Regards, >> Abhishek Agarwal >> >> > -- Regards, Abhishek Agarwal
