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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
