i think rpc solutions should be able to gain in performance by having host byte order/little endian as the wire format. I mean spending all those cycles on bit swapping is pointless if both endpoints are in host byte order.
RPC Olympics – The Search for the Perfect RPC Protocol
41–50 of 71 posts
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#42We did a similar analysis in the early days at Elementary after rolling something custom based on ZMQ. We would up creating Atom: https://github.com/elementary-robotics/atom
Atom is an easy, Redis Streams-based RPC that also emphasizes docker containerization of microservices. We support plug-ang-play serialization with msgpack and Apache Arrow currently supported and more on the roadmap. You can also send raw binary if you please.
Another nice thing about Redis is that if you're running microservices on the same instance you can connect to redis through a linux socket on tmpfs and bypass the TCP stack to get even better performance.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#43Curious to hear anyone's experience with RPC over Nameko in Python. We use it extensively on top of RabbitMQ and its been pretty robust.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#44Curious to hear anyone's experience with RPC over Nameko in Python. We use it extensively on top of RabbitMQ and its been pretty robust.
RPC over Rabbit can work (and does) but you do have to remember that it in the end it is a queue and a couple of bad messages can stop your entire system.
RPC over Rabbit is fine if you don't care about the result, or you can guarantee that each message gets processed in a short constant time.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#45Having just looked into this recently, I can also safely say that moving to REST HTTP/2 on its own already provides a significant speed benefit. Closing the gap to GRPC (or even substantially beating it) is possible by switching to a fast serialization format (eg; flatbuffers, msgpack, capnproto). While GRPC has its place it also comes with headaches like pretty lousy generated interfaces, horrible debuggability, and…
Came here to say something similar. The interfaces and tooling around gRPC in the public sphere is pretty bad. If you maintain a code base with multiple languages and want to compile gRPC for it you can choose between:
1. Having a complex build system that is aware of gRPC
2. Massive migraines
Unfortunately build systems integrations, IDE integrations, and generated code is unanimously awful for gRPC.
Every company I've seen use grpc has unfortunately adopted the practice of basically manually running protoc and committing the generated code into repo - sometimes modifying the code manually to make it import successfully (Python).
I hope Bazel evolves into a state where it's usable by the average engineer and has first class support for gRPC.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#46Earlier quoted context omitted.
It wouldn’t really be an R PC, then would it?
It's not a normal procedure call within the same process.
Right. Those are methods for IPC. IPC doesn't have to deal with all the same issues as RPC, and so those techniques are going to be faster as a result. You can't really compare them.
It's like comparing communication between people physically located in the same room and people located on different continents.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#47My current rpc model for python is to pickle function name and args/kwargs and publish to redis for any subscribers that might be listening. If the channel is marked as persisting, I put the message to a hashset with current nanosecond as the timestamp and just send a ping instead. It is pretty fast with asyncio redis client clocking at an avg 15k rpc/s on a single core with uvloop on a lowly i7
Be careful using the pickle format; it's not considered safe to unpickle untrusted data. https://docs.python.org/3/library/pickle.html
I did see the big warning labels everywhere. However, there is simply no replacement that is equally fast (protocol 5), easy to use (copyreg) and imports necessary modules when deserializing. So tradeoffs were made.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#48Earlier quoted context omitted.
especially when you use the router pattern on server side in order to have multiple sessions on the same socket.
Got any references on the router pattern? I searched but came up with a lot of IT related articles.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#49Strong recommendation for ZeroMQ as well. It's a thin layer on TCP, is very fast, offers bindings in many languages, and is fairly flexible as well. https://zeromq.org/
I second this recommendation. I use MsgPack over ZeroMQ with a custom RPC protocol. Protobuf, Capn Proto, Flatbuffers are good serialization mechanisms as well. Can't wait until the new Socket Types are out of draft stage.
I believe GRPC is pluggable so if one wanted to invest time in building a GRPC ZeroMQ Transport then that is a feasible route. GRPC bring really good RPC mechanisms to the table.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#50No such thing as "RPC Protocol", there's a huge insurmountable gulf between "I want my Python and Javascript services to pass ad-hoc messages between themselves" and "I want to send C++ structs over the network with typesafety and minimal overhead".