On Wed, Jun 6, 2012 at 8:00 AM, Peter Samuelson <pe...@p12n.org> wrote: > This sort of thing is, in fact, often done in DNS. (A "single UDP > packet", indeed, with an already deployed global caching scheme with a > configurable lifetime.) SpamAssassin rule updates, for instance.
Yup. And, Apache's infrastructure team handles SpamAssassin's rule updates without any real worries through an automated system and a collection of public DNS slaves. The drawback from a DNS-based check is that it's harder to collect stats on who is out-of-date if you use DNS - eg, Google DNS at 8.8.8.8 will serve cached responses to the client without telling our masters. However, DNS is indeed likely the most efficient and scalable way to do a quick update check that a whole bunch of users are going to hit. I think the moral of the Eclipse situation is that you have to understand the protocol's use case and do your best to optimize for it without boxing yourself in. While I know a lot of people like the theory of the REPORT call being one giant request, I think it's very hard to scale that out in a high-load situation without doing something like our full-blown proxies which has the FS locally. I look forward to reducing our PROPFIND requests next week in Berlin! I'll be very curious to see where the traffic numbers end up after that gets implemented. -- justin
