Прежде чем вы начнете изучать другую архитектуру, которая, вероятно, потребует серьезного переписывания, выясните, куда все это время уходит. Настройте профилирование на серверах WildFly. Начните с того, что сделайте это с одним, затем сделайте несколько входящих звонков. Проверьте, сколько времени тратится в различных частях стека. Обрабатывается ли один вызов веб-службы довольно медленно? Тогда посмотрите, куда уходит это время. Это может быть доступ к базе данных. Один такой вызов обрабатывается довольно быстро на самом сервере после его поступления? Тогда вам лучше всего потерять время на сетевом уровне.
Проверьте сетевой трафик. Для этого вы можете использовать Wireshark или аналогичный инструмент трассировки. Посмотрите, сколько фактически времени проходит между входящим запросом и выходящим ответом. Это медленно, но обработка самой Wildfly кажется достаточно быстрой? Может быть, что-то происходит (например, безопасность). Время между запросом и ответом очень быстро? Вы определенно видите в сети виновника.
В конце концов вам может потребоваться активировать профилирование и трассировку сети на всех трех серверах одновременно, чтобы увидеть, что происходит, или для каждой комбинации двух серверов. Может оказаться, что только одно из них является узким местом. И если у вас есть серверы A, B и C, из-за их звука ваша установка может привести к тому, что вызов с A до B также потребует вызова с B до C до некоторый результат может быть возвращен на A. Если это так, то неудивительно, что вы видите серьезную задержку.
Но измерьте и найдите корень проблемы, прежде чем начать принимать решение об изменении всей платформы и другого языка программирования. В противном случае вы можете уделить много времени чему-либо без каких-либо улучшений. Если архитектура в корне ошибочна, вам нужно подумать о другом подходе. Если это все еще находится на стадии прототипирования, это было бы значительно проще.