>Note that the package install is just under 2/3 of the total; >the SMF manifest import is an obvious target. There are also >pauses of a minute or two in the configuration phase that I >don't understand.
Perhaps those are the "uncompress java/X" bits? >The limiting factor in current installs appears to be the cpu >required to bzcat the archives. It took the test machine 2 minutes >to unpack the staroffice archive - going at 2M/s which is the >network data rate I observed during install. That's about 1/6 of >the total data - so 12 minutes of the 22 is bzcat. That's the >lowest hanging fruit. Even when you've solved that there's still >10 minutes left - and only 4 of those appear to be down to the >contents file. There is of course the actual time it takes to write >the data to disk - and, being scattered around in small files, >those writes won't be as efficient as the contents file. I think it isn't too difficult to bunzip2 on the server and then gzip then and see how that makes a difference. >So, for this test, of the total 36 minutes the contents file rewrite >is about 20% of the package installation time and 10% of the total >elapsed time. The impact on a DVD install is even less - there it's >even more important to stream the data adequately fast. Ah, but if the content file holds up data reads then speeding it up may have ripple effects. >Even so, the contents file is costing us 4 minutes, and once you >solve the uncompress problem and the SMF import it starts to look >like the next target. But even there it's only going to be 1/3 of >the time at most, and there are a couple of ways to speed things >up: > - re-order package installation to install small packages first > - install clusters rather than individual packages Thanks for your analysis. This is extremely helpful. Casper
