4 ms·
Couple of years ago I had this idea that most REST calls I had in my app could easily fit a single packet if encoded in binary. I rolled my own framework for f
by lmilcin 5y ago
Couple of years ago I had this idea that most REST calls I had in my app could easily fit a single packet if encoded in binary.
I rolled my own framework for fun that did REST-style communication but sans TCP, HTTP and JSON.
This improved latency and efficiency by couple orders of magnitude. I would like something that did this that I could use directly without having to write my own framework.
- puppet-master 5y agoThis sounds really interesting, could you provide a bit more detail on the application? Mostly interested in: - was it over a LAN or WAN? - how were the latency improvements measured? - was there a UI on the front end or was this strictly a backend to backend scenario
- lmilcin 5y agoIt was DC environment. I measure latency on a client, on service and on using some very expensive, cut-through switches. This shotgun method lets me lazily detect where the latency comes from with a single look. I understand not everybody has access to cut-through switching, but for most uses port mirroring is available on a lot of hardware Strictly backend.
- throw0101a 5y agoSounds like RPC over UDP. * https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_Procedure_Call https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_...
- Matthias247 5y agoDid the app before that made use of connection pooling and reuse? If yes then the latency gap is typically not high. You can still send a http request in a single ip packet as long as your framework doesn’t do anything wrong. Obviously there will a a latency hit for new connections. But in return you get handling of packet loss