Hi Andy,

On Fri, Feb 04, 2005 at 07:08:26PM -0800, Andrew Hanushevsky wrote:
> >   We really need to get the xrootd testbed hardware set up so that we
> > can dream up some real tests instead of deploying the latest development
> > version in the production system at CNAF.... One of the machines is
> > a linux server, is that correct? We could easily duplicate this sort
> > of situation at SLAC (250-300++ clients hitting various versions of xrootd
> > with various amounts of swap space). While SLAC still has solaris servers,
> > most of the rest of the world is more likely to be running linux servers
> > these days...
> Agreed. We've been running withy the new xrootd on Solaris x86, 400 clients,
> with no ill effects. So, I'd say that it's probably a good release. I still
> have to go through the memory trace and make sure the memory trim algorithm
> is wiorking as expected.
> >   Andy, assuming that the swap space and memory issues are dealt with (and
> > ignoring the random I/O and file descriptor limits), is there anything
> > else in xrootd itself that you expect will limit the number of clients?
> The only thing left is my using some data structure that doesn't scale well.
> I dont know of any right now, but that doesn't mean there isn't one (I could
> still be in the linear part of the curve). The limits really are controlled
> by a) number of allowed file descriptors, b) thread limit, and c) amount of
> real memory/swap space.. Everything else is fungible.

  Ok, once you finish testing the new memory algorithm let's try to beat
up some linux server with 1000 clients just to make sure we understand that
there are no unexpected limitations should that actually happen to someone.
(I have a couple of other tests I'd like to do with so many clients, but 
obviously we have to convince Akram to let us borrow the "miniq" for 24 
hours at some convenient point.. ;-)

  On Tuesday at the xrootd meeting, we should talk about turning the current 
"development" version into a "production" version. This should probably mean 
testing it to the point where we can deploy it on the production kan* servers 
at SLAC. In addition to the performance improvements, the other thing it
would be nice to push out into production is the server-side monitoring.
What do you think, Jacek? 


Peter Elmer     E-mail: [log in to unmask]      Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland