Garethwduncan Posted July 2, 2009 Report Share Posted July 2, 2009 (edited) After upgrading from retrospect 6.x to 8.x we found that the speed of backing up from a client to our raid was dramatically slower. which was really disappointing and had pushed our backup window to 26+ hours which is not acceptable. So we hit the forums looking for answers, long and the short of it ? most posts we found digressed into reinstalling Retrospect 6.x, and the comment from the Retro lads was basically "Sorry we had to get it release by deadlines, we'll fix performance issues in patches" Our findings! We found that Sharing the folder we are going to backup (of Course Owner:Read&Write Group:Read&Write Everyone:None) then adding the share in Retrospect over afp. + Add Source --> Add Share --> afp:///Share_name/ . This increases our backup speed dramatically on average 10x the write speed, bring it back to a decent speed / backup window. Copying Folders/Files using the client Performance: 124.7 MB/minute (123.9 copy, 125.5 compare) When u have 800 odd gig to back up is painful. However ! AFP for the Save. Copying Folders/Files using AFP Performance: 1741.1 MB/minute (1869.0 copy, 1629.5 compare) Much faster! but not without its own issues. The problem with this is that the "shares" aren't monitored and show up as "not backed up" Basically because its not using the client to do the backups its just using AFP, Anyways I hope helps some people out, Edited July 3, 2009 by Guest Quote Link to comment Share on other sites More sharing options...
lucius Posted July 3, 2009 Report Share Posted July 3, 2009 Wow, that's interesting. Yikes, what could the Retrospect client be doing that slows transfers down by an order of magnitude? Quote Link to comment Share on other sites More sharing options...
Mayoff Posted July 3, 2009 Report Share Posted July 3, 2009 I agree it is interesting and we will write a bug for this and investigate what is going on. It is possible that on your network the traffic over filesharing vs the client TCP connection is taking a different path that is specific to that network. What is the speed when you refresh the connection in the source screen? Quote Link to comment Share on other sites More sharing options...
rhwalker Posted July 3, 2009 Report Share Posted July 3, 2009 I agree it is interesting and we will write a bug for this and investigate what is going on. It is possible that on your network the traffic over filesharing vs the client TCP connection is taking a different path that is specific to that network. What is the speed when you refresh the connection in the source screen? I believe that this is unrelated to routing path and is instead due to the protocol and my suspicion that Retrospect 8 is not doing overlapped windowing of packets to/from the client (or, if it is, is not doing it right). Robin, it's my understanding, unless something has changed with Retrospect 8, that Retrospect still communicates with its clients via UDP over port 497 (rather than TCP). The TCP protocol handles windowing and buffering, etc., whereas UDP, being a datagram protocol, does not. See my earlier post on this same subject in another forum here: Retrospect network performance AFP over IP is designed for performance, and the OS handles buffering, etc., to move things along. I would hope that, as Retrospect 8 matures into a real product usable in a production environment, attention can be devoted to tuning performance issues such as this rather than, as now, being focused on getting it to simply work. Russ Quote Link to comment Share on other sites More sharing options...
Mayoff Posted July 3, 2009 Report Share Posted July 3, 2009 Retrospect still communicates with its clients via UDP over port 497 (rather than TCP) Retrospect ONLY uses UDP for client discovery and has never used it for the transfer to data. This is true today as it always has been the case. Connection switches to TCP after it is found on the network. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted July 3, 2009 Report Share Posted July 3, 2009 Thanks for clearing up my misunderstanding. I apologize for my erroneous understanding. In that case, it's a true mystery to me as well unless it's something as simple as a mis-set option for the TCP socket that is opened, or needing bigger buffers to be allocated for larger transfers. Also, the original poster doesn't say how much memory is on the client or engine. Perhaps its an issue of not being able to allocate gobs of buffers due to the greater memory requirements of Retrospecct 8. Russ Quote Link to comment Share on other sites More sharing options...
Garethwduncan Posted July 5, 2009 Author Report Share Posted July 5, 2009 Hi guys, Sorry bout the delay in response its been the weekend and all, The Server the engine is running on is 2x3gig Xeons, 8 gig of ram, 1 gig NIC, fiber to the raid its writing too, Clients are Imac 20's-24's, Altho it didnt seem to make a difference when testing on a client backing up a identical server to the engine. More than happy to provide any information ya'll need. oh and, What is the speed when you refresh the connection in the source screen? About 20-25 secounds Quote Link to comment Share on other sites More sharing options...
Mayoff Posted July 6, 2009 Report Share Posted July 6, 2009 I have logged bug 22680 to track this issue. Quote Link to comment Share on other sites More sharing options...
Maser Posted July 6, 2009 Report Share Posted July 6, 2009 FWIW... I went to reproduce this and I can -- sort of. Yes, the *backup* speed of the same folder when mounted via AFP is faster -- significantly faster. However, the amount of time to *scan the folder* before the backup starts -- is about 3 times longer. So the *overall time* of the backup of an AFP client is a lot longer. For my test scenario, it took 15 minutes (total) to do everything to a new disk media set with the standard client setup. But it took *30 minutes* to do it with an AFP setup -- even though the *backup speed* was reported as being faster. EMC just needs to get the scanning speed of the standard client connection and the backups speed of an AFP mount and they'd be all set! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.