Я бы начал с понижения topology.max.spout.pending.Если у вас есть топология, которая бесполезно обрабатывает уже истекшие тайм-ауты, вам будет проще определить, где находится ваше узкое место.
Имейте в виду, что задержка емкости / выполнения учитывает только то, сколько временипотрачено в execute за каждый кортеж.
Насколько я помню, болт Кафки не проверяет кортежи до того, как он выйдет execute, но вместо этого доставляет кортеж производителю и фиксирует кортеж с помощью обратного вызова от производителя, что может произойти после executeвозвращается.В результате вы не увидите фактического времени, потраченного на обработку кортежей в болте Кафки, отраженного в задержке производительности / выполнения.Вы можете видеть фактическое время между достижением execute кортежа и задержкой кортежа в процессе, которое довольно велико.
Задержка вашего процесса count_bolt также высока, поэтому посмотрите,каждый также буферизует кортежи перед тем, как их взломать.