В большинстве случаев перевод одноузлового приложения в многоузловое только ухудшит эксплуатационные характеристики вашего приложения. Либо Вы фактически заново разработаете ваше приложение при адаптации его в многоузловое.
"Мир" давно изменился. Одноузловые приложения встречаются очень редко. Либо ваше приложение пользуется сервисами других приложений (узлов), либо рано или поздно будет предоставлять свои сервисы другим приложениям (узлам). Отсюда вытекает требование разрабатывать ваше приложение сразу многоузловым. Многоузловое приложение можно в частном случае эксплуатировать в одноузловом варианте.
Для создания производительного приложения экономить целенаправленно нужно сразу и на всем на этапе разработки приложения по всей цепочке прохождения вызовов: клиент -> сеть -> программные слои вашего приложения -> сеть -> БД или другой узел -> сеть -> программные слои вашего приложения -> сеть -> клиент (не самая "сложная" цепочка)! Неоправданная потеря нескольких миллисекунд в каждом звене этой цепочки может Вам принести "на выходе" к потере нескольких или десятков секунд.
Для того, чтобы ориентироваться где в приложении возник провал производительности, нужно иметь какие то измерители для разных элементов цепочки вызовов. Хорошим решением считаю возврат хотя бы части наиболее критичных "измерений" в ответе запроса. Это значительно упрощает диагностику проблемы, особенно в распределенных (многоузловых) приложениях, достаточно взглянуть на полученный результат выполнения запроса.