On Mon, Apr 8, 2013 at 6:00 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
> > Sent: maandag 8 april 2013 16:11
> > To: commits_at_subversion.apache.org
> > Subject: svn commit: r1465647 - /subversion/site/publish/docs/release-
> > notes/1.8.html
> >
> > Author: stefan2
> > Date: Mon Apr 8 14:11:21 2013
> > New Revision: 1465647
> >
> > URL: http://svn.apache.org/r1465647
> > Log:
> > Update the release notes in light of r1465622. We will no longer
> > time out in zero-copy mode but naive use of this option will still
> > have adverse effects on quality of service.
> >
> > * publish/docs/release-notes/1.8.html
> > (svnserve): replace the bit about timeouts;
> > add a note about cache dependency
> >
> > Modified:
> > subversion/site/publish/docs/release-notes/1.8.html
> >
> > Modified: subversion/site/publish/docs/release-notes/1.8.html
> > URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-
> > notes/1.8.html?rev=1465647&r1=1465646&r2=1465647&view=diff
> > ==========================================================
> > ====================
> > --- subversion/site/publish/docs/release-notes/1.8.html (original)
> > +++ subversion/site/publish/docs/release-notes/1.8.html Mon Apr 8
> > 14:11:21 2013
> > @@ -1560,13 +1560,16 @@ CPU load. Future clients may be able, ho
> > </p>
> >
> > <p>When the server is given the <tt>--client-speed N</tt> parameter,
> > -it will assume that <tt>all</tt> clients are able to process data rates
> > -of N Gbit/s; N being a non-negative integer. With N>0, the server
> will
> > +it will assume that most clients are able to process data at rates of
> > +N Gbit/s; N being a non-negative integer. With N>0, the server will
> > take various shortcuts to reduce internal processing overhead. On the
> > -downside, it must employ strict time-outs to prevent clients from
> > -interfering with each other: In any 1 second interval, a client must
> process
> > -incoming data with at least 2% of the specified speed - or the server
> > -may time out and abort the operation.
> > +downside, a hanging client may cause server performance to degrade for
> > +other clients. Setting N to values above 100 is legal but will often
> > +result in a net performance loss.
> > +</p>
>
> Would it help if we would use Mbit here, to allow other types of
> improvements later?
>
Good point!
> In general I'm committing over the internet and I don't think these speeds
> make any sense here in the forseeable future, while I could see us
> optimizing between ADSL (1-20 Mbit down, 0.25-4 up) and fiber (20-300 Mbit
> synchronous) in future versions.
>
Changed in r1466918. One thing we might do in future is to
select default network data compression levels depending on
the --client-speed parameter.
> I don't see a more than one GBit connection to a server anywhere in sight
> for workstations, except for very specific network setups. (Server-server
> might go to 10 Gbit/s in the near future, but that is not a common
> workstation scenario)
>
If your server suffers from frequent stampedes (100 users trying
to checking out the latest release at the same time in a LAN),
that option can help you to reduce the server load a bit.
> If we switch to Mbits/s as value we should still be able to talk about
> more than a Pbit/s using a normal integer.
>
Thanks for the review!
-- Stefan^2.
--
*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*
*
*
Received on 2013-04-11 17:55:57 CEST