Re: [Sidebar] - Interesting discussion on impact of "simple" HTTP requests

On Tue, Jun 5, 2012 at 11:12 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:

> Maybe an Apache HTTP Server person could speak up here.  In such scenaries,
> does it matter whether the bazillions of tiny requests are coming in via a
> single connection or over unique ones?  Ours would be hitting the server via
> a small handful of connections; I don't know enough about Eclipse to say if
> that's also true for them, though the blog post you mention above seems to
> imply that while it didn't use to the be the case, Eclipse does now reuse
> connections.

In terms of Eclipse, which was mainly looking at this from the point
of view of bandwidth, the effect of this caused the bandwidth required
to service those requests to go from 384 MB, bad, to 1.5 GB, really
bad. The extra bandwidth due to the additional requests needed for
session negotiation each time.

> I'll do my best to summarize the current thoughts around the requests and
> request types you mention above.  Greg, Ivan, or others will surely correct
> me if/where I'm wrong:
>
> Ivan and I have already stated that we think ra_serf needs to grow support
> for the send-me-everything-in-the-REPORT mode as a client-side option,
> perhaps when/if it detects that the server can't hack the typical approach.
>  (Or perhaps even exposed via the ~/.subversion/server settings... I dunno.)

FWIW, it seems to me it should be a server setting. Obviously older
clients would use the approach they support.

> As a measure short of all that, though, we could simply include properties
> in the REPORT response, eliminating PROPFINDs altogether.  I mean, the
> server already has the properties in hand, and is simply dropping them on
> the floor rather than streaming them in the REPORT response today, only to
> have the client turn back around ask for the same data.
>
> Greg, on the other hand, prefers to see us stick with the current REPORT
> functionality, but replace the per-file-and-directory-depth-empty PROPFINDs
> with per-directory-depth-immediates PROPFINDs.
>
> As for the HEAD requests we issue today during update/checkout, those are in
> lieu of GETs, and could (*should*) be eliminated entirely, but I simply
> haven't figured out the right way to do so.

I am somewhat neutral on the GET requests. Today, the Neon approach
seems to be faster but Justin/Greg make some good points about Base-64
etc that imply that maybe if we tackled some of these other issues
then they would become more even or Serf approach might even be faster
(especially combined with the change you made). From the standpoint
of a server admin, I think the file data has to be sent to the client
no matter what. So whether it is multiple GET requests or a single
REPORT response is not necessarily the main issue. I think the issue
that a server admin has trouble wrapping their head around is all of
the other requests that at least on the surface seem like they could
be handled with fewer requests (or none at all). So I would be in
favor of continuing to optimize our protocol to remove more of these
requests from the conversation.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/