On Tue, Sep 25, 2012 at 4:29 PM, Johan Corveleyn <jcor...@gmail.com> wrote:
> On Sun, Sep 23, 2012 at 2:33 PM, Stefan Fuhrmann > <stefan.fuhrm...@wandisco.com> wrote: > > On Sat, Sep 22, 2012 at 7:13 PM, Johan Corveleyn <jcor...@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> ! *
