On Tue, Jun 5, 2012 at 10:49 AM, Mark Phippard <markphip_at_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
Received on 2012-06-05 17:26:09 CEST