On Wed, Jun 6, 2012 at 8:00 AM, Peter Samuelson <peter_at_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
Received on 2012-06-06 22:39:07 CEST