[nbm]

In the two cases mentioned, there isn't any extra _response_ time.

> servers cannot periodically advertise their load measures to clients

This is an asynchronous mechanism - you can use polling, push, or queue, or whatever. Individual responses don't pay the cost.

> staple current load reports to query responses, which the client can cache and use for a period of time

This is just a few extra bytes in the response, which likely has negligible cost. One can fairly reasonably say that responses don't pay any cost.

Obviously there are other costs - it just depends on what you're trading off between on whether it is the right decision.

[vijayjayaram]

Author here. Great points, I agree 2 extra round trips are not strictly necessary.

The advantage of P2C is the simplicity that comes from its stateless/just-in-time nature. If you cache load, either by servers broadcasting or including a load indicator in the response, you have to consider cache invalidation and TTLs. The longer the TTL, the higher the odds of a thundering herd (all clients think one server is under loaded and proceed to overload it). If you're undertaking this complexity, it may be better to go with a proxy, which can have other benefits too (connection pooling, no client cooperation required). Like all such decisions, it depends on the situation.

[nbm]

Even in the proxy case (which is my day job), it's often worth the price of the up-front load polling to have sufficiently recent information to take action on. The most obvious cases are those where you have some (or all) requests being expensive, as opposed to thousands of exclusively tiny requests.

This does depend on having a local load balancing layer (not, say, making a choice between two servers that are each 50+ms away from the load balancer), and also having a high-performance RPC stack (C++ on both sides, and Thrift, in my case).