On Tue, Sep 25, 2012 at 4:29 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Sun, Sep 23, 2012 at 2:33 PM, Stefan Fuhrmann
> <stefan.fuhrmann_at_wandisco.com> wrote:
> > On Sat, Sep 22, 2012 at 7:13 PM, Johan Corveleyn <jcorvel_at_gmail.com>
> wrote:
> >>
> >> Heh, next question: what are those "slow places" mainly, and do you
> >> have any ideas to speed those up as well? Are there (even only
> >> theoretical) possibilities here? Or would that require major
> >> revamping? Or is it simply theoretically not possible to overcome
> >> certain bottlenecks?
> >
> > It is not entirely clear, yet, where that overhead comes from.
> > However,
> >
> > * IIRC, we use the same reporter on the same granularity,
> > the server pushes a whole file tree out to the client with no
> > need for extra roundtrips. But I may be mistaken here.
>
> With 1.8 there will only be ra_serf for http, and that does a separate
> http GET for every file during checkout/update. These requests can go
> in parallel. In most setups, with KeepAlive enabled, TCP connections
> will be reused, but still there will be a certain overhead for every
> http request/response. There is no giant streaming response with an
> entire tree.
>
Thanks for the clarification.
> > Another thing is that svnserve would be just fine for many
> > use-cases if only it had decent SSPI / ldap support. But
> > that is something we simply need to code. Power users
> > inside a LAN may then use svnserve and more flexible /
> > complicated setups are handled by an Apache server on
> > the same repository.
>
> Ah yes. If somebody could "fix" the auth support in svnserve (in a way
> that really works, as opposed to the current SASL support), that would
> be great :-). That would open up a lot more options for deployment.
>
I guess I should talk to our IT guys when I see
them next month. A non-trivial Windows Domain
setup would help testing such code.
> > Finally, 1.8 clients are much to slow to do anything useful
> > with that amount of bandwidth. Checksumming alone limits
> > the throughput to ~3Gb/s (for export since it only uses MD5)
> > or even ~1Gb/s (checkout calculates MD5 and SHA1).
> >
> > Future client will hopefully do much better here.
>
> Indeed. That would make the client again the clear bottleneck :-).
> Besides, even if you checksum at 3Gb/s, you'll need some seriously
> fast hardware to write to persistent storage at such a speed :-).
>
It's Gbits, not GBytes ;) And 300MB/s write speed is
not entirely outlandish considering todays SSDs.
-- Stefan^2.
--
*
Join us this October at Subversion Live
2012<http://www.wandisco.com/svn-live-2012>
for two days of best practice SVN training, networking, live demos,
committer meet and greet, and more! Space is limited, so get signed up
today<http://www.wandisco.com/svn-live-2012>
!
*
Received on 2012-09-25 17:05:10 CEST