SLOW imaging via AFP

[kirkd]

I am dealing with slow/disconnecting performance via Casper Imaging. Often the connection drops or crawls along at 4-12MB/s.

Here are some specifics that may help:

JSS 9.3 running on a OS X Server 3.1.1 Mid 2011 Mac Mini OS X 10.9.2
Distribution Point is setup via AFP - Port 548 is open on our firewall. I have not made any changes, the slow performance is constant, sometimes the imaging process won't even complete because the AFP connection shows as idle on OS X server.

Anyone have advice on this?

[bentoms]

We see the same with pretty much the same setup.

A reboot seems to fix.

[kirkd]

Hi Bentoms,
I have bounced the Mini a few times, it has yet to help performance. I plan on using a Thunderbolt external drive as an imaging solution, I was just hoping there was a way to fix the slow AFP connection. Also, is there another solution that might work or is AFP the only solution with my current setup?

[mpermann]

Are you using Casper Imaging on a netboot set? We ran into the same problem with our netboot server and the problem went away after a restart of the netboot server.

[bentoms]

Hmmm... Are you using NetBoot too?

I've not really had the time to look into it greatly.

[kirkd]

I am not using Netboot. I am target booting the Macs to my iMac and running Casper Imaging. The AFP distribution point mounts without issue, it's just painfully slow.

[scottb]

Have you tried to use SMB on the server instead?

[kirkd]

I have not, I see it is easy enough to tick the SMB box under File Sharing on OSX Server, how would I configure the distribution point in the JSS?

Edit: This seems simple enough, I can request port 139 on our firewall. I am unclear what to set as the Domain/workgroup.

[scottb]

Go to the server and edit. Change to SMB and the port to 389. Of course you need to make sure your shares are functioning before testing the JSS with SMB, but even though we use all Windows DP's, I'd think it's worth a shot.

[mpermann]

@kirkd, have you tried putting Casper Imaging on an external bootable hard drive and booting the system you are wanting to image from the external bootable drive and imaging it that way rather than using target imaging? I'm just wondering if it's some specific problem with the iMac or target imaging mode.

[kirkd]

@mpermann This is my next step. I am currently setting up an external Thunderbolt drive, I will test this out. If I don't find a solution I will just replicate my distribution point to the external drive and image that way.

[mpermann]

@kirkd, that would certainly take AFP out of the equation in your imaging workflow. I wasn't actually proposing that though. I just meant to try and use an external drive to boot from the specific computer needing imaged and still use the Casper share over AFP just to eliminate the iMac and Casper's target imaging mode as the culprit of your imaging problem. Also, are you able to push out packages in a reasonable amount of time with Casper Remote or is that slow as well? Do you only have AFP enabled or do you also have http/https enabled? I presume all your systems are using gigabit ethernet.

[kirkd]

Casper Remote and HTTP seems to work just fine. Actually, I use HTTP as a default for my policies because I know it's stable. Unfortunately our switches are 100mb.

[calum_rmit]

I think you may be confusing megaBITS with megaBYTES. a 100megaBIT switch can only transfer 10megaBYTES per second give or take. so if your seeing transfer speeds around this then that is normal and maximum for your network if there is a 100mb link anywhere between your client and your server. a network is like a chain, only as strong or as fast as its weakest link.
it sounds more like you have a networking issue rather than a casper imaging issue. I would try connecting to your share from your workstation and copying a large file ie 4Gb and see what transfer speeds you get. If it is similar to casper imaging then it pretty much shows either your network or fileserver is causing the slow down. to go further you could then connect your workstation directly to your file server via an unmanaged switch and try the same test and that will rule out the network side of things, that is, if you still experience dropouts or slowness (ie slower than the rated speed of the unmanaged switch) then the fileserver is to blame.

Hope that helps