priority 到底怎么影响请求的先后?能填什么值?并发高了还有效吗?高优先级请求会不会把低优先级的“饿死”?这篇用能记录到达顺序的服务器逐项量。
构造时报错的:[{'i': 4, 'p': '2.5', 'exc': 'TypeError: Request priority not an integer: 2.5'}, {'i': 6, 'p': "'7'", 'exc': "TypeError: Request priority not an integer: '7'"}, {'i': 7, 'p': 'None', 'exc': 'TypeError: Request priority not an integer: None'}];服务器收到的顺序(r<产生序号>):['r3', 'r1', 'r5', 'r0', 'r2'];finish_reason=finished;spider_exceptions=0
对应关系:r0=0, r1=5, r2=-5, r3=10**30, r4=2.5(浮点), r5=True, r6='7'(字符串), r7=None
日志里的错误:[]priority 只能是整数(bool 算整数),负数、很大的整数都可以;其它类型在构造 Request 时就抛 TypeError。
CONCURRENT_REQUESTS 逆序对数 服务器收到的优先级序列(前 24 个)
1 0 [9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 8, 8, 8, 7, 6, 6, 6, 6, 6]
4 0 [9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 8, 8, 8, 7, 6, 6, 6, 6, 6]
16 2 [9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 8, 8, 8, 6, 6, 7, 6, 6, 6]
60 133 [9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 6, 8, 6, 7, 6, 8, 6, 6, 3]优先级决定调度器先取哪个请求,不保证请求先到达服务器或先完成;并发越高,到达顺序越不受控。
(a) 高优先级链(hi0 → hi1 → … → hi9,每个在上一个响应之后才产生):服务器收到 ['hi0', 'low9', 'hi1', 'low8', 'hi2', 'low7', 'hi3', 'low6', 'hi4', 'low5', 'hi5', 'low4', 'hi6', 'low3', 'hi7', 'low2', 'hi8', 'low1', 'hi9', 'low0'] (b) 10 个高优先级请求和 10 个低优先级请求同时排队:服务器收到 ['hi9', 'hi8', 'hi7', 'hi6', 'hi5', 'hi4', 'hi3', 'hi2', 'hi1', 'hi0', 'low9', 'low8', 'low7', 'low6', 'low5', 'low4', 'low3', 'low2', 'low1', 'low0']
每次出队只在已有的请求里挑优先级最高的。高优先级请求如果还没产生,就轮到低优先级的;只有高优先级请求一直排在队里,低优先级的才会等待。