3 ms·
Let's assume a has a time constraint, and needs to start shoveling bytes back to the client in 30ms. In the pipeline case, a probably only has visibility to b,
by jfoutz 5y ago
Let's assume a has a time constraint, and needs to start shoveling bytes back to the client in 30ms.
In the pipeline case, a probably only has visibility to b, each service in the chain has ~7ms to provide its response.
In the fan out case, a is aware of b c and d, they can each take 25ms or more and a can still meet its deadline.
The way a sets its timeouts will vary depending on what's happening downstream.
This is a pedantic and fussy point of view. Nobody really does this, some pretend they do. But it can be important for overall performance.
- DelightOne 5y agoOhh you talk about call pipelines, I totally missed the point. You are talking about time-constrained systems where an answer in the timeframe is required, right? Otherwise the timeout does not make sense, or would you do such precise timeouts even in non-time-constrained systems? Anyway, seems to make sense to plan for this timing-wise. Allows addressing and seeing performance bottlenecks. Thank you for spelling it out for me!
- jfoutz 5y agoFailure too. Recovery in a pipeline is different than fan out.