Will caching work if one of the web servers has a clock that is slightly off?

views:

answers:

Will caching work if one of the web servers has a clock that is slightly off?

It is said that the web servers' clocks must be identical for the Expires and Cache-Control headers to work? Why is that? Can't they be off by 1 second or a few minutes?

If the cache is supposed to be good for 1 year, then won't a time difference of a few minutes or even a few hours not matter on one or some of the web servers?

In http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html
it is said that

note that in order for this [caching] to work, all your application servers must return the same timestamps. This means that they must have their clocks synchronized. If one of them drifts out of sync, you‘ll see different timestamps at random and the cache won‘t work. In that case the browser will request the same assets over and over again even thought they didn‘t change. You can use something like Live HTTP Headers for Firefox to verify that the cache is indeed working.

Note that this is Rails specific and only in the case where you have more than one web server serving the data.

Given that the cache stores the data using a timestamp, if the servers differ on what the timestamp is, the cache will always be invalidated on one of them (the one with the 'older' timestamp) as it will always think the file has been recently updated and thus think the request as a cache miss.

Vinko Vrsalovic 2010-07-21 00:20:16

is it due to another header(s)? Because if it is just `Expires` and `Cache-Control`, then the time slightly off shouldn't matter. So you mean the clock has to be accurate to the second? What if a machine can be off by a second after a few hours or even after 1 hour? Then all the machines has to sync to the exact same time every half hour?

動靜能量 2010-07-21 00:51:47

It's due to the application that will return the data as it were new or not. Remember that the code is what sends the headers depending on if it thinks the asset has been updated or not. I must reiterate that this is Rails specific, and not a property of browser caches (some comment in the answer below makes me doubt you are aware of that)

Vinko Vrsalovic 2010-07-21 06:17:30

If you run ntpd on all your hosts (and you do, don't you?) they'll be more than close enough. It has less to do with the headers than with the caching controllers generating the ?1232285206 at the end of the URLs. That's just a Unix epoch time (seconds since 00:00:00 Jan 1 1970), so being within a few seconds should do just fine for content that is okay to cache. ntpd typically keeps a quarter-second or less tolerance. (In a series of ntpdate tests against multiple time servers, my computer was never more than .15 seconds off.)

sarnold 2010-07-21 01:22:13

if it is a number like `1232285206` then shouldn't every second matter? (because `?1232285206` and `?1232285207` will create different URL already.) also, even if it is accurate to the second, won't there be cases like, when one controller runs, the time is 12:03.999997 and on another machine, the controller runs at 12:04.000001 and therefore they are "off by" one second (if the number is truncated (by math.floor))

動靜能量 2010-07-21 02:02:24

Sure, but chances are good that your assets don't change multiple times in one second -- they just need to be right-enough when the request is handled. When you change your assets, stale assets may be handed out for almost an entire second. If you cannot tolerate one-second-stale time, then perhaps caching your assets is not a good idea. But most web sites can handle one-second out-of-date cached objects. If the clocks on your servers was off by ten seconds, then you could be handing out 11-second stale data. But really, just run ntpd, and be happy. :)

sarnold 2010-07-21 02:32:06

Thanks for your answer. What do you mean most web sites can "handle" one-second out-of-date cached objects? Isn't it the browser that decide whether to reload something? Can you state it in specific terms... and why / how web server not care about a few second differences and what mechanism is at work and what is the limit (10 seconds? 15?)

動靜能量 2010-07-21 02:51:00

The timestamp placed at the end of the URL is based on the `mtime` timestamp of the asset file itself, not on the time of handling the request. Sorry I misunderstood the mechanism earlier; if this asset file has different `mtimes` on different application servers, then the file will be 'cached' under several names, and the clients may need to download it several times, once under each name. As for "handle one-second out-of-date", it's just that the clear majority of web sites do not need to-the-second accuracy of content.

sarnold 2010-07-21 03:28:58

ansaurus

tags:

views:

answers:

Will caching work if one of the web servers has a clock that is slightly off?

related questions