Hi Danek,
On 03/25/09 17:37, Danek Duvall wrote:
> On Wed, Mar 25, 2009 at 02:50:53PM +0100, jan damborsky wrote:
>
>> I have taken a closer look at how long might take to obtain this
>> information for one package. I have tried for package localy installed:
>>
>> # time pkg contents -t file -o pkg.size SUNWcsd | awk 'BEGIN {pkg_sum = 0}
>> {pkg_sum+=$1} END {print pkg_sum}'
>> 24469
>>
>> real 0m3.707s
>> user 0m2.038s
>> sys 0m0.206s
>>
>> And when bigger one has been tried:
>>
>> # time pkg contents -t file -o pkg.size SUNWcs | awk 'BEGIN {pkg_sum = 0}
>> {pkg_sum+=$1} END {print pkg_sum}'
>> 25309681
>>
>> real 0m3.820s
>> user 0m2.192s
>> sys 0m0.195s
>>
>> So it seems that size of package doesn't matter too much, the operation
>> took ~3-4 seconds for one package which would mean >1/2 hour for 600
>> packages if we do this on per package basis.
>
> Why would you do it package by package?
this is a good point - once the package list is generated,
pkg can be called once with that package list provided.
>
> $ ptime pkg contents -t file -o pkg.size $(pkg list -H | nawk '{print
> $1}') > /dev/null
> real 26.080669767
> user 20.504647451
> sys 0.606594932
I have tried to obtain this data remotely in a way installer
would likely do this and it doesn't take 1/2 hour but still
couple of minutes are needed to finish this operation:
# pkg image-create -F -a opensolaris.org=http://ipkg.sfbay/dev /tmp/b
# pkg -R /tmp/b set-authority -m http://ipkg.czech:8000 opensolaris.org
# ptime pkg -R /tmp/b contents -r -t file -o pkg.size $(pkg list -H |
nawk '{print $1}') > /tmp/pkg_list_size_b
real 8:13.384340181
user 29.875434124
sys 0.854146934
Once required metadata are cached on client side, the operation
is faster:
# ptime pkg -R /tmp/b contents -r -t file -o pkg.size $(pkg list -H |
nawk '{print $1}') > /tmp/pkg_list_size_c
real 21.639862980
user 19.629691085
sys 0.426719639
>
> The only thing you're really missing is a way to list all the packages you
> care about. "pkg install" is the only thing that calculates that, but it
> only spits it out when you use -v, and that's not a programmatic interface.
# ptime pkg -R /tmp/b install -nv babel_install > /tmp/pkg_list_babel
real 59.513369690
user 41.077811909
sys 0.514519087
Based on this, it seems that it will take ~10 minutes to obtain information
about size of bits to be installed.
Also, I am a little bit concerned that since there are IPS internals
consumed,
it might be source of incompatibility problems in future when something
changes
there.
Based on this, I am thinking if it might be better approach to encapsulate
the implementation on IPS server side and introduce API to provide
these kind of information to potential consumers.
Then I think we might eliminate the bottleneck between IPS server
and client and make the implementation on AI client side more robust.
From IPS point of view, might it sound as reasonable approach to
try or might it be better to think about other possible solutions ?
Thank you,
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090325/d5e0c0da/attachment.html>
