|
continue the story
on peer-to-peer connection, in order not to lock unnecessary resources to obtain high performance, we used asynchronous requests but asynchronous is only responsible for the sending process, after firing the message, it forgets and listens to the response from the peer to trigger callback actions whenever it came back.
if the peer is implemented with a queue, it is fulfilled then drop the overflow message. The underlayer usually runs at full load, so a stream of steady bad latency KPI response that we earned.if the peer is not implemented with a queue, it is flooded and then degraded.
Therefore the response time increases with less throughput we earnedThis asynchronous sending mechanism cuts the pressure conjunction, making the client unable to know the server's healthy signal to refrain outgoing traffic.
Therefore we need a cascading method to transmit this lost pressure information back to the client to control the sending process.
so that is the work of Back-pressure strategies. they sense the high-pressure flow then avoid routing to it or tell the producer to refrain from the speed Back pressure is useful when handling the case where the input rate is greater than the system can handle. In that case, Back-pressure must maintain the highest throughput of best (acceptable) quality, in asynchronous mode of course.
3 basic strategies of backpressure are buffering, drop, and control speed. a good back pressure strategy must well control this 3 actions in real timeAs we all know buffering is just a temporary solution to flatten short peaks, if incoming speed is high rising, no queue can save us due to Little¡¯s Laws, and we must come to the last choice, drop.The last one is controlling the producer speed, this is what we target for designing our ILB.
Without flow control, to keep the load under the overload threshold, we usually need to plan large redundant capacity, and keep the system on even with the resources planned for the next 5-year growth. Furthermore, concurrency makes us maintain system utilization usually under 60% to archive stable URLLC KPI in core businesses, this 40% gap is a big waste.
|