Storm in a Clustered Mode - Real-time Analytics with Storm and Cassandra - page 75

• topology.message.timeout.secs : This value specifies the duration in
seconds after which a tuple being processed by the topology is declared as timed
out and discarded. Thereafter, depending upon whether it's a reliable or unreliable
topology, it's replayed or not. This value should be set cautiously; if set too low,
all messages will end up being timed out. If it is set too high, one may never get
to know the performance bottlenecks in the topology.
• topology.debug : This parameter denotes whether you want to run the topo-
logy in the debug mode or node. The debug mode is when all the debug logs are
printed, and it is recommended in the development and staging mode, but not in
the production mode because I/O is very high in this mode and thus hits the over-
all performance.
• supervisor.slots.ports : This parameter specifies the ports for the super-
visor workers. This number directly ties to the number of workers that can be
spawned on the supervisor. When topologies are spawned, one has to specify the
number of workers that are to be allocated, which in turn ties to actual resources
allocated to the topology. The number of workers is really important because they
actually identify how many topologies can run on the cluster and in turn how
much parallelism can be achieved. For example, by default, we have four slots
per supervisor, so in our cluster, we will have Total number of slots/workers =
4*2 = 8 . Each worker takes a certain number of resources from the system in
terms of CPU and RAM, so how many workers are spawned on the supervisor de-
pends on the system configuration.