search

jaracil / nexus

Distributed RPC system
Other
11 stars 2 forks source link

Performance enhancement proposal #4

Closed oriolf closed 8 years ago

oriolf commented 8 years ago

This proposal aims to avoid unnecessary latency overhead and net traffic when a nexus service and a nexus client are on the same server.

Nowadays, if a client A and a service B are in the same server, when A calls B the petition has to go through nexus, to B, and then back through nexus. This is flexible but inefficient, and could be avoided if A knew about B being in the same server and sent the petition directly to it.

The proposal is to enhance nexus with capability to enable this performance improvement, without any change in the way that services are built and deployed.

A possible implementation would be as follows: service A makes its first request to B through nexus. Nexus handles the request, B answers back and nexus sends the response to A with some metadata attached to it that lets A know that B is in the same server. With that information, A sends its subsequent requests directly to B. If B fails, the next request from A would fail, and the client would send the request again to Nexus.

This implementation isolates A and B from changes in nexus, such as permission changes, so those would need some way to be propagated to all services that are using this pattern in order to avoid clients to consume services that they are no longer allowed to.

jaracil commented 8 years ago

The implementation will be too difficult and breaks a lot of Nexus architecture concepts.

Thanks.