On Tue, Jun 5, 2012 at 10:49 AM, Mark Phippard <markp...@gmail.com> wrote: >... > The net effect is just the impact that a seemingly small HTTP request > can have on a highly trafficked site where those requests start to add > up. The main problem here is that the Eclipse update process looks > for a small index file that is currently always a HTTP 404. This
Heh. Reminds me of the traffic spike that occurred when a Google Code project used one of its version control for a configuration file. It was a proxy add-on for Firefox to navigate the Chinese firewall. Suddenly, every user who had the add-on installed was pinging code.google.com for this one file, retrieved via a Subversion URL. Daniel Berlin moved fast and introduced a cache that dropped our server load. > results in 1.5GB of network packets per day which basically amounts to > 152 minutes per day of their available bandwidth. The 404 itself is > not the problem, the bandwidth usage would be worse if the file > existed. The issue is more the design of the protocol and the > discovery it does each time it runs. This is probably similar to all > of the HEAD and PROPFIND requests we do in our protocol. They are > seeing similar bandwidth issues resulting from the usage of HEAD in > their protocol. It looks like the webmaster would like them to > explore doing more with a single request. Someone that understands > how our REPORT requests work might want to throw some commentary into: See above: cache. Not "lump things into one response". A reverse proxy (or several) in front of the primary (Subversion) server can 404 that request before introducing any load on the origin server. > https://bugs.eclipse.org/bugs/show_bug.cgi?id=381620 > > To explain how a single HTTP request could stream back multiple files > to the client. It looks like this would mean adopting WebDAV on their > servers and clients though. I'll look at those bugs and see what I can add to help them out. >... Cheers, -g
