то у тебя проблемы)

Короч добавить ресурсов и переписать на что-то по-быстрее.. а ты хорош

это транспорт. Что и как ты между штуками через него гоняешь не столь важно. Но для кейса "сделали запрос и надо сходить в другую штуку" это не самая разумная идея.

логично, если вам нужен отладчик, то у вас проблемы
пацаны без всяких отладчиков в вардампы срут

вардампы это не эффективный спосб дебага рантайма. Моин поинт в том что если есть код и он работает не так как ты его читаешь - то скорее всего там проблема. Надо ее решать или нет зависит от того насколько часто тебе приходится тратить время на отладку этого участка кода.

логи по твоей логике же вардампы, но это ж не так и флоу работы с логами отличается от отладки локально

а еще лучше поставить рей)

скорее всего причина тупняка - накладные расходы на инициализацию процесса. Типичная история с "микросервисами на пыхе". Вариант тут только один - убрать эти накладные расходы (или как минимум уменьшить).

Если заменить эластику на кролика или на мускуль какой то помимо бутстраппинга фреймворка появляются всякие сетевые вещи вроде "а открой ка tcp соединение". А если у тебя комуникации по tls то еще больше накладных расходов на подключение. Потому выгодно держать процесс вечно поднятым и реюзать существующие соединения.

Даже если мы говорим про эластику за TLS то просто реюз tcp соединения (аля keep alive) уже уменьшает накладные расходы на запрос.

пых или не пых это уже каждый решает сам. Для простых кейсов есть всякие road runner-ы (с которыми увы приходится разбираться ибо тупо взять и юзать - неожиданные проблемы в проде). Я просто предпочитаю такие простые штуки делать на ноде какой или еще на чем с чем умею работать.

потому обмазываются всякими pgbouncer-ами и прочими проксями, ставят всякие прокси которые делают терминацию TLS трафика между сервисами (что бы коннекшены держать открытыми) и много чего еще.

У меня был кейс когда старт симфони со всеми прибабахами был скажем 5ms а все хэндшейки между сервисами базами и прочим было где-то 10ms. Сама же логика обработки или там "распарсить http запрос" - тут не важно пых или не пых. Есть кейсы где разницу можно почувствовать но обычно упираются в оч не эффективную работу с IO у пыхи.

Tls мешает держать соединение?

ну пых умирает и коннекшена больше нет

Так с пыхом и не tls умирает)

да, просто хэндшейк с tls и без выглядят чуть по разному

на одном из проектов было но ходили сообщения с инфой для помещения в индекс, типа продукт создан/обновлен/удален, а не запросы-ответы

https://hpbn.co/assets/diagrams/b83b75dbbf5b7e4be31c8000f91fc1a8.svg

ну вот пример (больше для браузеров актуально, на сервере все ж лэтенски не такие конские)

мол при пинге между серверами в 28ms у тебя на TCP соединение уходит 56ms а на TLS сверху еще 112.

Не слишком жёсткий пинг на картинке?

ну это "Обычный" пинг из браузера. На сервере у тебя это будет 1-2ms если в разных A/Z

на тему лэтенси... был кейс. Есть консюмер для не оч важных очередей. Он обрабатывает сообщеньки из очереди с prefetch 100. Сообщенек много. Все работало хорошо. Вжух решили "надо горизонтально масштабироваться" и вместо одного сервера где все было хорошо разнесли на 3 сервера. Теперь лэтенси для доставки сообщенек увеличилось до огромных "0.5ms" в среднем. Много это? мало? prefetch 100 же должно успевать.

В пиковые часы очередь забивалась на миллионы сообщенький и кролику становилось плохо (lazy очереди помогают в таком но мы не ожидали что там в целом такое может произойти).

При этом 99% времени и консьюмер и продьюсер простаивали. В итоге добавили батчинг (что просто сотни сообщений запаковываются в одно большое) что бы избежать просадки по сети.

по-моему тут многовато операций на сендере