> feedmail.org/0. This one looks like it's trying desperately to honor the max-age thing, but sometimes it arrives a hair too early - on the order of about 100 msec here. So weird. How damn often is it considering these polls for it to be able to hit it that close? Does it ever rest?
Haha, no we never rest.
Basically the poller looks at what the next feed to check is and sleeps until the scheduled time, then fires it off. There is a concurrency limit but in practice we don't hit it. So within the accuracy of a Linux sleep call we will be firing off the request.
However for whatever reason I decided that if the scheduled time is within 1s of the target we just skip the sleep, so that is where the earliness comes from.
The reason she has seen 100ms rather than closer to 1s is probably because we calculate the time based on when we receive the response and there are things like DNS and TCP setup that will delay the request a bit. This feed seems to consistently respond in under 0.4s so in theory we could be slightly earlier. But I don't think people with max-age=3600 are worried about a few hundred milliseconds.
Haha, no we never rest.
Basically the poller looks at what the next feed to check is and sleeps until the scheduled time, then fires it off. There is a concurrency limit but in practice we don't hit it. So within the accuracy of a Linux sleep call we will be firing off the request.
However for whatever reason I decided that if the scheduled time is within 1s of the target we just skip the sleep, so that is where the earliness comes from.
The reason she has seen 100ms rather than closer to 1s is probably because we calculate the time based on when we receive the response and there are things like DNS and TCP setup that will delay the request a bit. This feed seems to consistently respond in under 0.4s so in theory we could be slightly earlier. But I don't think people with max-age=3600 are worried about a few hundred milliseconds.