Performance tuning NetBoot/SUS

dlondon
Valued Contributor

Hi,

We are just working on getting our NetBoot/SUS on a Redhat VM ready for prime time.

In my initial testing it's taking twice as long to NetBoot a test machine from the NetBoot/SUS server compared to our Xserve with NetBoot (the existing NetBoot Server). The Xserve however is using NFS whilst the NetBoot/SUS is using HTTP to give access to the rest of the NBI after the booter loads. When I say twice as long I mean from start of the machine to desktop loaded on the client machine. That time is around 6 minutes compared with 3 minutes.

Unfortunately the old machine is behaving flaky if I switch it to http so I can't easily make the comparison of both using http.

The NBI I am using is diskless and the shadow file etc is hosted from the AFP share on each server (not a RAMdisk).

I tried comparing network speeds/conditions by timing a large file transfer to each server (actually the complete NBI) using rsync and I get very similar times sending it to each machine - about 30 minutes for 15.2GB. Because of that I'm thinking the difference in times for the NetBoot boot times is more related to the server software in some way.

Does anyone have thoughts on what things can be tweaked to improve that NetBoot image boot time on the NetBoot/SUS?

Regards,

David

2 REPLIES 2

dlondon
Valued Contributor

I guess this is not such an issue for others.

I discovered that the VM volume we were using for the NBI and Shadow files etc was ISCSI attached which is much slower - something like 8 times slower than the other system disks. I asked for a faster volume and that has brought us back to NetBoot times of around 3 minutes to get to the desktop which is in the same region as the Xserve NetBoot server.

I'd still like to hear if anyone has any other thoughts on things to tune to get it better.

Regards,

David

bradtchapman
Valued Contributor II

This issue came up in our CCA class last week. Netboot/SUS is expected to run about half as fast as a real Mac. My gut feeling is that there is some component of the proprietary, Apple AFP stack makes it run more efficiently than the open source Netatalk, and they will never be able to emulate it.