On 06/05/2012 10:49 AM, Mark Phippard wrote:
> Some interesting discussion going on this week at Eclipse.org (none of
> this is specifically related to SVN):
>
> http://eclipsewebmaster.blogspot.ca/2012/06/problems-of-scale.html
>
> Which spawned:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=381598
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=381620
>
> Among others. There could be some Serf relevance here, although to be
> honest I think the way Neon works with HTTPv1 in many ways may be even
> more relevant.
>
> 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.
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.
> I am not sure if there is anything for us to learn, but I suspect
> there is. If nothing else, it is interesting to see the impact that a
> seemingly small and simple request can have when it is multiplied by
> millions of users. If there are ways we can continue the work we
> started with HTTPv2 and eliminate more HTTP requests there would be
> benefits. For example, we still issue a lot of HEAD and PROPFIND
> requests during update and checkout. Maybe we could include more
> information in the REPORT response to eliminate the need for those
> additional requests.
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.)
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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-06-05 17:13:17 CEST