Re: [sidr] btw: minutes for interim 27 Jul 2012

[Tim Bruijnzeels <[e-mail]>]

Hi,

On 21 Aug 2012, at 19:41, Murphy, Sandra wrote:

> What I forwarded before was the pure text of the minutes taken.
> 
> The minutes taker also published the minutes at a web site and incorporated snapshots of blackboard (literally) drawings.  Those might be useful in understanding the text, so I uploaded the html from the web site to the IETF site.
> 
> If you look at:
> http://www.ietf.org/proceedings/interim/2012/07/27/sidr/minutes/minutes-interim-2012-sidr-5
> 

A clarification on this:

> rsyncd performance testing
> full recursive fetch of just data (no validation)
> client had all the data, on a local network: just rsync overhead
> There is a boundary for clients/sec that can be handled that is constrained by the CPU.
> There is a boundary for the number of concurrent clients that is constrained by the memory available
> smallest test is 70k objects, and the real world isn't near that yet. yet. In the long term when we have 100k-400k ROAs then these numbers will become important.
> Steve K: server was mac mini, how much memory?
> Tim: 2Gb
> Steve: we should try this again with a real server
> Tim: I think the bigger issue is the CPU size, and there are much bigger CPU sizes out there of course
I don't remember my exact words, but what I meant to say regarding CPU is this:

= We see 1.6 clients/second for a repo size of 70k objects with the mac mini core 2 duo 3GHz cpu.
= Faster CPUs and more cores are available
= But the order of magnitude improvement that you can expect here is in 10s maybe 50s..
= And that is still a low number compared to http

= Increasing memory will allow more concurrent clients
= But if connection rate is consistently higher than the processing rate you will see concurrency increase until it hits the ceiling even if you increase memory

I think this is an intrinsic problem to the server having to invest a relatively large amount of CPU and memory when using rsync, just like Randy pointed at in his remark about my slide here:

> slide 26: latency has a huge impact
> Randy: so what you've traded is the CPU/memory cost for network cost?
> Tim: Yes
> we're pushing work from the repo server to the clients because I think it will scale better

Like I said, I don't remember the exact words I used during the interim so this may have been unclear then, even so I hope this clarifies things.


Thanks
Tim