处理背压与吞吐

目标

学会将队列深度翻译为延迟时间，通过上限和负载阻断使系统自我保护后，通过同步性调节实际提高处理率。

为什么重要

放入队列的系统的故障大多是“队列堆积，但没有人知道”。API仪表板都是绿色的，响应时间也正常，只有用户看不到结果。如果不能将队列深度翻译为延迟，就无法判断这种情况有多严重。小力的定律W = L / λ简化为一行——深度3000，处理率每秒50件，现在接收的用户要等60秒。而且，如果利用率接近100%，等待时间不是线性的，而是呈指数级增长，用图表一看，就会明白为什么不能将工作者的容量调整为流入量的100%。

阶段

/opt/app/loadgen.py罗q:work每秒放入200件，持续10秒。LLEN q:work必须大于1500。
/root/qb/measure.sh以1秒间隔测量10次球道深度/root/qb/depth.csv在t,depth和海瑟一起留下11行。
/root/qb/little.txt在L=<깊이> lambda=<초당 처리 건수> W=<초>写下三个值。W是将L除以lambda得到的值，必须与小数点后第一位相符。
/root/qb/api.py将 127.0.0.1:8142 启动。POST /enqueue如果队列长度超过1000，则给429。如果小于1000，则给202。
429 回答中Retry-After将叶头放入清水中浸泡一小时。/root/qb/shed.out在status=429 retry_after=<정수>写。
同样的500件分别用1个和4个工作者处理/root/qb/concurrency.txt在workers=1 seconds=<값>科workers=4 seconds=<값>写两行。4个边要更快。
/root/qb/report.md在## 안정 조건，## 목표 이용률，## 상한 정책放入三个标题，每个段落写25字以上。

参考

稳定条件：λ < μ。利用率ρ = λ/μ以0.7~0.8为目标。
李特尔定律：L = λ x W，倒过来是 W = L / λ
库深度通知的趋势，如“持续增加5分钟”而不是绝对值，是值得信赖的。
常见的错误：只增加 Walker，而没有确认后面的DB是否成为新的瓶颈。

放入下属填充队列

/opt/app/loadgen.py罗q:work每秒放入200件，持续10秒。LLEN q:work必须大于1500。

/opt/app/loadgen.py 接受几秒钟内要插入几件的参数。要比处理速度快插入才能增加深度。

记录キュー深度时间序列

/root/qb/measure.sh以1秒间隔测量10次球道深度/root/qb/depth.csv在t,depth和海瑟一起留下11行。

每隔1秒测量长度，并以CSV格式保存。不要忘记标题行。

用利特尔的定律估计等待时间

/root/qb/little.txt在L=<깊이> lambda=<초당 처리 건수> W=<초>写下三个值。W是将L除以lambda得到的值，必须与小数点后第一位相符。

停留时间是将深度除以处理率得出的值。必须分别填写三个值才能得分。

把Q上限和429粘在一起

/root/qb/api.py将 127.0.0.1:8142 启动。POST /enqueue如果队列长度超过1000，则给429。如果小于1000，则给202。

与其说接受了却做不到，不如说现在不能接受更诚实。超过上限就拒绝吧。

通过Retry-After告知重新尝试的时间点

429 回答中Retry-After将叶头放入清水中浸泡一小时。/root/qb/shed.out在status=429 retry_after=<정수>写。

会用数字告诉客户什么时候再来就可以了。在队列深度中计算会更准确。

提高工作者的同步性，改善处理率

同样的500件分别用1个和4个工作者处理/root/qb/concurrency.txt在workers=1 seconds=<값>科workers=4 seconds=<값>写两行。4个边要更快。

分别用1个和4个工作者处理相同的工作负载，比较所需时间。请保留两个值。

整理稳定条件

/root/qb/report.md在## 안정 조건，## 목표 이용률，## 상한 정책放入三个标题，每个段落写25字以上。

将流入率和处理率的关系、目标利用率、上限政策整理成文档。请准确使用指定的标题。