Comments 19
p.s. В документации есть примеры, которые построены на тегах по адресу объектов (например встречается delete this) — пугающая игра с ручной управлением памятью.
https://github.com/grpc/grpc/blob/master/examples/cpp/helloworld/greeter_async_server.cc
но ведь в gRPC есть несколько типов стримов на любой вкус: client to server, server to client, bidirectional. gRPC вполне подходит для чатиков, если учитывать проблемы, которые есть в любом протоколе.
P.S. вот пример https://github.com/dialogs/api-schema
Создаётся впечатление что исправляли проблему около полугода.
Новый — это jemalloc? Если нет, то пробовали ли его?
Если бы вы гоняли там какие-то PCI (номера кредиток например) или HIPAA (медицинские данные) или ещё какой-то compliance надо было соблюдать, то намучались бы ещё больше! Пришлось бы ещё извращаться с аллокаторами для gRPC и отдельно аллокаторами для Protobuf, чтобы они брали память из какой-то openssl secure arena, например, т.е. область памяти, которую нельзя отсвопить и/или добавить в coredump.
А разработчикам об этом сообщали?
Наверняка ведь вы не одни, кто использует tcmalloc, значит проблема вполне реальная. Ну и вообще логика работы с «одноразовыми» потокам — прямо скажем, посредственная, непонятно зачем так делать.
gRPC хорошо использовать для создания внешних интерфейсов, тогда клиенты могут использовать эту замечательную технологию "из коробки" и подключиться к вашему сервису из любого языка программирования.
Если вы пишете код для сервера и клиента, и тем более этот код на одном языке, например, C++, то gRPC слишком "дорого стоит". Как минимум, в gRPC надо было гонять flatbuffers, а не protobuf, столько лишних аллокаций у вас!
Если вам категорически хочется пользоваться модной-молодёжной библиотекой из-коробки, то смотрите в сторону Cap'n Proto, там zero-copy сериализация, и даже какой-то RPC есть.
Всё что нужно было вам написать — сообщения Запрос/Ответ, обязательное поле номер_сообщения. Запрос ложиться в unordered_map, где ключ номер_сообщения. Когда приходит ответ, то достаётся запрос, заполняются поля с ответом и запускается колбек.
На стороне сервера вы создаёте количество потоков равное количеству кор, или чуть больше, если у вас там какие-то дисковые операции есть. Что может быть проще и эффективнее?
Если у вас много полей и сложные данные и лениво писать сериализацию, то тут выбор из protobuf (дорого), flatbuffers (лучше), capnproto (совсем хорошо).
Опыт использования gRPC в Почте Mail.ru