Это не совсем конкретный инструмент, но может быть полезным.
Потребители:
Не уверен, какова ваша внутренняя архитектура, но давайте предположим, что это чтение MDB в сообщениях. Я утверждаю, что ваше единственное требование здесь для точного определения количества нитей - это выбрать максимальный предел. Если ваш MDB использует ресурсы от конечного поставщика, такого как пул соединений JDBC, рассмотрите максимальный предел как наибольшее количество одновременных экземпляров из этого ресурса, которые вы можете допустить. Если очередь MDB удаленная, вы, вероятно, захотите считать удаленные соединения (или технически сеансы JMS) конечным ресурсом. Если к MDB предъявляются менее конечные требования (и очередь является локальной), максимальный предел становится числом потоков, используемой памяти и / или неиспользуемым ЦП, потребляемым рабочими потоками. Причиной здесь является то, что контейнер JBoss MDB будет просто продолжать выделять больше экземпляров MDB (и, следовательно, потоков), пока очередь не станет пустой или не будет достигнут максимальный предел. Единственная причина, по которой я могу подумать, что вы действительно будете мучиться сверх минимума, заключается в том, что истекшее время или накладные расходы контейнера на создание новых экземпляров превышают ваш допуск, и эти операции обычно довольно маленькие.
Производители
Общая аксиома обмена сообщениями заключается в том, что производители почти всегда превосходят потребителей. Вы могли бы подумать, что это довольно произвольно, но это шаблон, который я вижу постоянно, даже в самых разных сценариях обмена сообщениями. В любом случае, сложно сказать, как многопоточность должна работать для производителя, не зная немного о приложении, но способны ли вы на [неопределенно] пропорционально увеличивать количество потоков производителя и количество генерируемых сообщений, или у вас есть некоторые Что-то вроде шапки, где дополнительные темы просто не генерируют больше сообщений? Я предполагаю, что это последнее, так как наиболее полезная работа имеет некоторые ограниченные данные или расчет поставщика. На мой взгляд, два драйвера здесь - это порядок и постоянство.
Во-первых, если у вас строгий порядок сообщений, где сообщения должны обрабатываться строго (FPFP). Сначала производится - сначала обрабатывается, тогда вы немного затруднены, потому что вам почти приходится переходить на однопоточную пропускную способность, если вы не можете разработайте некоторую форму логического разграничения сообщений (например, номер клиента, когда сообщения любого данного клиента всегда отправляются в одну и ту же очередь, но у вас может быть несколько очередей, каждая из которых обслуживается одним потоком, поэтому каждый клиент фактически является FPFP).
Если оставить в стороне, постоянство является следующим соображением, если у вас есть надежная и обширная устойчивость сообщений (или очень высокий допуск к потере сообщений), просто отправьте потоки производителя в город. Сообщения будут надежно помещаться в очередь, и в конечном итоге потребители [надеются] наверстать упущенное. Однако, если количество сообщений в вашей персистентности или простая глубина очереди могут потенциально дать вам волю, когда они становятся слишком высокими, вот где инструмент может пригодиться. Если число потоков вашего производителя может быть динамически изменено (что они могут во многих реализациях Java ThreadPool), то вы можете выбрать глубину очереди и увеличить или уменьшить количество потоков производителя в соответствии с определенными вами диапазонами глубины очереди, необязательно до точки, где, если потребители в основном останавливаются, так же как и производители. Я не знаю какого-либо конкретного инструмента, который бы это делал, но между двумя серверами JBoss это довольно просто сделать. Выбор глубины очереди -> количество потоков производителей будет сложнее.
Сказав все это, я действительно прочитаю статью, на которую вы ссылались .....