Just a quick comment, I've had slow clients and have tended to segregate
them from the fast ones for two reasons

1 Slow clients can slow down the saveset completion delaying the
automatic cloning until the slowest client has finished
2. To avoid tying up resources (I'd rather have a bunch of slow clients
using 1 tape drive - or disk device - than use one each).

It shouldn't slow any clients down, faster clients will just write more
blocks in the same time.

Regards
Bob


-----Original Message-----
From: Legato NetWorker discussion [mailto:NETWORKER AT LISTMAIL.TEMPLE DOT EDU]
On Behalf Of Darren Dunham
Sent: 29 November 2004 20:38
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] performance impacted by slow client


> I'm looking for information about how/whether a slow client may impact

> the performance of other backup clients.  One source that I've 
> consulted is telling me that one slow client multiplexed onto a tape 
> with faster clients will slow down the faster clients.  Is this 
> possible?

That's not what I've seen.  Now you don't want to multiplex too many
hosts onto your drive, but if one is slow, I've seen that it doesn't
affect the others greatly.

When you do the restore, you're going to have to read a *lot* of tape
though.  This may not be a big problem, because you might be waiting on
the slow client for the restore also.  If you're doing a local restore
of the data though, it will slow you down.

> They are recommending that I segregate the slower clients in my 
> environment onto a separate pool or within a separate group so that 
> this doesn't happen.  Is this correct?  It was my impression that 
> groups and pools were designed to logically segregate data based on 
> data requirements rather than as tools to tune a backup's performance.

Hmm.  It would depend on the exact circumstances, but I haven't seen
this be a source of problems before.

I'd prefer to create pools only for retention/storage requirements. That
simplifies things most of the way.

--
Darren Dunham                                           ddunham AT taos DOT com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

--
Note: To sign off this list, send a "signoff networker" command via
email to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can also
view and post messages to the list. Questions regarding this list should
be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=