On Tue, Jun 5, 2012 at 11:12 AM, C. Michael Pilato <cmpil...@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/
