• antirez's avatar
    Client timeout handling improved. · b029ff11
    antirez authored
    The previos attempt to process each client at least once every ten
    seconds was not a good idea, because:
    
    1. Usually because of the past min iterations set to 50, you get much
    better processing period most of the times.
    
    2. However when there are many clients and a normal setting for
    server.hz, the edge case is triggered, and waiting 10 seconds for a
    BLPOP that asked for 1 second is not ok.
    
    3. Moreover, because of the high min-itereations limit of 50, when HZ
    was set to an high value, the actual behavior was to process a lot of
    clients per second.
    
    Also the function checking for timeouts called gettimeofday() at each
    iteration which can be costly.
    
    The new implementation will try to process each client once per second,
    gets the current time as argument, and does not attempt to process more
    than 5 clients per iteration if not needed.
    
    So now:
    
    1. The CPU usage of an idle Redis process is the same or better.
    2. The CPU usage of a busy Redis process is the same or better.
    3. However a non trivial amount of work may be performed per iteration
    when there are many many clients. In this particular case the user may
    want to raise the "HZ" value if needed.
    
    Btw with 4000 clients it was still not possible to noticy any actual
    latency created by processing 400 clients per second, since the work
    performed for each client is pretty small.
    b029ff11
redis.c 144 KB