Имелся ввиду tcmalloc, так как его мы подключали, когда хотели профилировать через gperftools. Были идеи попробовать jemalloc/mimalloc, но сейчас нас вполне устраивает tcmalloc.
Да, примерно так оно и продолжалось, мы не сразу сели за ее исправление. Сначала просто поднимали количество реплик и объем оперативной памяти. Затем решили переписать на асинхронную версию, которая тоже ничего не изменила. И только потом решили основательно подойти к поиску решения, потому что быстрые и простые меры ничем не помогли.
Пока не уверены, думали заиспользовать наш обычный подход с использованием boost::asio, устанавливать tcp соединение и не рвать его. Но хочется попробовать ещё мультиплексирование и попользоваться библиотекой в других сервисах, с другим профилем нагрузки.
gRPC это действительно история больше про запрос-ответ, поэтому для чата он не подойдет. По поводу асинхронного кода в примере — согласен, я попытался сделать свою обертку над этим АПИ: gist.github.com/lieroz/6ab0b844eb659cd8d202783f467c4e3d, но это не решило проблему с потоками.
Cap'n Proto видели, но побоялись использовать.
Именно так мы и хотели сначала сделать, но решили попробовать gRPC, потому что хотели побыстрее запуститься.
Пока не уверены, думали заиспользовать наш обычный подход с использованием boost::asio, устанавливать tcp соединение и не рвать его. Но хочется попробовать ещё мультиплексирование и попользоваться библиотекой в других сервисах, с другим профилем нагрузки.