You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2010/10/01 17:37:04 UTC
Bundle cache changes
Hey everyone,
I've made some changes to the bundle cache layout and handling to
improve performance and clean up code. I've tried to maintain backward
compatibility with old caches, but I'd appreciate is someone could try
it out on their caches to see if it works.
** Back up your caches just in case! **
Note that the new cache format will not work with older frameworks. So
you cannot use a cache created with this new framework with previous
frameworks; however, previously created caches should mostly continue to
work between the two although there will be a loss of fidelity since
changes to state are only saved to the new way or the old way depending
on if you are running on the new framework or the old one.
For the curious, I've combined five bundle cache files (id, location,
state, start level, last modified, and refresh count) into a single file
and try to avoid excessive file accesses. This appears to improve
startup time when you have a cache with lots of bundles, but your
mileage will vary based on platform and other factors. Although, you
won't necessarily see any improvements if you are using an old cache,
since it will revert to the old way.
Thanks.
-> richard
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/11/10 2:36, Valentin Valchev wrote:
> On 1.10.2010 г. 18:37 ч., Richard S. Hall wrote:
>> Hey everyone,
>>
>> I've made some changes to the bundle cache layout and handling to
>> improve performance and clean up code. I've tried to maintain backward
>> compatibility with old caches, but I'd appreciate is someone could try
>> it out on their caches to see if it works.
>>
>> ** Back up your caches just in case! **
>>
>> Note that the new cache format will not work with older frameworks. So
>> you cannot use a cache created with this new framework with previous
>> frameworks; however, previously created caches should mostly continue
>> to work between the two although there will be a loss of fidelity
>> since changes to state are only saved to the new way or the old way
>> depending on if you are running on the new framework or the old one.
>>
>> For the curious, I've combined five bundle cache files (id, location,
>> state, start level, last modified, and refresh count) into a single
>> file and try to avoid excessive file accesses. This appears to improve
>> startup time when you have a cache with lots of bundles, but your
>> mileage will vary based on platform and other factors. Although, you
>> won't necessarily see any improvements if you are using an old cache,
>> since it will revert to the old way.
> Hello,
> Well, maybe it will be even faster if you have only one ... let's say
> "index" file, for all bundles, that contains that internal data. This
> way, at startup you just need to load one index, and then based on it,
> to continue with bundle initialization. Just need to make sure, that
> writing to that index file is atomic and will survive sudden power fail
> or Ctrl+C.
Yeah, I'm not sure I'm willing to give up on having a simple, crash
resistant cache that is easily editable by hand. But that time may come.
-> richard
> Yes, this means when the state of single bundle is changed, then you
> should update the master index. But I'm quite sure that the write
> performance will depend so much on the size of the written file, until
> it is less than the disk block size. As example for NTFS you have
> default cluster size 4096 - big enough for index file.
>
> Regards,
> Valentin
>
>> Thanks.
>>
>> -> richard
>>
>>
>
Re: Bundle cache changes
Posted by Valentin Valchev <v_...@prosyst.bg>.
On 1.10.2010 г. 18:37 ч., Richard S. Hall wrote:
> Hey everyone,
>
> I've made some changes to the bundle cache layout and handling to
> improve performance and clean up code. I've tried to maintain backward
> compatibility with old caches, but I'd appreciate is someone could try
> it out on their caches to see if it works.
>
> ** Back up your caches just in case! **
>
> Note that the new cache format will not work with older frameworks. So
> you cannot use a cache created with this new framework with previous
> frameworks; however, previously created caches should mostly continue
> to work between the two although there will be a loss of fidelity
> since changes to state are only saved to the new way or the old way
> depending on if you are running on the new framework or the old one.
>
> For the curious, I've combined five bundle cache files (id, location,
> state, start level, last modified, and refresh count) into a single
> file and try to avoid excessive file accesses. This appears to improve
> startup time when you have a cache with lots of bundles, but your
> mileage will vary based on platform and other factors. Although, you
> won't necessarily see any improvements if you are using an old cache,
> since it will revert to the old way.
Hello,
Well, maybe it will be even faster if you have only one ... let's say
"index" file, for all bundles, that contains that internal data. This
way, at startup you just need to load one index, and then based on it,
to continue with bundle initialization. Just need to make sure, that
writing to that index file is atomic and will survive sudden power fail
or Ctrl+C.
Yes, this means when the state of single bundle is changed, then you
should update the master index. But I'm quite sure that the write
performance will depend so much on the size of the written file, until
it is less than the disk block size. As example for NTFS you have
default cluster size 4096 - big enough for index file.
Regards,
Valentin
>
> Thanks.
>
> -> richard
>
>
--
-------------------------------------------------
Valentin Valchev · Lead Software Engineer
ProSyst Labs EOOD
1606 Sofia, Bulgaria · 48 Vladajska Str.
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
http://www.prosyst.com · v.valchev@prosyst.bg
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/6/10 1:51 AM, Felix Meschberger wrote:
> Hi
>
> On 05.10.2010 15:13, Richard S. Hall wrote:
>
>> On 10/5/10 2:59, Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> On 04.10.2010 22:26, Richard S. Hall wrote:
>>>
>>>> On 10/4/10 12:31, Pierre De Rop wrote:
>>>>
>>>>> This is surprising, because I double checked (I did the same kind of
>>>>> tests
>>>>> of differents machines), and I always see that loading a populated
>>>>> cache is
>>>>> a bit longer than an empty cache.
>>>>> Ok, it's confusing for now, I will do further investigation and will
>>>>> get
>>>>> back to you later, if I find something.
>>>>>
>>>> Let's keep investigating this.
>>>>
>>>> In the meantime, I decided to rollback the change for the next release
>>>> so we can have more time to investigate it because right now I need to
>>>> get a bug fix out. So, we won't introduce any bundle cache structure
>>>> changes in 3.0.4, but maybe in 3.0.5.
>>>>
>>> This sounds like a minor-release-number-worthy change ;-)
>>>
>> I'm not sure that's necessary. It is still backward compatible, but it
>> isn't forward compatible.
>>
> This means: once you ran the framework with the new bundle cache and
> installed and/or updated bundles you cannot run the existing cache with
> an older version of the framework any longer. Right ?
>
> In this case, IMHO a minor version number increase might provide a hint
> at this situation.
>
I don't think this sort of change is possible to understand from a
version number change. The cache is an odd situation, since it is an
implementation detail, but people depend on it. Either way, we'll
certainly cause confusion for someone.
-> richard
> Regards
> Felix
>
>
>> -> richard
>>
>>
>>> Regards
>>> Felix
>>>
>>>
>>>> -> richard
>>>>
>>>>
>>>>> On Mon, Oct 4, 2010 at 5:05 PM, Richard S.
>>>>> Hall<he...@ungoverned.org>wrote:
>>>>>
>>>>>
>>>>>> On 10/4/10 10:52, Richard S. Hall wrote:
>>>>>>
>>>>>>
>>>>>>> Thanks for the installer bundle, I did some tests locally on my Mac
>>>>>>> using
>>>>>>> 230 bundles from GlassFish, this is what I see (note: the "purge"
>>>>>>> command
>>>>>>> flushes disk buffers):
>>>>>>>
>>>>>>> Empty cache
>>>>>>> -----------------
>>>>>>> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
>>>>>>> bin/felix.jar
>>>>>>> Mon Oct 4 10:43:09 EDT 2010
>>>>>>> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
>>>>>>> FrameworkEvent.STARTED event ...
>>>>>>> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
>>>>>>> ./load dir
>>>>>>> 2010-10-04 10:43:54,464 - Done.
>>>>>>>
>>>>>>> Populated cache
>>>>>>> -----------------------
>>>>>>> [heavyweight main]$ purge; date; java -jar bin/felix.jar
>>>>>>> Mon Oct 4 10:44:49 EDT 2010
>>>>>>> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
>>>>>>> FrameworkEvent.STARTED event ...
>>>>>>> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
>>>>>>> ./load dir
>>>>>>> 2010-10-04 10:45:13,342 - Done.
>>>>>>>
>>>>>>> You can see that the empty cache scenario takes about 45 seconds,
>>>>>>> whereas
>>>>>>> the populated cache takes about 24 seconds. So, on my machine, it
>>>>>>> takes a
>>>>>>> lot less time to re-load cached bundles...could be a function of my
>>>>>>> disk
>>>>>>> speed, I suppose, but it is what I would expect.
>>>>>>>
>>>>>>> Not sure how to proceed, other than trying to get more samples.
>>>>>>>
>>>>>>>
>>>>>> Interestingly, I tried the same test using the 3.0.3 release (the
>>>>>> above was
>>>>>> with trunk) and I got the follow results:
>>>>>>
>>>>>> Empty cache (3.0.3)
>>>>>> -----------------
>>>>>>
>>>>>> rm -rf felix-cache; purge; date; java -jar bin/felix.jar
>>>>>> Mon Oct 4 10:58:23 EDT 2010
>>>>>> 2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 10:58:43,557 - Framework started: Installing bundles from
>>>>>> ./load
>>>>>> dir
>>>>>> 2010-10-04 10:59:03,373 - Done.
>>>>>>
>>>>>> Populated cache (3.0.3)
>>>>>> -----------------------
>>>>>>
>>>>>> purge; date; java -jar bin/felix.jar
>>>>>> Mon Oct 4 10:59:50 EDT 2010
>>>>>> 2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 11:00:26,736 - Framework started: Installing bundles from
>>>>>> ./load
>>>>>> dir
>>>>>> 2010-10-04 11:00:26,738 - Done.
>>>>>>
>>>>>> So, the populated cache takes nearly as long as the empty cache (36
>>>>>> seconds
>>>>>> compared to 40 seconds)...this also makes sense, since the trunk has
>>>>>> patches
>>>>>> specifically designed to improve re-loading cached bundles.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>>>>>
>>>>>>>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<
>>>>>>>>>> pierre.derop@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>>>>>>>
>>>>>>>>>>>> <he...@ungoverned.org>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> One thing, was your performance comparison based on using
>>>>>>>>>>>> the new
>>>>>>>>>>>> cache
>>>>>>>>>>>> or
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> old?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>>>>>>>> snapshot
>>>>>>>>>>>>> and
>>>>>>>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>>>>>>>
>>>>>>>>>>>>> yes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>>>>>>>> but I also checked that new fwk/trunk is properly working when
>>>>>>>>>>>> being
>>>>>>>>>>>> started
>>>>>>>>>>>> with the old cache (from 3.0.2)
>>>>>>>>>>>>
>>>>>>>>>>>> You should also be testing an already created cache (i.e., a
>>>>>>>>>>>> framework
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> restart), not an empty cache.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the previous test, I compared with already created cache,
>>>>>>>>>>>>> not
>>>>>>>>>>>>> with
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> empty
>>>>>>>>>>>>
>>>>>>>>>>> caches.
>>>>>>>>>>>
>>>>>>>>>>>> With empty caches, here are the results:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec.
>>>>>>>>>>>> (this is
>>>>>>>>>>>> surprising:
>>>>>>>>>>>>
>>>>>>>>>>>> I
>>>>>>>>>>>>
>>>>>>>>>>> would expect to get a longer delay, since the cache is
>>>>>>>>>>> empty when
>>>>>>>>>>>
>>>>>>>>>>>> I
>>>>>>>>>>>> start
>>>>>>>>>>>> the fwk)
>>>>>>>>>>>>
>>>>>>>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>>>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>>>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>>>>>>>
>>>>>>>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>>>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>>>>>>>
>>>>>>>>>>>> hmmm, I don't understand why the fwk startup time is better
>>>>>>>>>>>> when the
>>>>>>>>>>>>
>>>>>>>>>>>> cache
>>>>>>>>>>>>
>>>>>>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec
>>>>>>>>>>> from
>>>>>>>>>>>
>>>>>>>>>>>> previous
>>>>>>>>>>>> mail)
>>>>>>>>>>>> Ok, I will do more tests ... may be I did something wrong ? ...
>>>>>>>>>>>> to be
>>>>>>>>>>>> continued ...
>>>>>>>>>>>>
>>>>>>>>>>>> Hmm. Yeah, that seems a little odd. In that case, you should
>>>>>>>>>>>> just
>>>>>>>>>>>>
>>>>>>>>>>> delete
>>>>>>>>>>> your cache each time to get better startup performance! ;-)
>>>>>>>>>>>
>>>>>>>>>>> Definitely let me know what you find out. I too would expect
>>>>>>>>>>> framework
>>>>>>>>>>> restarts to be faster since we don't have to copy the JAR files
>>>>>>>>>>> first.
>>>>>>>>>>>
>>>>>>>>>>> -> richard
>>>>>>>>>>>
>>>>>>>>>>> /pierre
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Is that what you are doing? Just want to make sure I
>>>>>>>>>>>> understand what
>>>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> being measured. :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Richard,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> fwk/trunk)
>>>>>>>>>>>>>>
>>>>>>>>>>>> ->
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> everything works ok
>>>>>>>>>>>>>
>>>>>>>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I also compared the performance of the startup time between
>>>>>>>>>>>>>> felix
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2.0.2
>>>>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> felix trunk.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> To do this, I managed to ensure that my linux IO buffers
>>>>>>>>>>>>>> cache are
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>
>>>>>>>>>>>> before doing each test, by doing this:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> sync
>>>>>>>>>>>>>
>>>>>>>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This ensures that my linux has released all buffer cache
>>>>>>>>>>>>>> disk, like
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> the case when I boot my host (cold start).
>>>>>>>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1
>>>>>>>>>>>>>> *seconds
>>>>>>>>>>>>>> (it's
>>>>>>>>>>>>>> slow
>>>>>>>>>>>>>> because all disk buffers are empty):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>>>>>>>> quicker,
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk
>>>>>>>>>>>>>> buffers
>>>>>>>>>>>>>> before
>>>>>>>>>>>>>> starting the test):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /pierre
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<
>>>>>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> convenience
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've made some changes to the bundle cache layout and
>>>>>>>>>>>>>>> handling to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> improve
>>>>>>>>>>>>>>>> performance and clean up code. I've tried to maintain
>>>>>>>>>>>>>>>> backward
>>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>> with old caches, but I'd appreciate is someone could try it
>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>> caches to see if it works.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>>>>>>>> frameworks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>
>>>>>>>>>>>>> cannot use a cache created with this new framework with
>>>>>>>>>>>>> previous
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> frameworks;
>>>>>>>>>>>>>>>> however, previously created caches should mostly continue
>>>>>>>>>>>>>>>> to work
>>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>> the two although there will be a loss of fidelity since
>>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> only saved to the new way or the old way depending on if
>>>>>>>>>>>>>>>> you are
>>>>>>>>>>>>>>>> running
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> location,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> state, start level, last modified, and refresh count) into a
>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>
>>>>>>>>>>>>> file
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> try to avoid excessive file accesses. This appears to
>>>>>>>>>>>>>>>> improve
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> startup
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>
>>>>>>>>>>>>> when you have a cache with lots of bundles, but your mileage
>>>>>>>>>>>>> will
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> vary
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> based
>>>>>>>>>>>>>>
>>>>>>>>>>>>> on platform and other factors. Although, you won't necessarily
>>>>>>>>>>>>> see
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> improvements if you are using an old cache, since it will
>>>>>>>>>>>>>> revert to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>> way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>
Re: Bundle cache changes
Posted by Felix Meschberger <fm...@gmail.com>.
Hi
On 05.10.2010 15:13, Richard S. Hall wrote:
> On 10/5/10 2:59, Felix Meschberger wrote:
>> Hi,
>>
>> On 04.10.2010 22:26, Richard S. Hall wrote:
>>> On 10/4/10 12:31, Pierre De Rop wrote:
>>>> This is surprising, because I double checked (I did the same kind of
>>>> tests
>>>> of differents machines), and I always see that loading a populated
>>>> cache is
>>>> a bit longer than an empty cache.
>>>> Ok, it's confusing for now, I will do further investigation and will
>>>> get
>>>> back to you later, if I find something.
>>> Let's keep investigating this.
>>>
>>> In the meantime, I decided to rollback the change for the next release
>>> so we can have more time to investigate it because right now I need to
>>> get a bug fix out. So, we won't introduce any bundle cache structure
>>> changes in 3.0.4, but maybe in 3.0.5.
>> This sounds like a minor-release-number-worthy change ;-)
>
> I'm not sure that's necessary. It is still backward compatible, but it
> isn't forward compatible.
This means: once you ran the framework with the new bundle cache and
installed and/or updated bundles you cannot run the existing cache with
an older version of the framework any longer. Right ?
In this case, IMHO a minor version number increase might provide a hint
at this situation.
Regards
Felix
>
> -> richard
>
>> Regards
>> Felix
>>
>>> -> richard
>>>
>>>> On Mon, Oct 4, 2010 at 5:05 PM, Richard S.
>>>> Hall<he...@ungoverned.org>wrote:
>>>>
>>>>> On 10/4/10 10:52, Richard S. Hall wrote:
>>>>>
>>>>>> Thanks for the installer bundle, I did some tests locally on my Mac
>>>>>> using
>>>>>> 230 bundles from GlassFish, this is what I see (note: the "purge"
>>>>>> command
>>>>>> flushes disk buffers):
>>>>>>
>>>>>> Empty cache
>>>>>> -----------------
>>>>>> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
>>>>>> bin/felix.jar
>>>>>> Mon Oct 4 10:43:09 EDT 2010
>>>>>> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
>>>>>> ./load dir
>>>>>> 2010-10-04 10:43:54,464 - Done.
>>>>>>
>>>>>> Populated cache
>>>>>> -----------------------
>>>>>> [heavyweight main]$ purge; date; java -jar bin/felix.jar
>>>>>> Mon Oct 4 10:44:49 EDT 2010
>>>>>> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
>>>>>> ./load dir
>>>>>> 2010-10-04 10:45:13,342 - Done.
>>>>>>
>>>>>> You can see that the empty cache scenario takes about 45 seconds,
>>>>>> whereas
>>>>>> the populated cache takes about 24 seconds. So, on my machine, it
>>>>>> takes a
>>>>>> lot less time to re-load cached bundles...could be a function of my
>>>>>> disk
>>>>>> speed, I suppose, but it is what I would expect.
>>>>>>
>>>>>> Not sure how to proceed, other than trying to get more samples.
>>>>>>
>>>>> Interestingly, I tried the same test using the 3.0.3 release (the
>>>>> above was
>>>>> with trunk) and I got the follow results:
>>>>>
>>>>> Empty cache (3.0.3)
>>>>> -----------------
>>>>>
>>>>> rm -rf felix-cache; purge; date; java -jar bin/felix.jar
>>>>> Mon Oct 4 10:58:23 EDT 2010
>>>>> 2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
>>>>> FrameworkEvent.STARTED event ...
>>>>> 2010-10-04 10:58:43,557 - Framework started: Installing bundles from
>>>>> ./load
>>>>> dir
>>>>> 2010-10-04 10:59:03,373 - Done.
>>>>>
>>>>> Populated cache (3.0.3)
>>>>> -----------------------
>>>>>
>>>>> purge; date; java -jar bin/felix.jar
>>>>> Mon Oct 4 10:59:50 EDT 2010
>>>>> 2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
>>>>> FrameworkEvent.STARTED event ...
>>>>> 2010-10-04 11:00:26,736 - Framework started: Installing bundles from
>>>>> ./load
>>>>> dir
>>>>> 2010-10-04 11:00:26,738 - Done.
>>>>>
>>>>> So, the populated cache takes nearly as long as the empty cache (36
>>>>> seconds
>>>>> compared to 40 seconds)...this also makes sense, since the trunk has
>>>>> patches
>>>>> specifically designed to improve re-loading cached bundles.
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>
>>>>>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>>>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<
>>>>>>>>> pierre.derop@gmail.com>
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>>>>>>> <he...@ungoverned.org>wrote:
>>>>>>>>>>>
>>>>>>>>>>> One thing, was your performance comparison based on using
>>>>>>>>>>> the new
>>>>>>>>>>> cache
>>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>>> old?
>>>>>>>>>>>>
>>>>>>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>>>>>>> snapshot
>>>>>>>>>>>> and
>>>>>>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>>>>>>
>>>>>>>>>>>> yes:
>>>>>>>>>>>>
>>>>>>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>>>>>>> but I also checked that new fwk/trunk is properly working when
>>>>>>>>>>> being
>>>>>>>>>>> started
>>>>>>>>>>> with the old cache (from 3.0.2)
>>>>>>>>>>>
>>>>>>>>>>> You should also be testing an already created cache (i.e., a
>>>>>>>>>>> framework
>>>>>>>>>>>
>>>>>>>>>>>> restart), not an empty cache.
>>>>>>>>>>>>
>>>>>>>>>>>> In the previous test, I compared with already created cache,
>>>>>>>>>>>> not
>>>>>>>>>>>> with
>>>>>>>>>>>>
>>>>>>>>>>> empty
>>>>>>>>>> caches.
>>>>>>>>>>> With empty caches, here are the results:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec.
>>>>>>>>>>> (this is
>>>>>>>>>>> surprising:
>>>>>>>>>>>
>>>>>>>>>>> I
>>>>>>>>>> would expect to get a longer delay, since the cache is
>>>>>>>>>> empty when
>>>>>>>>>>> I
>>>>>>>>>>> start
>>>>>>>>>>> the fwk)
>>>>>>>>>>>
>>>>>>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>>>>>>
>>>>>>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>>>>>>
>>>>>>>>>>> hmmm, I don't understand why the fwk startup time is better
>>>>>>>>>>> when the
>>>>>>>>>>>
>>>>>>>>>>> cache
>>>>>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec
>>>>>>>>>> from
>>>>>>>>>>> previous
>>>>>>>>>>> mail)
>>>>>>>>>>> Ok, I will do more tests ... may be I did something wrong ? ...
>>>>>>>>>>> to be
>>>>>>>>>>> continued ...
>>>>>>>>>>>
>>>>>>>>>>> Hmm. Yeah, that seems a little odd. In that case, you should
>>>>>>>>>>> just
>>>>>>>>>> delete
>>>>>>>>>> your cache each time to get better startup performance! ;-)
>>>>>>>>>>
>>>>>>>>>> Definitely let me know what you find out. I too would expect
>>>>>>>>>> framework
>>>>>>>>>> restarts to be faster since we don't have to copy the JAR files
>>>>>>>>>> first.
>>>>>>>>>>
>>>>>>>>>> -> richard
>>>>>>>>>>
>>>>>>>>>> /pierre
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is that what you are doing? Just want to make sure I
>>>>>>>>>>> understand what
>>>>>>>>>>> is
>>>>>>>>>>>
>>>>>>>>>>>> being measured. :-)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -> richard
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Richard,
>>>>>>>>>>>>
>>>>>>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>>>>>>
>>>>>>>>>>>>> fwk/trunk)
>>>>>>>>>>> ->
>>>>>>>>>>>
>>>>>>>>>>>> everything works ok
>>>>>>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>>>>>>
>>>>>>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I also compared the performance of the startup time between
>>>>>>>>>>>>> felix
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.0.2
>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>>> felix trunk.
>>>>>>>>>>>>> To do this, I managed to ensure that my linux IO buffers
>>>>>>>>>>>>> cache are
>>>>>>>>>>>>>
>>>>>>>>>>>>> empty
>>>>>>>>>>> before doing each test, by doing this:
>>>>>>>>>>>
>>>>>>>>>>>> sync
>>>>>>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>
>>>>>>>>>>>>> This ensures that my linux has released all buffer cache
>>>>>>>>>>>>> disk, like
>>>>>>>>>>>>> it
>>>>>>>>>>>>> is
>>>>>>>>>>>>> the case when I boot my host (cold start).
>>>>>>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1
>>>>>>>>>>>>> *seconds
>>>>>>>>>>>>> (it's
>>>>>>>>>>>>> slow
>>>>>>>>>>>>> because all disk buffers are empty):
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>>>>>>
>>>>>>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>>>>>>> quicker,
>>>>>>>>>>>>> but
>>>>>>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk
>>>>>>>>>>>>> buffers
>>>>>>>>>>>>> before
>>>>>>>>>>>>> starting the test):
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> /pierre
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<
>>>>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>>>>>>> convenience
>>>>>>>>>>>>>
>>>>>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've made some changes to the bundle cache layout and
>>>>>>>>>>>>>> handling to
>>>>>>>>>>>>>>> improve
>>>>>>>>>>>>>>> performance and clean up code. I've tried to maintain
>>>>>>>>>>>>>>> backward
>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>> with old caches, but I'd appreciate is someone could try it
>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>> caches to see if it works.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>>>>>>> frameworks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So
>>>>>>>>>>>>> you
>>>>>>>>>>>> cannot use a cache created with this new framework with
>>>>>>>>>>>> previous
>>>>>>>>>>>>>>> frameworks;
>>>>>>>>>>>>>>> however, previously created caches should mostly continue
>>>>>>>>>>>>>>> to work
>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>> the two although there will be a loss of fidelity since
>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> only saved to the new way or the old way depending on if
>>>>>>>>>>>>>>> you are
>>>>>>>>>>>>>>> running
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> location,
>>>>>>>>>>>>> state, start level, last modified, and refresh count) into a
>>>>>>>>>>>>> single
>>>>>>>>>>>> file
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> try to avoid excessive file accesses. This appears to
>>>>>>>>>>>>>>> improve
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> startup
>>>>>>>>>>>>> time
>>>>>>>>>>>> when you have a cache with lots of bundles, but your mileage
>>>>>>>>>>>> will
>>>>>>>>>>>>>>> vary
>>>>>>>>>>>>> based
>>>>>>>>>>>> on platform and other factors. Although, you won't necessarily
>>>>>>>>>>>> see
>>>>>>>>>>>>>>> any
>>>>>>>>>>>>> improvements if you are using an old cache, since it will
>>>>>>>>>>>>> revert to
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>> way.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Thanks for the feedback.
Just so you know you aren't crazy, I tested it on my EEE PC and I am
seeing similar results as you. It is taking around 18 seconds with an
empty cache and about 23 seconds with a populated cache.
In the end, though, the patch does show improvement over the non-patched
version, so it is probably still worthwhile...but very counter intuitive.
-> richard
On 10/5/10 12:21, Pierre De Rop wrote:
> Hello Richard,
>
> I progress on my testing, and I understand now why I did not get the same
> results than you ...
> I did two tests: one test on a machine with a relatively slow disk, and
> another test on a
> host whose disk is faster.
>
> I did the test with the 213 bundles from glassfish 3.0.1
> (glassfishv3/glassfish/modules/*.jar)
>
> Test on the host with the slow disk:
> ========================
>
> I first measured the time needed to open a single file when disk buffers are
> flushed: 32 millis.
> (I did this to check that the disk io speed).
>
> Here are the results of the tests:
>
> * with felix 3.0.3 ->
> time to load an empty felix cache (with disk buffers flushed) = 9.2 millis
> time to load an existing felix cache (with dsk buffers flushed) = 14.9
> millis
>
> * with felix trunk (optimized version that you uncommitted yesterday) ->
> time to load an empty felix cache (with disk buffers flushed) = 9.1 millis
> time to load an existing felix cache (with dsk buffers flushed) = 12.3
> millis
>
> (here, we notice that it takes a longer time to load an existing felix
> cache, than an empty one, either with felix 3.0.3 or optimized felix trunk).
>
> Test on the host with the faster disk:
> ==========================
>
> Time needed to open a single file when disk buffers are flushed: 1 millis.
>
> * with felix 3.0.3 ->
> time to load an empty felix cache (with disk buffers flushed) = 8.1 millis
> time to load an existing felix cache (with dsk buffers flushed) = 5.3 millis
>
> * with felix trunk (optimized version that you recently uncommited) ->
> time to load an empty felix cache (with disk buffers flushed) = 7.9 millis
> time to load an existing felix cache (with dsk buffers flushed) = 4.7 millis
>
> (here, loading an existing felix cache is faster then an empty felix cache,
> as expected).
>
> So, in any cases, the optimized version of the trunk is faster than the
> 2.0.3.
> However, with a low disk IO rate, then it seems that it takes a longer time
> to load an existing felix cache
> than an empty one.
>
>
> /pierre
>
>
>
>
> On Tue, Oct 5, 2010 at 3:13 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> On 10/5/10 2:59, Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> On 04.10.2010 22:26, Richard S. Hall wrote:
>>>
>>>> On 10/4/10 12:31, Pierre De Rop wrote:
>>>>
>>>>> This is surprising, because I double checked (I did the same kind of
>>>>> tests
>>>>> of differents machines), and I always see that loading a populated
>>>>> cache is
>>>>> a bit longer than an empty cache.
>>>>> Ok, it's confusing for now, I will do further investigation and will get
>>>>> back to you later, if I find something.
>>>>>
>>>> Let's keep investigating this.
>>>>
>>>> In the meantime, I decided to rollback the change for the next release
>>>> so we can have more time to investigate it because right now I need to
>>>> get a bug fix out. So, we won't introduce any bundle cache structure
>>>> changes in 3.0.4, but maybe in 3.0.5.
>>>>
>>> This sounds like a minor-release-number-worthy change ;-)
>>>
>> I'm not sure that's necessary. It is still backward compatible, but it
>> isn't forward compatible.
>>
>> -> richard
>>
>>
>> Regards
>>> Felix
>>>
>>> -> richard
>>>> On Mon, Oct 4, 2010 at 5:05 PM, Richard S.
>>>>> Hall<he...@ungoverned.org>wrote:
>>>>>
>>>>> On 10/4/10 10:52, Richard S. Hall wrote:
>>>>>> Thanks for the installer bundle, I did some tests locally on my Mac
>>>>>>> using
>>>>>>> 230 bundles from GlassFish, this is what I see (note: the "purge"
>>>>>>> command
>>>>>>> flushes disk buffers):
>>>>>>>
>>>>>>> Empty cache
>>>>>>> -----------------
>>>>>>> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
>>>>>>> bin/felix.jar
>>>>>>> Mon Oct 4 10:43:09 EDT 2010
>>>>>>> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
>>>>>>> FrameworkEvent.STARTED event ...
>>>>>>> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
>>>>>>> ./load dir
>>>>>>> 2010-10-04 10:43:54,464 - Done.
>>>>>>>
>>>>>>> Populated cache
>>>>>>> -----------------------
>>>>>>> [heavyweight main]$ purge; date; java -jar bin/felix.jar
>>>>>>> Mon Oct 4 10:44:49 EDT 2010
>>>>>>> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
>>>>>>> FrameworkEvent.STARTED event ...
>>>>>>> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
>>>>>>> ./load dir
>>>>>>> 2010-10-04 10:45:13,342 - Done.
>>>>>>>
>>>>>>> You can see that the empty cache scenario takes about 45 seconds,
>>>>>>> whereas
>>>>>>> the populated cache takes about 24 seconds. So, on my machine, it
>>>>>>> takes a
>>>>>>> lot less time to re-load cached bundles...could be a function of my
>>>>>>> disk
>>>>>>> speed, I suppose, but it is what I would expect.
>>>>>>>
>>>>>>> Not sure how to proceed, other than trying to get more samples.
>>>>>>>
>>>>>>> Interestingly, I tried the same test using the 3.0.3 release (the
>>>>>> above was
>>>>>> with trunk) and I got the follow results:
>>>>>>
>>>>>> Empty cache (3.0.3)
>>>>>> -----------------
>>>>>>
>>>>>> rm -rf felix-cache; purge; date; java -jar bin/felix.jar
>>>>>> Mon Oct 4 10:58:23 EDT 2010
>>>>>> 2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 10:58:43,557 - Framework started: Installing bundles from
>>>>>> ./load
>>>>>> dir
>>>>>> 2010-10-04 10:59:03,373 - Done.
>>>>>>
>>>>>> Populated cache (3.0.3)
>>>>>> -----------------------
>>>>>>
>>>>>> purge; date; java -jar bin/felix.jar
>>>>>> Mon Oct 4 10:59:50 EDT 2010
>>>>>> 2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 11:00:26,736 - Framework started: Installing bundles from
>>>>>> ./load
>>>>>> dir
>>>>>> 2010-10-04 11:00:26,738 - Done.
>>>>>>
>>>>>> So, the populated cache takes nearly as long as the empty cache (36
>>>>>> seconds
>>>>>> compared to 40 seconds)...this also makes sense, since the trunk has
>>>>>> patches
>>>>>> specifically designed to improve re-loading cached bundles.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>>>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<
>>>>>>>>>> pierre.derop@gmail.com>
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>>>>>>>
>>>>>>>>>>>> <he...@ungoverned.org>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> One thing, was your performance comparison based on using
>>>>>>>>>>>> the new
>>>>>>>>>>>> cache
>>>>>>>>>>>> or
>>>>>>>>>>>>
>>>>>>>>>>>> old?
>>>>>>>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>>>>>>>> snapshot
>>>>>>>>>>>>> and
>>>>>>>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>>>>>>>
>>>>>>>>>>>>> yes:
>>>>>>>>>>>>>
>>>>>>>>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>>>>>>>> but I also checked that new fwk/trunk is properly working when
>>>>>>>>>>>> being
>>>>>>>>>>>> started
>>>>>>>>>>>> with the old cache (from 3.0.2)
>>>>>>>>>>>>
>>>>>>>>>>>> You should also be testing an already created cache (i.e., a
>>>>>>>>>>>> framework
>>>>>>>>>>>>
>>>>>>>>>>>> restart), not an empty cache.
>>>>>>>>>>>>> In the previous test, I compared with already created cache,
>>>>>>>>>>>>> not
>>>>>>>>>>>>> with
>>>>>>>>>>>>>
>>>>>>>>>>>>> empty
>>>>>>>>>>> caches.
>>>>>>>>>>>
>>>>>>>>>>>> With empty caches, here are the results:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is
>>>>>>>>>>>> surprising:
>>>>>>>>>>>>
>>>>>>>>>>>> I
>>>>>>>>>>>>
>>>>>>>>>>> would expect to get a longer delay, since the cache is
>>>>>>>>>>> empty when
>>>>>>>>>>>
>>>>>>>>>>>> I
>>>>>>>>>>>> start
>>>>>>>>>>>> the fwk)
>>>>>>>>>>>>
>>>>>>>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>>>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>>>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>>>>>>>
>>>>>>>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>>>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>>>>>>>
>>>>>>>>>>>> hmmm, I don't understand why the fwk startup time is better
>>>>>>>>>>>> when the
>>>>>>>>>>>>
>>>>>>>>>>>> cache
>>>>>>>>>>>>
>>>>>>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec
>>>>>>>>>>> from
>>>>>>>>>>>
>>>>>>>>>>>> previous
>>>>>>>>>>>> mail)
>>>>>>>>>>>> Ok, I will do more tests ... may be I did something wrong ? ...
>>>>>>>>>>>> to be
>>>>>>>>>>>> continued ...
>>>>>>>>>>>>
>>>>>>>>>>>> Hmm. Yeah, that seems a little odd. In that case, you should
>>>>>>>>>>>> just
>>>>>>>>>>>>
>>>>>>>>>>> delete
>>>>>>>>>>> your cache each time to get better startup performance! ;-)
>>>>>>>>>>>
>>>>>>>>>>> Definitely let me know what you find out. I too would expect
>>>>>>>>>>> framework
>>>>>>>>>>> restarts to be faster since we don't have to copy the JAR files
>>>>>>>>>>> first.
>>>>>>>>>>>
>>>>>>>>>>> -> richard
>>>>>>>>>>>
>>>>>>>>>>> /pierre
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Is that what you are doing? Just want to make sure I
>>>>>>>>>>>> understand what
>>>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>> being measured. :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Richard,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>>>>>>> fwk/trunk)
>>>>>>>>>>>>>>
>>>>>>>>>>>>> ->
>>>>>>>>>>>> everything works ok
>>>>>>>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I also compared the performance of the startup time between
>>>>>>>>>>>>>> felix
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2.0.2
>>>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>>> felix trunk.
>>>>>>>>>>>>>> To do this, I managed to ensure that my linux IO buffers
>>>>>>>>>>>>>> cache are
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>
>>>>>>>>>>>>> before doing each test, by doing this:
>>>>>>>>>>>> sync
>>>>>>>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This ensures that my linux has released all buffer cache
>>>>>>>>>>>>>> disk, like
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> the case when I boot my host (cold start).
>>>>>>>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds
>>>>>>>>>>>>>> (it's
>>>>>>>>>>>>>> slow
>>>>>>>>>>>>>> because all disk buffers are empty):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>>>>>>>> quicker,
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk
>>>>>>>>>>>>>> buffers
>>>>>>>>>>>>>> before
>>>>>>>>>>>>>> starting the test):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /pierre
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<
>>>>>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> convenience
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've made some changes to the bundle cache layout and
>>>>>>>>>>>>>>> handling to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> improve
>>>>>>>>>>>>>>>> performance and clean up code. I've tried to maintain
>>>>>>>>>>>>>>>> backward
>>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>> with old caches, but I'd appreciate is someone could try it
>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>> caches to see if it works.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>>>>>>>> frameworks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>>>>>>>>
>>>>>>>>>>>>>> frameworks;
>>>>>>>>>>>>>>>> however, previously created caches should mostly continue
>>>>>>>>>>>>>>>> to work
>>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>> the two although there will be a loss of fidelity since
>>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> only saved to the new way or the old way depending on if
>>>>>>>>>>>>>>>> you are
>>>>>>>>>>>>>>>> running
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> location,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> state, start level, last modified, and refresh count) into a
>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>
>>>>>>>>>>>>> file
>>>>>>>>>>>>>
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> try to avoid excessive file accesses. This appears to improve
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> startup
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> time
>>>>>>>>>>>>> when you have a cache with lots of bundles, but your mileage
>>>>>>>>>>>>> will
>>>>>>>>>>>>>
>>>>>>>>>>>>>> vary
>>>>>>>>>>>>>>> based
>>>>>>>>>>>>> on platform and other factors. Although, you won't necessarily
>>>>>>>>>>>>> see
>>>>>>>>>>>>>
>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>> improvements if you are using an old cache, since it will
>>>>>>>>>>>>>> revert to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>> way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
Re: Bundle cache changes
Posted by Pierre De Rop <pi...@gmail.com>.
(the results in the above post are in seconds, not in millis ...)
On Tue, Oct 5, 2010 at 6:21 PM, Pierre De Rop <pi...@gmail.com>wrote:
> Hello Richard,
>
> I progress on my testing, and I understand now why I did not get the same
> results than you ...
> I did two tests: one test on a machine with a relatively slow disk, and
> another test on a
> host whose disk is faster.
>
> I did the test with the 213 bundles from glassfish 3.0.1
> (glassfishv3/glassfish/modules/*.jar)
>
> Test on the host with the slow disk:
> ========================
>
> I first measured the time needed to open a single file when disk buffers
> are flushed: 32 millis.
> (I did this to check that the disk io speed).
>
> Here are the results of the tests:
>
> * with felix 3.0.3 ->
> time to load an empty felix cache (with disk buffers flushed) = 9.2 millis
> time to load an existing felix cache (with dsk buffers flushed) = 14.9
> millis
>
> * with felix trunk (optimized version that you uncommitted yesterday) ->
> time to load an empty felix cache (with disk buffers flushed) = 9.1 millis
> time to load an existing felix cache (with dsk buffers flushed) = 12.3
> millis
>
> (here, we notice that it takes a longer time to load an existing felix
> cache, than an empty one, either with felix 3.0.3 or optimized felix trunk).
>
> Test on the host with the faster disk:
> ==========================
>
> Time needed to open a single file when disk buffers are flushed: 1 millis.
>
> * with felix 3.0.3 ->
> time to load an empty felix cache (with disk buffers flushed) = 8.1 millis
> time to load an existing felix cache (with dsk buffers flushed) = 5.3
> millis
>
> * with felix trunk (optimized version that you recently uncommited) ->
> time to load an empty felix cache (with disk buffers flushed) = 7.9 millis
> time to load an existing felix cache (with dsk buffers flushed) = 4.7
> millis
>
> (here, loading an existing felix cache is faster then an empty felix cache,
> as expected).
>
> So, in any cases, the optimized version of the trunk is faster than the
> 2.0.3.
> However, with a low disk IO rate, then it seems that it takes a longer time
> to load an existing felix cache
> than an empty one.
>
>
> /pierre
>
>
>
>
>
> On Tue, Oct 5, 2010 at 3:13 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> On 10/5/10 2:59, Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> On 04.10.2010 22:26, Richard S. Hall wrote:
>>>
>>>> On 10/4/10 12:31, Pierre De Rop wrote:
>>>>
>>>>> This is surprising, because I double checked (I did the same kind of
>>>>> tests
>>>>> of differents machines), and I always see that loading a populated
>>>>> cache is
>>>>> a bit longer than an empty cache.
>>>>> Ok, it's confusing for now, I will do further investigation and will
>>>>> get
>>>>> back to you later, if I find something.
>>>>>
>>>> Let's keep investigating this.
>>>>
>>>> In the meantime, I decided to rollback the change for the next release
>>>> so we can have more time to investigate it because right now I need to
>>>> get a bug fix out. So, we won't introduce any bundle cache structure
>>>> changes in 3.0.4, but maybe in 3.0.5.
>>>>
>>> This sounds like a minor-release-number-worthy change ;-)
>>>
>>
>> I'm not sure that's necessary. It is still backward compatible, but it
>> isn't forward compatible.
>>
>> -> richard
>>
>>
>> Regards
>>> Felix
>>>
>>> -> richard
>>>>
>>>> On Mon, Oct 4, 2010 at 5:05 PM, Richard S.
>>>>> Hall<he...@ungoverned.org>wrote:
>>>>>
>>>>> On 10/4/10 10:52, Richard S. Hall wrote:
>>>>>>
>>>>>> Thanks for the installer bundle, I did some tests locally on my Mac
>>>>>>> using
>>>>>>> 230 bundles from GlassFish, this is what I see (note: the "purge"
>>>>>>> command
>>>>>>> flushes disk buffers):
>>>>>>>
>>>>>>> Empty cache
>>>>>>> -----------------
>>>>>>> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
>>>>>>> bin/felix.jar
>>>>>>> Mon Oct 4 10:43:09 EDT 2010
>>>>>>> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
>>>>>>> FrameworkEvent.STARTED event ...
>>>>>>> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
>>>>>>> ./load dir
>>>>>>> 2010-10-04 10:43:54,464 - Done.
>>>>>>>
>>>>>>> Populated cache
>>>>>>> -----------------------
>>>>>>> [heavyweight main]$ purge; date; java -jar bin/felix.jar
>>>>>>> Mon Oct 4 10:44:49 EDT 2010
>>>>>>> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
>>>>>>> FrameworkEvent.STARTED event ...
>>>>>>> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
>>>>>>> ./load dir
>>>>>>> 2010-10-04 10:45:13,342 - Done.
>>>>>>>
>>>>>>> You can see that the empty cache scenario takes about 45 seconds,
>>>>>>> whereas
>>>>>>> the populated cache takes about 24 seconds. So, on my machine, it
>>>>>>> takes a
>>>>>>> lot less time to re-load cached bundles...could be a function of my
>>>>>>> disk
>>>>>>> speed, I suppose, but it is what I would expect.
>>>>>>>
>>>>>>> Not sure how to proceed, other than trying to get more samples.
>>>>>>>
>>>>>>> Interestingly, I tried the same test using the 3.0.3 release (the
>>>>>> above was
>>>>>> with trunk) and I got the follow results:
>>>>>>
>>>>>> Empty cache (3.0.3)
>>>>>> -----------------
>>>>>>
>>>>>> rm -rf felix-cache; purge; date; java -jar bin/felix.jar
>>>>>> Mon Oct 4 10:58:23 EDT 2010
>>>>>> 2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 10:58:43,557 - Framework started: Installing bundles from
>>>>>> ./load
>>>>>> dir
>>>>>> 2010-10-04 10:59:03,373 - Done.
>>>>>>
>>>>>> Populated cache (3.0.3)
>>>>>> -----------------------
>>>>>>
>>>>>> purge; date; java -jar bin/felix.jar
>>>>>> Mon Oct 4 10:59:50 EDT 2010
>>>>>> 2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 11:00:26,736 - Framework started: Installing bundles from
>>>>>> ./load
>>>>>> dir
>>>>>> 2010-10-04 11:00:26,738 - Done.
>>>>>>
>>>>>> So, the populated cache takes nearly as long as the empty cache (36
>>>>>> seconds
>>>>>> compared to 40 seconds)...this also makes sense, since the trunk has
>>>>>> patches
>>>>>> specifically designed to improve re-loading cached bundles.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>>>>>
>>>>>>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<
>>>>>>>>>> pierre.derop@gmail.com>
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>>>>>>>
>>>>>>>>>>>> <he...@ungoverned.org>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> One thing, was your performance comparison based on using
>>>>>>>>>>>> the new
>>>>>>>>>>>> cache
>>>>>>>>>>>> or
>>>>>>>>>>>>
>>>>>>>>>>>> old?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>>>>>>>> snapshot
>>>>>>>>>>>>> and
>>>>>>>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>>>>>>>
>>>>>>>>>>>>> yes:
>>>>>>>>>>>>>
>>>>>>>>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>>>>>>>> but I also checked that new fwk/trunk is properly working when
>>>>>>>>>>>> being
>>>>>>>>>>>> started
>>>>>>>>>>>> with the old cache (from 3.0.2)
>>>>>>>>>>>>
>>>>>>>>>>>> You should also be testing an already created cache (i.e., a
>>>>>>>>>>>> framework
>>>>>>>>>>>>
>>>>>>>>>>>> restart), not an empty cache.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the previous test, I compared with already created cache,
>>>>>>>>>>>>> not
>>>>>>>>>>>>> with
>>>>>>>>>>>>>
>>>>>>>>>>>>> empty
>>>>>>>>>>>>
>>>>>>>>>>> caches.
>>>>>>>>>>>
>>>>>>>>>>>> With empty caches, here are the results:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this
>>>>>>>>>>>> is
>>>>>>>>>>>> surprising:
>>>>>>>>>>>>
>>>>>>>>>>>> I
>>>>>>>>>>>>
>>>>>>>>>>> would expect to get a longer delay, since the cache is
>>>>>>>>>>> empty when
>>>>>>>>>>>
>>>>>>>>>>>> I
>>>>>>>>>>>> start
>>>>>>>>>>>> the fwk)
>>>>>>>>>>>>
>>>>>>>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>>>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>>>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>>>>>>>
>>>>>>>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>>>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>>>>>>>
>>>>>>>>>>>> hmmm, I don't understand why the fwk startup time is better
>>>>>>>>>>>> when the
>>>>>>>>>>>>
>>>>>>>>>>>> cache
>>>>>>>>>>>>
>>>>>>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec
>>>>>>>>>>> from
>>>>>>>>>>>
>>>>>>>>>>>> previous
>>>>>>>>>>>> mail)
>>>>>>>>>>>> Ok, I will do more tests ... may be I did something wrong ? ...
>>>>>>>>>>>> to be
>>>>>>>>>>>> continued ...
>>>>>>>>>>>>
>>>>>>>>>>>> Hmm. Yeah, that seems a little odd. In that case, you should
>>>>>>>>>>>> just
>>>>>>>>>>>>
>>>>>>>>>>> delete
>>>>>>>>>>> your cache each time to get better startup performance! ;-)
>>>>>>>>>>>
>>>>>>>>>>> Definitely let me know what you find out. I too would expect
>>>>>>>>>>> framework
>>>>>>>>>>> restarts to be faster since we don't have to copy the JAR files
>>>>>>>>>>> first.
>>>>>>>>>>>
>>>>>>>>>>> -> richard
>>>>>>>>>>>
>>>>>>>>>>> /pierre
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Is that what you are doing? Just want to make sure I
>>>>>>>>>>>> understand what
>>>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>> being measured. :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Richard,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> fwk/trunk)
>>>>>>>>>>>>>>
>>>>>>>>>>>>> ->
>>>>>>>>>>>>
>>>>>>>>>>>> everything works ok
>>>>>>>>>>>>>
>>>>>>>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I also compared the performance of the startup time between
>>>>>>>>>>>>>> felix
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2.0.2
>>>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>>>
>>>>>>>>>>>> felix trunk.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> To do this, I managed to ensure that my linux IO buffers
>>>>>>>>>>>>>> cache are
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>
>>>>>>>>>>>>> before doing each test, by doing this:
>>>>>>>>>>>>
>>>>>>>>>>>> sync
>>>>>>>>>>>>>
>>>>>>>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This ensures that my linux has released all buffer cache
>>>>>>>>>>>>>> disk, like
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> the case when I boot my host (cold start).
>>>>>>>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1
>>>>>>>>>>>>>> *seconds
>>>>>>>>>>>>>> (it's
>>>>>>>>>>>>>> slow
>>>>>>>>>>>>>> because all disk buffers are empty):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>>>>>>>> quicker,
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk
>>>>>>>>>>>>>> buffers
>>>>>>>>>>>>>> before
>>>>>>>>>>>>>> starting the test):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /pierre
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<
>>>>>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> convenience
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've made some changes to the bundle cache layout and
>>>>>>>>>>>>>>> handling to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> improve
>>>>>>>>>>>>>>>> performance and clean up code. I've tried to maintain
>>>>>>>>>>>>>>>> backward
>>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>> with old caches, but I'd appreciate is someone could try it
>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>> caches to see if it works.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>>>>>>>> frameworks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>
>>>>>>>>>>>>> cannot use a cache created with this new framework with
>>>>>>>>>>>>> previous
>>>>>>>>>>>>>
>>>>>>>>>>>>>> frameworks;
>>>>>>>>>>>>>>>> however, previously created caches should mostly continue
>>>>>>>>>>>>>>>> to work
>>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>> the two although there will be a loss of fidelity since
>>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> only saved to the new way or the old way depending on if
>>>>>>>>>>>>>>>> you are
>>>>>>>>>>>>>>>> running
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> location,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> state, start level, last modified, and refresh count) into a
>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>
>>>>>>>>>>>>> file
>>>>>>>>>>>>>
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> try to avoid excessive file accesses. This appears to
>>>>>>>>>>>>>>>> improve
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> startup
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>
>>>>>>>>>>>>> when you have a cache with lots of bundles, but your mileage
>>>>>>>>>>>>> will
>>>>>>>>>>>>>
>>>>>>>>>>>>>> vary
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> based
>>>>>>>>>>>>>>
>>>>>>>>>>>>> on platform and other factors. Although, you won't necessarily
>>>>>>>>>>>>> see
>>>>>>>>>>>>>
>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> improvements if you are using an old cache, since it will
>>>>>>>>>>>>>> revert to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>> way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>
Re: Bundle cache changes
Posted by Pierre De Rop <pi...@gmail.com>.
Hello Richard,
I progress on my testing, and I understand now why I did not get the same
results than you ...
I did two tests: one test on a machine with a relatively slow disk, and
another test on a
host whose disk is faster.
I did the test with the 213 bundles from glassfish 3.0.1
(glassfishv3/glassfish/modules/*.jar)
Test on the host with the slow disk:
========================
I first measured the time needed to open a single file when disk buffers are
flushed: 32 millis.
(I did this to check that the disk io speed).
Here are the results of the tests:
* with felix 3.0.3 ->
time to load an empty felix cache (with disk buffers flushed) = 9.2 millis
time to load an existing felix cache (with dsk buffers flushed) = 14.9
millis
* with felix trunk (optimized version that you uncommitted yesterday) ->
time to load an empty felix cache (with disk buffers flushed) = 9.1 millis
time to load an existing felix cache (with dsk buffers flushed) = 12.3
millis
(here, we notice that it takes a longer time to load an existing felix
cache, than an empty one, either with felix 3.0.3 or optimized felix trunk).
Test on the host with the faster disk:
==========================
Time needed to open a single file when disk buffers are flushed: 1 millis.
* with felix 3.0.3 ->
time to load an empty felix cache (with disk buffers flushed) = 8.1 millis
time to load an existing felix cache (with dsk buffers flushed) = 5.3 millis
* with felix trunk (optimized version that you recently uncommited) ->
time to load an empty felix cache (with disk buffers flushed) = 7.9 millis
time to load an existing felix cache (with dsk buffers flushed) = 4.7 millis
(here, loading an existing felix cache is faster then an empty felix cache,
as expected).
So, in any cases, the optimized version of the trunk is faster than the
2.0.3.
However, with a low disk IO rate, then it seems that it takes a longer time
to load an existing felix cache
than an empty one.
/pierre
On Tue, Oct 5, 2010 at 3:13 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 10/5/10 2:59, Felix Meschberger wrote:
>
>> Hi,
>>
>> On 04.10.2010 22:26, Richard S. Hall wrote:
>>
>>> On 10/4/10 12:31, Pierre De Rop wrote:
>>>
>>>> This is surprising, because I double checked (I did the same kind of
>>>> tests
>>>> of differents machines), and I always see that loading a populated
>>>> cache is
>>>> a bit longer than an empty cache.
>>>> Ok, it's confusing for now, I will do further investigation and will get
>>>> back to you later, if I find something.
>>>>
>>> Let's keep investigating this.
>>>
>>> In the meantime, I decided to rollback the change for the next release
>>> so we can have more time to investigate it because right now I need to
>>> get a bug fix out. So, we won't introduce any bundle cache structure
>>> changes in 3.0.4, but maybe in 3.0.5.
>>>
>> This sounds like a minor-release-number-worthy change ;-)
>>
>
> I'm not sure that's necessary. It is still backward compatible, but it
> isn't forward compatible.
>
> -> richard
>
>
> Regards
>> Felix
>>
>> -> richard
>>>
>>> On Mon, Oct 4, 2010 at 5:05 PM, Richard S.
>>>> Hall<he...@ungoverned.org>wrote:
>>>>
>>>> On 10/4/10 10:52, Richard S. Hall wrote:
>>>>>
>>>>> Thanks for the installer bundle, I did some tests locally on my Mac
>>>>>> using
>>>>>> 230 bundles from GlassFish, this is what I see (note: the "purge"
>>>>>> command
>>>>>> flushes disk buffers):
>>>>>>
>>>>>> Empty cache
>>>>>> -----------------
>>>>>> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
>>>>>> bin/felix.jar
>>>>>> Mon Oct 4 10:43:09 EDT 2010
>>>>>> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
>>>>>> ./load dir
>>>>>> 2010-10-04 10:43:54,464 - Done.
>>>>>>
>>>>>> Populated cache
>>>>>> -----------------------
>>>>>> [heavyweight main]$ purge; date; java -jar bin/felix.jar
>>>>>> Mon Oct 4 10:44:49 EDT 2010
>>>>>> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
>>>>>> FrameworkEvent.STARTED event ...
>>>>>> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
>>>>>> ./load dir
>>>>>> 2010-10-04 10:45:13,342 - Done.
>>>>>>
>>>>>> You can see that the empty cache scenario takes about 45 seconds,
>>>>>> whereas
>>>>>> the populated cache takes about 24 seconds. So, on my machine, it
>>>>>> takes a
>>>>>> lot less time to re-load cached bundles...could be a function of my
>>>>>> disk
>>>>>> speed, I suppose, but it is what I would expect.
>>>>>>
>>>>>> Not sure how to proceed, other than trying to get more samples.
>>>>>>
>>>>>> Interestingly, I tried the same test using the 3.0.3 release (the
>>>>> above was
>>>>> with trunk) and I got the follow results:
>>>>>
>>>>> Empty cache (3.0.3)
>>>>> -----------------
>>>>>
>>>>> rm -rf felix-cache; purge; date; java -jar bin/felix.jar
>>>>> Mon Oct 4 10:58:23 EDT 2010
>>>>> 2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
>>>>> FrameworkEvent.STARTED event ...
>>>>> 2010-10-04 10:58:43,557 - Framework started: Installing bundles from
>>>>> ./load
>>>>> dir
>>>>> 2010-10-04 10:59:03,373 - Done.
>>>>>
>>>>> Populated cache (3.0.3)
>>>>> -----------------------
>>>>>
>>>>> purge; date; java -jar bin/felix.jar
>>>>> Mon Oct 4 10:59:50 EDT 2010
>>>>> 2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
>>>>> FrameworkEvent.STARTED event ...
>>>>> 2010-10-04 11:00:26,736 - Framework started: Installing bundles from
>>>>> ./load
>>>>> dir
>>>>> 2010-10-04 11:00:26,738 - Done.
>>>>>
>>>>> So, the populated cache takes nearly as long as the empty cache (36
>>>>> seconds
>>>>> compared to 40 seconds)...this also makes sense, since the trunk has
>>>>> patches
>>>>> specifically designed to improve re-loading cached bundles.
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>>>>
>>>>>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<
>>>>>>>>> pierre.derop@gmail.com>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>>>>>>
>>>>>>>>>>> <he...@ungoverned.org>wrote:
>>>>>>>>>>>
>>>>>>>>>>> One thing, was your performance comparison based on using
>>>>>>>>>>> the new
>>>>>>>>>>> cache
>>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>> old?
>>>>>>>>>>>>
>>>>>>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>>>>>>> snapshot
>>>>>>>>>>>> and
>>>>>>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>>>>>>
>>>>>>>>>>>> yes:
>>>>>>>>>>>>
>>>>>>>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>>>>>>> but I also checked that new fwk/trunk is properly working when
>>>>>>>>>>> being
>>>>>>>>>>> started
>>>>>>>>>>> with the old cache (from 3.0.2)
>>>>>>>>>>>
>>>>>>>>>>> You should also be testing an already created cache (i.e., a
>>>>>>>>>>> framework
>>>>>>>>>>>
>>>>>>>>>>> restart), not an empty cache.
>>>>>>>>>>>>
>>>>>>>>>>>> In the previous test, I compared with already created cache,
>>>>>>>>>>>> not
>>>>>>>>>>>> with
>>>>>>>>>>>>
>>>>>>>>>>>> empty
>>>>>>>>>>>
>>>>>>>>>> caches.
>>>>>>>>>>
>>>>>>>>>>> With empty caches, here are the results:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is
>>>>>>>>>>> surprising:
>>>>>>>>>>>
>>>>>>>>>>> I
>>>>>>>>>>>
>>>>>>>>>> would expect to get a longer delay, since the cache is
>>>>>>>>>> empty when
>>>>>>>>>>
>>>>>>>>>>> I
>>>>>>>>>>> start
>>>>>>>>>>> the fwk)
>>>>>>>>>>>
>>>>>>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>>>>>>
>>>>>>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>>>>>>
>>>>>>>>>>> hmmm, I don't understand why the fwk startup time is better
>>>>>>>>>>> when the
>>>>>>>>>>>
>>>>>>>>>>> cache
>>>>>>>>>>>
>>>>>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec
>>>>>>>>>> from
>>>>>>>>>>
>>>>>>>>>>> previous
>>>>>>>>>>> mail)
>>>>>>>>>>> Ok, I will do more tests ... may be I did something wrong ? ...
>>>>>>>>>>> to be
>>>>>>>>>>> continued ...
>>>>>>>>>>>
>>>>>>>>>>> Hmm. Yeah, that seems a little odd. In that case, you should
>>>>>>>>>>> just
>>>>>>>>>>>
>>>>>>>>>> delete
>>>>>>>>>> your cache each time to get better startup performance! ;-)
>>>>>>>>>>
>>>>>>>>>> Definitely let me know what you find out. I too would expect
>>>>>>>>>> framework
>>>>>>>>>> restarts to be faster since we don't have to copy the JAR files
>>>>>>>>>> first.
>>>>>>>>>>
>>>>>>>>>> -> richard
>>>>>>>>>>
>>>>>>>>>> /pierre
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Is that what you are doing? Just want to make sure I
>>>>>>>>>>> understand what
>>>>>>>>>>> is
>>>>>>>>>>>
>>>>>>>>>>> being measured. :-)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -> richard
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Richard,
>>>>>>>>>>>>
>>>>>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>>>>>>
>>>>>>>>>>>>> fwk/trunk)
>>>>>>>>>>>>>
>>>>>>>>>>>> ->
>>>>>>>>>>>
>>>>>>>>>>> everything works ok
>>>>>>>>>>>>
>>>>>>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>>>>>>
>>>>>>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I also compared the performance of the startup time between
>>>>>>>>>>>>> felix
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.0.2
>>>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>> felix trunk.
>>>>>>>>>>>>
>>>>>>>>>>>>> To do this, I managed to ensure that my linux IO buffers
>>>>>>>>>>>>> cache are
>>>>>>>>>>>>>
>>>>>>>>>>>>> empty
>>>>>>>>>>>>>
>>>>>>>>>>>> before doing each test, by doing this:
>>>>>>>>>>>
>>>>>>>>>>> sync
>>>>>>>>>>>>
>>>>>>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>>>>>>
>>>>>>>>>>>>> This ensures that my linux has released all buffer cache
>>>>>>>>>>>>> disk, like
>>>>>>>>>>>>> it
>>>>>>>>>>>>> is
>>>>>>>>>>>>> the case when I boot my host (cold start).
>>>>>>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds
>>>>>>>>>>>>> (it's
>>>>>>>>>>>>> slow
>>>>>>>>>>>>> because all disk buffers are empty):
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>>>>>>
>>>>>>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>>>>>>> quicker,
>>>>>>>>>>>>> but
>>>>>>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk
>>>>>>>>>>>>> buffers
>>>>>>>>>>>>> before
>>>>>>>>>>>>> starting the test):
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> /pierre
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<
>>>>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> convenience
>>>>>>>>>>>>>
>>>>>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've made some changes to the bundle cache layout and
>>>>>>>>>>>>>> handling to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> improve
>>>>>>>>>>>>>>> performance and clean up code. I've tried to maintain
>>>>>>>>>>>>>>> backward
>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>> with old caches, but I'd appreciate is someone could try it
>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>> caches to see if it works.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>>>>>>> frameworks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>
>>>>>>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>>>>>>>
>>>>>>>>>>>>> frameworks;
>>>>>>>>>>>>>>> however, previously created caches should mostly continue
>>>>>>>>>>>>>>> to work
>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>> the two although there will be a loss of fidelity since
>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> only saved to the new way or the old way depending on if
>>>>>>>>>>>>>>> you are
>>>>>>>>>>>>>>> running
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> location,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> state, start level, last modified, and refresh count) into a
>>>>>>>>>>>>> single
>>>>>>>>>>>>>
>>>>>>>>>>>> file
>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> try to avoid excessive file accesses. This appears to improve
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> startup
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> time
>>>>>>>>>>>>>
>>>>>>>>>>>> when you have a cache with lots of bundles, but your mileage
>>>>>>>>>>>> will
>>>>>>>>>>>>
>>>>>>>>>>>>> vary
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> based
>>>>>>>>>>>>>
>>>>>>>>>>>> on platform and other factors. Although, you won't necessarily
>>>>>>>>>>>> see
>>>>>>>>>>>>
>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> improvements if you are using an old cache, since it will
>>>>>>>>>>>>> revert to
>>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>> old
>>>>>>>>>>>>>>> way.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/5/10 2:59, Felix Meschberger wrote:
> Hi,
>
> On 04.10.2010 22:26, Richard S. Hall wrote:
>> On 10/4/10 12:31, Pierre De Rop wrote:
>>> This is surprising, because I double checked (I did the same kind of
>>> tests
>>> of differents machines), and I always see that loading a populated
>>> cache is
>>> a bit longer than an empty cache.
>>> Ok, it's confusing for now, I will do further investigation and will get
>>> back to you later, if I find something.
>> Let's keep investigating this.
>>
>> In the meantime, I decided to rollback the change for the next release
>> so we can have more time to investigate it because right now I need to
>> get a bug fix out. So, we won't introduce any bundle cache structure
>> changes in 3.0.4, but maybe in 3.0.5.
> This sounds like a minor-release-number-worthy change ;-)
I'm not sure that's necessary. It is still backward compatible, but it
isn't forward compatible.
-> richard
> Regards
> Felix
>
>> -> richard
>>
>>> On Mon, Oct 4, 2010 at 5:05 PM, Richard S.
>>> Hall<he...@ungoverned.org>wrote:
>>>
>>>> On 10/4/10 10:52, Richard S. Hall wrote:
>>>>
>>>>> Thanks for the installer bundle, I did some tests locally on my Mac
>>>>> using
>>>>> 230 bundles from GlassFish, this is what I see (note: the "purge"
>>>>> command
>>>>> flushes disk buffers):
>>>>>
>>>>> Empty cache
>>>>> -----------------
>>>>> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
>>>>> bin/felix.jar
>>>>> Mon Oct 4 10:43:09 EDT 2010
>>>>> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
>>>>> FrameworkEvent.STARTED event ...
>>>>> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
>>>>> ./load dir
>>>>> 2010-10-04 10:43:54,464 - Done.
>>>>>
>>>>> Populated cache
>>>>> -----------------------
>>>>> [heavyweight main]$ purge; date; java -jar bin/felix.jar
>>>>> Mon Oct 4 10:44:49 EDT 2010
>>>>> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
>>>>> FrameworkEvent.STARTED event ...
>>>>> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
>>>>> ./load dir
>>>>> 2010-10-04 10:45:13,342 - Done.
>>>>>
>>>>> You can see that the empty cache scenario takes about 45 seconds,
>>>>> whereas
>>>>> the populated cache takes about 24 seconds. So, on my machine, it
>>>>> takes a
>>>>> lot less time to re-load cached bundles...could be a function of my
>>>>> disk
>>>>> speed, I suppose, but it is what I would expect.
>>>>>
>>>>> Not sure how to proceed, other than trying to get more samples.
>>>>>
>>>> Interestingly, I tried the same test using the 3.0.3 release (the
>>>> above was
>>>> with trunk) and I got the follow results:
>>>>
>>>> Empty cache (3.0.3)
>>>> -----------------
>>>>
>>>> rm -rf felix-cache; purge; date; java -jar bin/felix.jar
>>>> Mon Oct 4 10:58:23 EDT 2010
>>>> 2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
>>>> FrameworkEvent.STARTED event ...
>>>> 2010-10-04 10:58:43,557 - Framework started: Installing bundles from
>>>> ./load
>>>> dir
>>>> 2010-10-04 10:59:03,373 - Done.
>>>>
>>>> Populated cache (3.0.3)
>>>> -----------------------
>>>>
>>>> purge; date; java -jar bin/felix.jar
>>>> Mon Oct 4 10:59:50 EDT 2010
>>>> 2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
>>>> FrameworkEvent.STARTED event ...
>>>> 2010-10-04 11:00:26,736 - Framework started: Installing bundles from
>>>> ./load
>>>> dir
>>>> 2010-10-04 11:00:26,738 - Done.
>>>>
>>>> So, the populated cache takes nearly as long as the empty cache (36
>>>> seconds
>>>> compared to 40 seconds)...this also makes sense, since the trunk has
>>>> patches
>>>> specifically designed to improve re-loading cached bundles.
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<
>>>>>>>> pierre.derop@gmail.com>
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>>>>>> <he...@ungoverned.org>wrote:
>>>>>>>>>>
>>>>>>>>>> One thing, was your performance comparison based on using
>>>>>>>>>> the new
>>>>>>>>>> cache
>>>>>>>>>> or
>>>>>>>>>>
>>>>>>>>>>> old?
>>>>>>>>>>>
>>>>>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>>>>>> snapshot
>>>>>>>>>>> and
>>>>>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>>>>>
>>>>>>>>>>> yes:
>>>>>>>>>>>
>>>>>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>>>>>> but I also checked that new fwk/trunk is properly working when
>>>>>>>>>> being
>>>>>>>>>> started
>>>>>>>>>> with the old cache (from 3.0.2)
>>>>>>>>>>
>>>>>>>>>> You should also be testing an already created cache (i.e., a
>>>>>>>>>> framework
>>>>>>>>>>
>>>>>>>>>>> restart), not an empty cache.
>>>>>>>>>>>
>>>>>>>>>>> In the previous test, I compared with already created cache,
>>>>>>>>>>> not
>>>>>>>>>>> with
>>>>>>>>>>>
>>>>>>>>>> empty
>>>>>>>>> caches.
>>>>>>>>>> With empty caches, here are the results:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is
>>>>>>>>>> surprising:
>>>>>>>>>>
>>>>>>>>>> I
>>>>>>>>> would expect to get a longer delay, since the cache is
>>>>>>>>> empty when
>>>>>>>>>> I
>>>>>>>>>> start
>>>>>>>>>> the fwk)
>>>>>>>>>>
>>>>>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>>>>>
>>>>>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>>>>>
>>>>>>>>>> hmmm, I don't understand why the fwk startup time is better
>>>>>>>>>> when the
>>>>>>>>>>
>>>>>>>>>> cache
>>>>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec
>>>>>>>>> from
>>>>>>>>>> previous
>>>>>>>>>> mail)
>>>>>>>>>> Ok, I will do more tests ... may be I did something wrong ? ...
>>>>>>>>>> to be
>>>>>>>>>> continued ...
>>>>>>>>>>
>>>>>>>>>> Hmm. Yeah, that seems a little odd. In that case, you should
>>>>>>>>>> just
>>>>>>>>> delete
>>>>>>>>> your cache each time to get better startup performance! ;-)
>>>>>>>>>
>>>>>>>>> Definitely let me know what you find out. I too would expect
>>>>>>>>> framework
>>>>>>>>> restarts to be faster since we don't have to copy the JAR files
>>>>>>>>> first.
>>>>>>>>>
>>>>>>>>> -> richard
>>>>>>>>>
>>>>>>>>> /pierre
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is that what you are doing? Just want to make sure I
>>>>>>>>>> understand what
>>>>>>>>>> is
>>>>>>>>>>
>>>>>>>>>>> being measured. :-)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -> richard
>>>>>>>>>>>
>>>>>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Richard,
>>>>>>>>>>>
>>>>>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>>>>>
>>>>>>>>>>>> fwk/trunk)
>>>>>>>>>> ->
>>>>>>>>>>
>>>>>>>>>>> everything works ok
>>>>>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>>>>>
>>>>>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>>>>>
>>>>>>>>>>>> I also compared the performance of the startup time between
>>>>>>>>>>>> felix
>>>>>>>>>>>>
>>>>>>>>>>>> 2.0.2
>>>>>>>>>> and
>>>>>>>>>>
>>>>>>>>>>> felix trunk.
>>>>>>>>>>>> To do this, I managed to ensure that my linux IO buffers
>>>>>>>>>>>> cache are
>>>>>>>>>>>>
>>>>>>>>>>>> empty
>>>>>>>>>> before doing each test, by doing this:
>>>>>>>>>>
>>>>>>>>>>> sync
>>>>>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>>>>>
>>>>>>>>>>>> This ensures that my linux has released all buffer cache
>>>>>>>>>>>> disk, like
>>>>>>>>>>>> it
>>>>>>>>>>>> is
>>>>>>>>>>>> the case when I boot my host (cold start).
>>>>>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds
>>>>>>>>>>>> (it's
>>>>>>>>>>>> slow
>>>>>>>>>>>> because all disk buffers are empty):
>>>>>>>>>>>>
>>>>>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>>>>>
>>>>>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>>>>>> quicker,
>>>>>>>>>>>> but
>>>>>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk
>>>>>>>>>>>> buffers
>>>>>>>>>>>> before
>>>>>>>>>>>> starting the test):
>>>>>>>>>>>>
>>>>>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> /pierre
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<
>>>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>>>>>> convenience
>>>>>>>>>>>>
>>>>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've made some changes to the bundle cache layout and
>>>>>>>>>>>>> handling to
>>>>>>>>>>>>>> improve
>>>>>>>>>>>>>> performance and clean up code. I've tried to maintain backward
>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>> with old caches, but I'd appreciate is someone could try it
>>>>>>>>>>>>>> out
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> their
>>>>>>>>>>>>>> caches to see if it works.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>>>>>> frameworks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So
>>>>>>>>>>>> you
>>>>>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>>>>>>>>> frameworks;
>>>>>>>>>>>>>> however, previously created caches should mostly continue
>>>>>>>>>>>>>> to work
>>>>>>>>>>>>>> between
>>>>>>>>>>>>>> the two although there will be a loss of fidelity since
>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> state
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> only saved to the new way or the old way depending on if
>>>>>>>>>>>>>> you are
>>>>>>>>>>>>>> running
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> location,
>>>>>>>>>>>> state, start level, last modified, and refresh count) into a
>>>>>>>>>>>> single
>>>>>>>>>>> file
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> try to avoid excessive file accesses. This appears to improve
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> startup
>>>>>>>>>>>> time
>>>>>>>>>>> when you have a cache with lots of bundles, but your mileage will
>>>>>>>>>>>>>> vary
>>>>>>>>>>>> based
>>>>>>>>>>> on platform and other factors. Although, you won't necessarily
>>>>>>>>>>> see
>>>>>>>>>>>>>> any
>>>>>>>>>>>> improvements if you are using an old cache, since it will
>>>>>>>>>>>> revert to
>>>>>>>>>>> the
>>>>>>>>>>>>>> old
>>>>>>>>>>>>>> way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
Re: Bundle cache changes
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 04.10.2010 22:26, Richard S. Hall wrote:
> On 10/4/10 12:31, Pierre De Rop wrote:
>> This is surprising, because I double checked (I did the same kind of
>> tests
>> of differents machines), and I always see that loading a populated
>> cache is
>> a bit longer than an empty cache.
>> Ok, it's confusing for now, I will do further investigation and will get
>> back to you later, if I find something.
>
> Let's keep investigating this.
>
> In the meantime, I decided to rollback the change for the next release
> so we can have more time to investigate it because right now I need to
> get a bug fix out. So, we won't introduce any bundle cache structure
> changes in 3.0.4, but maybe in 3.0.5.
This sounds like a minor-release-number-worthy change ;-)
Regards
Felix
>
> -> richard
>
>>
>> On Mon, Oct 4, 2010 at 5:05 PM, Richard S.
>> Hall<he...@ungoverned.org>wrote:
>>
>>> On 10/4/10 10:52, Richard S. Hall wrote:
>>>
>>>> Thanks for the installer bundle, I did some tests locally on my Mac
>>>> using
>>>> 230 bundles from GlassFish, this is what I see (note: the "purge"
>>>> command
>>>> flushes disk buffers):
>>>>
>>>> Empty cache
>>>> -----------------
>>>> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
>>>> bin/felix.jar
>>>> Mon Oct 4 10:43:09 EDT 2010
>>>> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
>>>> FrameworkEvent.STARTED event ...
>>>> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
>>>> ./load dir
>>>> 2010-10-04 10:43:54,464 - Done.
>>>>
>>>> Populated cache
>>>> -----------------------
>>>> [heavyweight main]$ purge; date; java -jar bin/felix.jar
>>>> Mon Oct 4 10:44:49 EDT 2010
>>>> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
>>>> FrameworkEvent.STARTED event ...
>>>> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
>>>> ./load dir
>>>> 2010-10-04 10:45:13,342 - Done.
>>>>
>>>> You can see that the empty cache scenario takes about 45 seconds,
>>>> whereas
>>>> the populated cache takes about 24 seconds. So, on my machine, it
>>>> takes a
>>>> lot less time to re-load cached bundles...could be a function of my
>>>> disk
>>>> speed, I suppose, but it is what I would expect.
>>>>
>>>> Not sure how to proceed, other than trying to get more samples.
>>>>
>>> Interestingly, I tried the same test using the 3.0.3 release (the
>>> above was
>>> with trunk) and I got the follow results:
>>>
>>> Empty cache (3.0.3)
>>> -----------------
>>>
>>> rm -rf felix-cache; purge; date; java -jar bin/felix.jar
>>> Mon Oct 4 10:58:23 EDT 2010
>>> 2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
>>> FrameworkEvent.STARTED event ...
>>> 2010-10-04 10:58:43,557 - Framework started: Installing bundles from
>>> ./load
>>> dir
>>> 2010-10-04 10:59:03,373 - Done.
>>>
>>> Populated cache (3.0.3)
>>> -----------------------
>>>
>>> purge; date; java -jar bin/felix.jar
>>> Mon Oct 4 10:59:50 EDT 2010
>>> 2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
>>> FrameworkEvent.STARTED event ...
>>> 2010-10-04 11:00:26,736 - Framework started: Installing bundles from
>>> ./load
>>> dir
>>> 2010-10-04 11:00:26,738 - Done.
>>>
>>> So, the populated cache takes nearly as long as the empty cache (36
>>> seconds
>>> compared to 40 seconds)...this also makes sense, since the trunk has
>>> patches
>>> specifically designed to improve re-loading cached bundles.
>>>
>>> -> richard
>>>
>>>
>>>
>>>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<
>>>>>>> pierre.derop@gmail.com>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>>>>> <he...@ungoverned.org>wrote:
>>>>>>>>>
>>>>>>>>> One thing, was your performance comparison based on using
>>>>>>>>> the new
>>>>>>>>> cache
>>>>>>>>> or
>>>>>>>>>
>>>>>>>>>> old?
>>>>>>>>>>
>>>>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>>>>> snapshot
>>>>>>>>>> and
>>>>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>>>>
>>>>>>>>>> yes:
>>>>>>>>>>
>>>>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>>>>> but I also checked that new fwk/trunk is properly working when
>>>>>>>>> being
>>>>>>>>> started
>>>>>>>>> with the old cache (from 3.0.2)
>>>>>>>>>
>>>>>>>>> You should also be testing an already created cache (i.e., a
>>>>>>>>> framework
>>>>>>>>>
>>>>>>>>>> restart), not an empty cache.
>>>>>>>>>>
>>>>>>>>>> In the previous test, I compared with already created cache,
>>>>>>>>>> not
>>>>>>>>>> with
>>>>>>>>>>
>>>>>>>>> empty
>>>>>>>> caches.
>>>>>>>>> With empty caches, here are the results:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is
>>>>>>>>> surprising:
>>>>>>>>>
>>>>>>>>> I
>>>>>>>> would expect to get a longer delay, since the cache is
>>>>>>>> empty when
>>>>>>>>> I
>>>>>>>>> start
>>>>>>>>> the fwk)
>>>>>>>>>
>>>>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>>>>
>>>>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>>>>
>>>>>>>>> hmmm, I don't understand why the fwk startup time is better
>>>>>>>>> when the
>>>>>>>>>
>>>>>>>>> cache
>>>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec
>>>>>>>> from
>>>>>>>>> previous
>>>>>>>>> mail)
>>>>>>>>> Ok, I will do more tests ... may be I did something wrong ? ...
>>>>>>>>> to be
>>>>>>>>> continued ...
>>>>>>>>>
>>>>>>>>> Hmm. Yeah, that seems a little odd. In that case, you should
>>>>>>>>> just
>>>>>>>> delete
>>>>>>>> your cache each time to get better startup performance! ;-)
>>>>>>>>
>>>>>>>> Definitely let me know what you find out. I too would expect
>>>>>>>> framework
>>>>>>>> restarts to be faster since we don't have to copy the JAR files
>>>>>>>> first.
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>> /pierre
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is that what you are doing? Just want to make sure I
>>>>>>>>> understand what
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>>> being measured. :-)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -> richard
>>>>>>>>>>
>>>>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Richard,
>>>>>>>>>>
>>>>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>>>>
>>>>>>>>>>> fwk/trunk)
>>>>>>>>> ->
>>>>>>>>>
>>>>>>>>>> everything works ok
>>>>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>>>>
>>>>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>>>>
>>>>>>>>>>> I also compared the performance of the startup time between
>>>>>>>>>>> felix
>>>>>>>>>>>
>>>>>>>>>>> 2.0.2
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>>> felix trunk.
>>>>>>>>>>> To do this, I managed to ensure that my linux IO buffers
>>>>>>>>>>> cache are
>>>>>>>>>>>
>>>>>>>>>>> empty
>>>>>>>>> before doing each test, by doing this:
>>>>>>>>>
>>>>>>>>>> sync
>>>>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>>>>
>>>>>>>>>>> This ensures that my linux has released all buffer cache
>>>>>>>>>>> disk, like
>>>>>>>>>>> it
>>>>>>>>>>> is
>>>>>>>>>>> the case when I boot my host (cold start).
>>>>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds
>>>>>>>>>>> (it's
>>>>>>>>>>> slow
>>>>>>>>>>> because all disk buffers are empty):
>>>>>>>>>>>
>>>>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>>>>
>>>>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>>>>> quicker,
>>>>>>>>>>> but
>>>>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk
>>>>>>>>>>> buffers
>>>>>>>>>>> before
>>>>>>>>>>> starting the test):
>>>>>>>>>>>
>>>>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /pierre
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<
>>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>>>>> convenience
>>>>>>>>>>>
>>>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>
>>>>>>>>>>>> I've made some changes to the bundle cache layout and
>>>>>>>>>>>> handling to
>>>>>>>>>>>>> improve
>>>>>>>>>>>>> performance and clean up code. I've tried to maintain backward
>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>> with old caches, but I'd appreciate is someone could try it
>>>>>>>>>>>>> out
>>>>>>>>>>>>> on
>>>>>>>>>>>>> their
>>>>>>>>>>>>> caches to see if it works.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>>>>> frameworks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So
>>>>>>>>>>> you
>>>>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>>>>>>>> frameworks;
>>>>>>>>>>>>> however, previously created caches should mostly continue
>>>>>>>>>>>>> to work
>>>>>>>>>>>>> between
>>>>>>>>>>>>> the two although there will be a loss of fidelity since
>>>>>>>>>>>>> changes
>>>>>>>>>>>>> to
>>>>>>>>>>>>> state
>>>>>>>>>>>>> are
>>>>>>>>>>>>> only saved to the new way or the old way depending on if
>>>>>>>>>>>>> you are
>>>>>>>>>>>>> running
>>>>>>>>>>>>> on
>>>>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>>>>
>>>>>>>>>>>>> location,
>>>>>>>>>>> state, start level, last modified, and refresh count) into a
>>>>>>>>>>> single
>>>>>>>>>> file
>>>>>>>>>>>>> and
>>>>>>>>>>>>> try to avoid excessive file accesses. This appears to improve
>>>>>>>>>>>>>
>>>>>>>>>>>>> startup
>>>>>>>>>>> time
>>>>>>>>>> when you have a cache with lots of bundles, but your mileage will
>>>>>>>>>>>>> vary
>>>>>>>>>>> based
>>>>>>>>>> on platform and other factors. Although, you won't necessarily
>>>>>>>>>> see
>>>>>>>>>>>>> any
>>>>>>>>>>> improvements if you are using an old cache, since it will
>>>>>>>>>>> revert to
>>>>>>>>>> the
>>>>>>>>>>>>> old
>>>>>>>>>>>>> way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -> richard
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/4/10 12:31, Pierre De Rop wrote:
> This is surprising, because I double checked (I did the same kind of tests
> of differents machines), and I always see that loading a populated cache is
> a bit longer than an empty cache.
> Ok, it's confusing for now, I will do further investigation and will get
> back to you later, if I find something.
Let's keep investigating this.
In the meantime, I decided to rollback the change for the next release
so we can have more time to investigate it because right now I need to
get a bug fix out. So, we won't introduce any bundle cache structure
changes in 3.0.4, but maybe in 3.0.5.
-> richard
>
> On Mon, Oct 4, 2010 at 5:05 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> On 10/4/10 10:52, Richard S. Hall wrote:
>>
>>> Thanks for the installer bundle, I did some tests locally on my Mac using
>>> 230 bundles from GlassFish, this is what I see (note: the "purge" command
>>> flushes disk buffers):
>>>
>>> Empty cache
>>> -----------------
>>> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
>>> bin/felix.jar
>>> Mon Oct 4 10:43:09 EDT 2010
>>> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
>>> FrameworkEvent.STARTED event ...
>>> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
>>> ./load dir
>>> 2010-10-04 10:43:54,464 - Done.
>>>
>>> Populated cache
>>> -----------------------
>>> [heavyweight main]$ purge; date; java -jar bin/felix.jar
>>> Mon Oct 4 10:44:49 EDT 2010
>>> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
>>> FrameworkEvent.STARTED event ...
>>> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
>>> ./load dir
>>> 2010-10-04 10:45:13,342 - Done.
>>>
>>> You can see that the empty cache scenario takes about 45 seconds, whereas
>>> the populated cache takes about 24 seconds. So, on my machine, it takes a
>>> lot less time to re-load cached bundles...could be a function of my disk
>>> speed, I suppose, but it is what I would expect.
>>>
>>> Not sure how to proceed, other than trying to get more samples.
>>>
>> Interestingly, I tried the same test using the 3.0.3 release (the above was
>> with trunk) and I got the follow results:
>>
>> Empty cache (3.0.3)
>> -----------------
>>
>> rm -rf felix-cache; purge; date; java -jar bin/felix.jar
>> Mon Oct 4 10:58:23 EDT 2010
>> 2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
>> FrameworkEvent.STARTED event ...
>> 2010-10-04 10:58:43,557 - Framework started: Installing bundles from ./load
>> dir
>> 2010-10-04 10:59:03,373 - Done.
>>
>> Populated cache (3.0.3)
>> -----------------------
>>
>> purge; date; java -jar bin/felix.jar
>> Mon Oct 4 10:59:50 EDT 2010
>> 2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
>> FrameworkEvent.STARTED event ...
>> 2010-10-04 11:00:26,736 - Framework started: Installing bundles from ./load
>> dir
>> 2010-10-04 11:00:26,738 - Done.
>>
>> So, the populated cache takes nearly as long as the empty cache (36 seconds
>> compared to 40 seconds)...this also makes sense, since the trunk has patches
>> specifically designed to improve re-loading cached bundles.
>>
>> -> richard
>>
>>
>>
>>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<
>>>>>> pierre.derop@gmail.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>>>> <he...@ungoverned.org>wrote:
>>>>>>>>
>>>>>>>> One thing, was your performance comparison based on using the new
>>>>>>>> cache
>>>>>>>> or
>>>>>>>>
>>>>>>>>> old?
>>>>>>>>>
>>>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>>>> snapshot
>>>>>>>>> and
>>>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>>>
>>>>>>>>> yes:
>>>>>>>>>
>>>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>>>> but I also checked that new fwk/trunk is properly working when being
>>>>>>>> started
>>>>>>>> with the old cache (from 3.0.2)
>>>>>>>>
>>>>>>>> You should also be testing an already created cache (i.e., a
>>>>>>>> framework
>>>>>>>>
>>>>>>>>> restart), not an empty cache.
>>>>>>>>>
>>>>>>>>> In the previous test, I compared with already created cache, not
>>>>>>>>> with
>>>>>>>>>
>>>>>>>> empty
>>>>>>> caches.
>>>>>>>> With empty caches, here are the results:
>>>>>>>>
>>>>>>>>
>>>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is
>>>>>>>> surprising:
>>>>>>>>
>>>>>>>> I
>>>>>>> would expect to get a longer delay, since the cache is empty when
>>>>>>>> I
>>>>>>>> start
>>>>>>>> the fwk)
>>>>>>>>
>>>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>>>
>>>>>>>>
>>>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>>>
>>>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>>>
>>>>>>>> hmmm, I don't understand why the fwk startup time is better when the
>>>>>>>>
>>>>>>>> cache
>>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec from
>>>>>>>> previous
>>>>>>>> mail)
>>>>>>>> Ok, I will do more tests ... may be I did something wrong ? ... to be
>>>>>>>> continued ...
>>>>>>>>
>>>>>>>> Hmm. Yeah, that seems a little odd. In that case, you should just
>>>>>>> delete
>>>>>>> your cache each time to get better startup performance! ;-)
>>>>>>>
>>>>>>> Definitely let me know what you find out. I too would expect framework
>>>>>>> restarts to be faster since we don't have to copy the JAR files first.
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>> /pierre
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Is that what you are doing? Just want to make sure I understand what
>>>>>>>> is
>>>>>>>>
>>>>>>>>> being measured. :-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -> richard
>>>>>>>>>
>>>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>>>
>>>>>>>>> Hi Richard,
>>>>>>>>>
>>>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>>>
>>>>>>>>>> fwk/trunk)
>>>>>>>> ->
>>>>>>>>
>>>>>>>>> everything works ok
>>>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>>>
>>>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>>>
>>>>>>>>>> I also compared the performance of the startup time between felix
>>>>>>>>>>
>>>>>>>>>> 2.0.2
>>>>>>>> and
>>>>>>>>
>>>>>>>>> felix trunk.
>>>>>>>>>> To do this, I managed to ensure that my linux IO buffers cache are
>>>>>>>>>>
>>>>>>>>>> empty
>>>>>>>> before doing each test, by doing this:
>>>>>>>>
>>>>>>>>> sync
>>>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>>>
>>>>>>>>>> This ensures that my linux has released all buffer cache disk, like
>>>>>>>>>> it
>>>>>>>>>> is
>>>>>>>>>> the case when I boot my host (cold start).
>>>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds
>>>>>>>>>> (it's
>>>>>>>>>> slow
>>>>>>>>>> because all disk buffers are empty):
>>>>>>>>>>
>>>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>>>
>>>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>>>> quicker,
>>>>>>>>>> but
>>>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk buffers
>>>>>>>>>> before
>>>>>>>>>> starting the test):
>>>>>>>>>>
>>>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /pierre
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<
>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>>>> convenience
>>>>>>>>>>
>>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>>>
>>>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>
>>>>>>>>>>> I've made some changes to the bundle cache layout and handling to
>>>>>>>>>>>> improve
>>>>>>>>>>>> performance and clean up code. I've tried to maintain backward
>>>>>>>>>>>> compatibility
>>>>>>>>>>>> with old caches, but I'd appreciate is someone could try it out
>>>>>>>>>>>> on
>>>>>>>>>>>> their
>>>>>>>>>>>> caches to see if it works.
>>>>>>>>>>>>
>>>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>>>
>>>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>>>> frameworks.
>>>>>>>>>>>>
>>>>>>>>>>>> So
>>>>>>>>>> you
>>>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>>>>>>> frameworks;
>>>>>>>>>>>> however, previously created caches should mostly continue to work
>>>>>>>>>>>> between
>>>>>>>>>>>> the two although there will be a loss of fidelity since changes
>>>>>>>>>>>> to
>>>>>>>>>>>> state
>>>>>>>>>>>> are
>>>>>>>>>>>> only saved to the new way or the old way depending on if you are
>>>>>>>>>>>> running
>>>>>>>>>>>> on
>>>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>>>
>>>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>>>
>>>>>>>>>>>> location,
>>>>>>>>>> state, start level, last modified, and refresh count) into a single
>>>>>>>>> file
>>>>>>>>>>>> and
>>>>>>>>>>>> try to avoid excessive file accesses. This appears to improve
>>>>>>>>>>>>
>>>>>>>>>>>> startup
>>>>>>>>>> time
>>>>>>>>> when you have a cache with lots of bundles, but your mileage will
>>>>>>>>>>>> vary
>>>>>>>>>> based
>>>>>>>>> on platform and other factors. Although, you won't necessarily see
>>>>>>>>>>>> any
>>>>>>>>>> improvements if you are using an old cache, since it will revert to
>>>>>>>>> the
>>>>>>>>>>>> old
>>>>>>>>>>>> way.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> -> richard
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
Re: Bundle cache changes
Posted by Pierre De Rop <pi...@gmail.com>.
This is surprising, because I double checked (I did the same kind of tests
of differents machines), and I always see that loading a populated cache is
a bit longer than an empty cache.
Ok, it's confusing for now, I will do further investigation and will get
back to you later, if I find something.
On Mon, Oct 4, 2010 at 5:05 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 10/4/10 10:52, Richard S. Hall wrote:
>
>>
>> Thanks for the installer bundle, I did some tests locally on my Mac using
>> 230 bundles from GlassFish, this is what I see (note: the "purge" command
>> flushes disk buffers):
>>
>> Empty cache
>> -----------------
>> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
>> bin/felix.jar
>> Mon Oct 4 10:43:09 EDT 2010
>> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
>> FrameworkEvent.STARTED event ...
>> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
>> ./load dir
>> 2010-10-04 10:43:54,464 - Done.
>>
>> Populated cache
>> -----------------------
>> [heavyweight main]$ purge; date; java -jar bin/felix.jar
>> Mon Oct 4 10:44:49 EDT 2010
>> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
>> FrameworkEvent.STARTED event ...
>> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
>> ./load dir
>> 2010-10-04 10:45:13,342 - Done.
>>
>> You can see that the empty cache scenario takes about 45 seconds, whereas
>> the populated cache takes about 24 seconds. So, on my machine, it takes a
>> lot less time to re-load cached bundles...could be a function of my disk
>> speed, I suppose, but it is what I would expect.
>>
>> Not sure how to proceed, other than trying to get more samples.
>>
>
> Interestingly, I tried the same test using the 3.0.3 release (the above was
> with trunk) and I got the follow results:
>
> Empty cache (3.0.3)
> -----------------
>
> rm -rf felix-cache; purge; date; java -jar bin/felix.jar
> Mon Oct 4 10:58:23 EDT 2010
> 2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
> FrameworkEvent.STARTED event ...
> 2010-10-04 10:58:43,557 - Framework started: Installing bundles from ./load
> dir
> 2010-10-04 10:59:03,373 - Done.
>
> Populated cache (3.0.3)
> -----------------------
>
> purge; date; java -jar bin/felix.jar
> Mon Oct 4 10:59:50 EDT 2010
> 2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
> FrameworkEvent.STARTED event ...
> 2010-10-04 11:00:26,736 - Framework started: Installing bundles from ./load
> dir
> 2010-10-04 11:00:26,738 - Done.
>
> So, the populated cache takes nearly as long as the empty cache (36 seconds
> compared to 40 seconds)...this also makes sense, since the trunk has patches
> specifically designed to improve re-loading cached bundles.
>
> -> richard
>
>
>
>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>>
>>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<
>>>>> pierre.derop@gmail.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>>> <he...@ungoverned.org>wrote:
>>>>>>>
>>>>>>> One thing, was your performance comparison based on using the new
>>>>>>> cache
>>>>>>> or
>>>>>>>
>>>>>>>> old?
>>>>>>>>
>>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>>> snapshot
>>>>>>>> and
>>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>>
>>>>>>>> yes:
>>>>>>>>
>>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>>> but I also checked that new fwk/trunk is properly working when being
>>>>>>> started
>>>>>>> with the old cache (from 3.0.2)
>>>>>>>
>>>>>>> You should also be testing an already created cache (i.e., a
>>>>>>> framework
>>>>>>>
>>>>>>>> restart), not an empty cache.
>>>>>>>>
>>>>>>>> In the previous test, I compared with already created cache, not
>>>>>>>> with
>>>>>>>>
>>>>>>> empty
>>>>>>
>>>>>> caches.
>>>>>>> With empty caches, here are the results:
>>>>>>>
>>>>>>>
>>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is
>>>>>>> surprising:
>>>>>>>
>>>>>>> I
>>>>>>
>>>>>> would expect to get a longer delay, since the cache is empty when
>>>>>>> I
>>>>>>> start
>>>>>>> the fwk)
>>>>>>>
>>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>>
>>>>>>>
>>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>>
>>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>>
>>>>>>> hmmm, I don't understand why the fwk startup time is better when the
>>>>>>>
>>>>>>> cache
>>>>>>
>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec from
>>>>>>> previous
>>>>>>> mail)
>>>>>>> Ok, I will do more tests ... may be I did something wrong ? ... to be
>>>>>>> continued ...
>>>>>>>
>>>>>>> Hmm. Yeah, that seems a little odd. In that case, you should just
>>>>>> delete
>>>>>> your cache each time to get better startup performance! ;-)
>>>>>>
>>>>>> Definitely let me know what you find out. I too would expect framework
>>>>>> restarts to be faster since we don't have to copy the JAR files first.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>> /pierre
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Is that what you are doing? Just want to make sure I understand what
>>>>>>> is
>>>>>>>
>>>>>>>> being measured. :-)
>>>>>>>>
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>>
>>>>>>>> Hi Richard,
>>>>>>>>
>>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>>
>>>>>>>>> fwk/trunk)
>>>>>>>>
>>>>>>> ->
>>>>>>>
>>>>>>>> everything works ok
>>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>>
>>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>>
>>>>>>>>> I also compared the performance of the startup time between felix
>>>>>>>>>
>>>>>>>>> 2.0.2
>>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>> felix trunk.
>>>>>>>>> To do this, I managed to ensure that my linux IO buffers cache are
>>>>>>>>>
>>>>>>>>> empty
>>>>>>>>
>>>>>>> before doing each test, by doing this:
>>>>>>>
>>>>>>>> sync
>>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>>
>>>>>>>>> This ensures that my linux has released all buffer cache disk, like
>>>>>>>>> it
>>>>>>>>> is
>>>>>>>>> the case when I boot my host (cold start).
>>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds
>>>>>>>>> (it's
>>>>>>>>> slow
>>>>>>>>> because all disk buffers are empty):
>>>>>>>>>
>>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>>
>>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>>> quicker,
>>>>>>>>> but
>>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk buffers
>>>>>>>>> before
>>>>>>>>> starting the test):
>>>>>>>>>
>>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /pierre
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<
>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>>> convenience
>>>>>>>>>
>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>>
>>>>>>>>>> Hey everyone,
>>>>>>>>>>
>>>>>>>>>> I've made some changes to the bundle cache layout and handling to
>>>>>>>>>>> improve
>>>>>>>>>>> performance and clean up code. I've tried to maintain backward
>>>>>>>>>>> compatibility
>>>>>>>>>>> with old caches, but I'd appreciate is someone could try it out
>>>>>>>>>>> on
>>>>>>>>>>> their
>>>>>>>>>>> caches to see if it works.
>>>>>>>>>>>
>>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>>
>>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>>> frameworks.
>>>>>>>>>>>
>>>>>>>>>>> So
>>>>>>>>>>
>>>>>>>>> you
>>>>>>>
>>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>>>>>> frameworks;
>>>>>>>>>>> however, previously created caches should mostly continue to work
>>>>>>>>>>> between
>>>>>>>>>>> the two although there will be a loss of fidelity since changes
>>>>>>>>>>> to
>>>>>>>>>>> state
>>>>>>>>>>> are
>>>>>>>>>>> only saved to the new way or the old way depending on if you are
>>>>>>>>>>> running
>>>>>>>>>>> on
>>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>>
>>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>>
>>>>>>>>>>> location,
>>>>>>>>>>
>>>>>>>>> state, start level, last modified, and refresh count) into a single
>>>>>>>
>>>>>>>> file
>>>>>>>>>>> and
>>>>>>>>>>> try to avoid excessive file accesses. This appears to improve
>>>>>>>>>>>
>>>>>>>>>>> startup
>>>>>>>>>>
>>>>>>>>> time
>>>>>>>
>>>>>>>> when you have a cache with lots of bundles, but your mileage will
>>>>>>>>>>>
>>>>>>>>>>> vary
>>>>>>>>>>
>>>>>>>>> based
>>>>>>>
>>>>>>>> on platform and other factors. Although, you won't necessarily see
>>>>>>>>>>>
>>>>>>>>>>> any
>>>>>>>>>>
>>>>>>>>> improvements if you are using an old cache, since it will revert to
>>>>>>>
>>>>>>>> the
>>>>>>>>>>> old
>>>>>>>>>>> way.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> -> richard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/4/10 10:52, Richard S. Hall wrote:
>
> Thanks for the installer bundle, I did some tests locally on my Mac
> using 230 bundles from GlassFish, this is what I see (note: the
> "purge" command flushes disk buffers):
>
> Empty cache
> -----------------
> [heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
> bin/felix.jar
> Mon Oct 4 10:43:09 EDT 2010
> 2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
> FrameworkEvent.STARTED event ...
> 2010-10-04 10:43:24,822 - Framework started: Installing bundles from
> ./load dir
> 2010-10-04 10:43:54,464 - Done.
>
> Populated cache
> -----------------------
> [heavyweight main]$ purge; date; java -jar bin/felix.jar
> Mon Oct 4 10:44:49 EDT 2010
> 2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
> FrameworkEvent.STARTED event ...
> 2010-10-04 10:45:13,340 - Framework started: Installing bundles from
> ./load dir
> 2010-10-04 10:45:13,342 - Done.
>
> You can see that the empty cache scenario takes about 45 seconds,
> whereas the populated cache takes about 24 seconds. So, on my machine,
> it takes a lot less time to re-load cached bundles...could be a
> function of my disk speed, I suppose, but it is what I would expect.
>
> Not sure how to proceed, other than trying to get more samples.
Interestingly, I tried the same test using the 3.0.3 release (the above
was with trunk) and I got the follow results:
Empty cache (3.0.3)
-----------------
rm -rf felix-cache; purge; date; java -jar bin/felix.jar
Mon Oct 4 10:58:23 EDT 2010
2010-10-04 10:58:43,340 - BundleInstaller starting and waiting for
FrameworkEvent.STARTED event ...
2010-10-04 10:58:43,557 - Framework started: Installing bundles from
./load dir
2010-10-04 10:59:03,373 - Done.
Populated cache (3.0.3)
-----------------------
purge; date; java -jar bin/felix.jar
Mon Oct 4 10:59:50 EDT 2010
2010-10-04 11:00:24,738 - BundleInstaller starting and waiting for
FrameworkEvent.STARTED event ...
2010-10-04 11:00:26,736 - Framework started: Installing bundles from
./load dir
2010-10-04 11:00:26,738 - Done.
So, the populated cache takes nearly as long as the empty cache (36
seconds compared to 40 seconds)...this also makes sense, since the trunk
has patches specifically designed to improve re-loading cached bundles.
-> richard
>>
>>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>>
>>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De
>>>> Rop<pi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>>> <he...@ungoverned.org>wrote:
>>>>>>
>>>>>> One thing, was your performance comparison based on using the new
>>>>>> cache
>>>>>> or
>>>>>>> old?
>>>>>>>
>>>>>>> I assume you are using a newly created cache for the framework
>>>>>>> snapshot
>>>>>>> and
>>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>>
>>>>>>> yes:
>>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>>> but I also checked that new fwk/trunk is properly working when being
>>>>>> started
>>>>>> with the old cache (from 3.0.2)
>>>>>>
>>>>>> You should also be testing an already created cache (i.e., a
>>>>>> framework
>>>>>>> restart), not an empty cache.
>>>>>>>
>>>>>>> In the previous test, I compared with already created cache,
>>>>>>> not with
>>>>> empty
>>>>>
>>>>>> caches.
>>>>>> With empty caches, here are the results:
>>>>>>
>>>>>>
>>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is
>>>>>> surprising:
>>>>>>
>>>>> I
>>>>>
>>>>>> would expect to get a longer delay, since the cache is empty
>>>>>> when I
>>>>>> start
>>>>>> the fwk)
>>>>>>
>>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>>
>>>>>>
>>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>>
>>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>>
>>>>>> hmmm, I don't understand why the fwk startup time is better when the
>>>>>>
>>>>> cache
>>>>>
>>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec from
>>>>>> previous
>>>>>> mail)
>>>>>> Ok, I will do more tests ... may be I did something wrong ? ...
>>>>>> to be
>>>>>> continued ...
>>>>>>
>>>>> Hmm. Yeah, that seems a little odd. In that case, you should just
>>>>> delete
>>>>> your cache each time to get better startup performance! ;-)
>>>>>
>>>>> Definitely let me know what you find out. I too would expect
>>>>> framework
>>>>> restarts to be faster since we don't have to copy the JAR files
>>>>> first.
>>>>>
>>>>> -> richard
>>>>>
>>>>> /pierre
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is that what you are doing? Just want to make sure I understand
>>>>>> what is
>>>>>>> being measured. :-)
>>>>>>>
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>>
>>>>>>> Hi Richard,
>>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>>
>>>>>>> fwk/trunk)
>>>>>> ->
>>>>>>>> everything works ok
>>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>>
>>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>>
>>>>>>>> I also compared the performance of the startup time between felix
>>>>>>>>
>>>>>>> 2.0.2
>>>>>> and
>>>>>>>> felix trunk.
>>>>>>>> To do this, I managed to ensure that my linux IO buffers cache are
>>>>>>>>
>>>>>>> empty
>>>>>> before doing each test, by doing this:
>>>>>>>> sync
>>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>>
>>>>>>>> This ensures that my linux has released all buffer cache disk,
>>>>>>>> like it
>>>>>>>> is
>>>>>>>> the case when I boot my host (cold start).
>>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds
>>>>>>>> (it's
>>>>>>>> slow
>>>>>>>> because all disk buffers are empty):
>>>>>>>>
>>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>>
>>>>>>>> and with felix/trunk, indeed, the server starts a little bit
>>>>>>>> quicker,
>>>>>>>> but
>>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk buffers
>>>>>>>> before
>>>>>>>> starting the test):
>>>>>>>>
>>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>>
>>>>>>>>
>>>>>>>> /pierre
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S.
>>>>>>>> Hall<heavy@ungoverned.org
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>> p.s. I deploy snapshots of the everything, including the
>>>>>>>> convenience
>>>>>>>>
>>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>>
>>>>>>>>> Hey everyone,
>>>>>>>>>
>>>>>>>>>> I've made some changes to the bundle cache layout and
>>>>>>>>>> handling to
>>>>>>>>>> improve
>>>>>>>>>> performance and clean up code. I've tried to maintain backward
>>>>>>>>>> compatibility
>>>>>>>>>> with old caches, but I'd appreciate is someone could try it
>>>>>>>>>> out on
>>>>>>>>>> their
>>>>>>>>>> caches to see if it works.
>>>>>>>>>>
>>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>>
>>>>>>>>>> Note that the new cache format will not work with older
>>>>>>>>>> frameworks.
>>>>>>>>>>
>>>>>>>>> So
>>>>>> you
>>>>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>>>>> frameworks;
>>>>>>>>>> however, previously created caches should mostly continue to
>>>>>>>>>> work
>>>>>>>>>> between
>>>>>>>>>> the two although there will be a loss of fidelity since
>>>>>>>>>> changes to
>>>>>>>>>> state
>>>>>>>>>> are
>>>>>>>>>> only saved to the new way or the old way depending on if you are
>>>>>>>>>> running
>>>>>>>>>> on
>>>>>>>>>> the new framework or the old one.
>>>>>>>>>>
>>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>>
>>>>>>>>> location,
>>>>>> state, start level, last modified, and refresh count) into a single
>>>>>>>>>> file
>>>>>>>>>> and
>>>>>>>>>> try to avoid excessive file accesses. This appears to improve
>>>>>>>>>>
>>>>>>>>> startup
>>>>>> time
>>>>>>>>>> when you have a cache with lots of bundles, but your mileage
>>>>>>>>>> will
>>>>>>>>>>
>>>>>>>>> vary
>>>>>> based
>>>>>>>>>> on platform and other factors. Although, you won't
>>>>>>>>>> necessarily see
>>>>>>>>>>
>>>>>>>>> any
>>>>>> improvements if you are using an old cache, since it will revert to
>>>>>>>>>> the
>>>>>>>>>> old
>>>>>>>>>> way.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> -> richard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/2/10 15:10, Pierre De Rop wrote:
> On Sat, Oct 2, 2010 at 7:42 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> On 10/2/10 12:09, Pierre De Rop wrote:
>>
>>> Hi Richard,
>>>
>> Am I interpreting the above data correctly that it takes about 6 seconds to
>> start up when you install your bundles and 9.6 seconds for it to start when
>> the framework reloads the cached bundles? And this data is for the trunk
>> framework?
>>
>> yes, with trunk.
>
>
>> If so, that seems odd to me, since the install includes the copying of the
>> JAR file as well as opening the JAR file for use, while reloading should
>> only include opening the JAR file for use...
>>
>>
> I will try to send you something which reproduces the scenario.
Thanks for the installer bundle, I did some tests locally on my Mac
using 230 bundles from GlassFish, this is what I see (note: the "purge"
command flushes disk buffers):
Empty cache
-----------------
[heavyweight main]$ rm -rf felix-cache; purge; date; java -jar
bin/felix.jar
Mon Oct 4 10:43:09 EDT 2010
2010-10-04 10:43:24,541 - BundleInstaller starting and waiting for
FrameworkEvent.STARTED event ...
2010-10-04 10:43:24,822 - Framework started: Installing bundles from
./load dir
2010-10-04 10:43:54,464 - Done.
Populated cache
-----------------------
[heavyweight main]$ purge; date; java -jar bin/felix.jar
Mon Oct 4 10:44:49 EDT 2010
2010-10-04 10:45:12,212 - BundleInstaller starting and waiting for
FrameworkEvent.STARTED event ...
2010-10-04 10:45:13,340 - Framework started: Installing bundles from
./load dir
2010-10-04 10:45:13,342 - Done.
You can see that the empty cache scenario takes about 45 seconds,
whereas the populated cache takes about 24 seconds. So, on my machine,
it takes a lot less time to re-load cached bundles...could be a function
of my disk speed, I suppose, but it is what I would expect.
Not sure how to proceed, other than trying to get more samples.
-> richard
> /pierre
>
>
>
>
>> -> richard
>>
>>
>> /pierre
>>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>>
>>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<pi...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>>> <he...@ungoverned.org>wrote:
>>>>>
>>>>> One thing, was your performance comparison based on using the new
>>>>> cache
>>>>> or
>>>>>> old?
>>>>>>
>>>>>> I assume you are using a newly created cache for the framework snapshot
>>>>>> and
>>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>>
>>>>>> yes:
>>>>> old cache with 3.0.2, and new cache with trunk.
>>>>> but I also checked that new fwk/trunk is properly working when being
>>>>> started
>>>>> with the old cache (from 3.0.2)
>>>>>
>>>>> You should also be testing an already created cache (i.e., a framework
>>>>>> restart), not an empty cache.
>>>>>>
>>>>>> In the previous test, I compared with already created cache, not with
>>>> empty
>>>>
>>>>> caches.
>>>>> With empty caches, here are the results:
>>>>>
>>>>>
>>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is
>>>>> surprising:
>>>>>
>>>> I
>>>>
>>>>> would expect to get a longer delay, since the cache is empty when I
>>>>> start
>>>>> the fwk)
>>>>>
>>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>>
>>>>>
>>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>>
>>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>>
>>>>> hmmm, I don't understand why the fwk startup time is better when the
>>>>>
>>>> cache
>>>>
>>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec from
>>>>> previous
>>>>> mail)
>>>>> Ok, I will do more tests ... may be I did something wrong ? ... to be
>>>>> continued ...
>>>>>
>>>> Hmm. Yeah, that seems a little odd. In that case, you should just delete
>>>> your cache each time to get better startup performance! ;-)
>>>>
>>>> Definitely let me know what you find out. I too would expect framework
>>>> restarts to be faster since we don't have to copy the JAR files first.
>>>>
>>>> -> richard
>>>>
>>>> /pierre
>>>>>
>>>>>
>>>>>
>>>>> Is that what you are doing? Just want to make sure I understand what is
>>>>>> being measured. :-)
>>>>>>
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>>
>>>>>> Hi Richard,
>>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>>
>>>>>> fwk/trunk)
>>>>> ->
>>>>>>> everything works ok
>>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>>
>>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>>
>>>>>>> I also compared the performance of the startup time between felix
>>>>>>>
>>>>>> 2.0.2
>>>>> and
>>>>>>> felix trunk.
>>>>>>> To do this, I managed to ensure that my linux IO buffers cache are
>>>>>>>
>>>>>> empty
>>>>> before doing each test, by doing this:
>>>>>>> sync
>>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>>
>>>>>>> This ensures that my linux has released all buffer cache disk, like it
>>>>>>> is
>>>>>>> the case when I boot my host (cold start).
>>>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds (it's
>>>>>>> slow
>>>>>>> because all disk buffers are empty):
>>>>>>>
>>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>>
>>>>>>> and with felix/trunk, indeed, the server starts a little bit quicker,
>>>>>>> but
>>>>>>> not so much: around *in 20,3* seconds (I also flushed disk buffers
>>>>>>> before
>>>>>>> starting the test):
>>>>>>>
>>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>>
>>>>>>>
>>>>>>> /pierre
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<heavy@ungoverned.org
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>> p.s. I deploy snapshots of the everything, including the convenience
>>>>>>>
>>>>>>>> framework distribution or you can build from trunk.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>>
>>>>>>>> Hey everyone,
>>>>>>>>
>>>>>>>>> I've made some changes to the bundle cache layout and handling to
>>>>>>>>> improve
>>>>>>>>> performance and clean up code. I've tried to maintain backward
>>>>>>>>> compatibility
>>>>>>>>> with old caches, but I'd appreciate is someone could try it out on
>>>>>>>>> their
>>>>>>>>> caches to see if it works.
>>>>>>>>>
>>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>>
>>>>>>>>> Note that the new cache format will not work with older frameworks.
>>>>>>>>>
>>>>>>>> So
>>>>> you
>>>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>>>> frameworks;
>>>>>>>>> however, previously created caches should mostly continue to work
>>>>>>>>> between
>>>>>>>>> the two although there will be a loss of fidelity since changes to
>>>>>>>>> state
>>>>>>>>> are
>>>>>>>>> only saved to the new way or the old way depending on if you are
>>>>>>>>> running
>>>>>>>>> on
>>>>>>>>> the new framework or the old one.
>>>>>>>>>
>>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>>
>>>>>>>> location,
>>>>> state, start level, last modified, and refresh count) into a single
>>>>>>>>> file
>>>>>>>>> and
>>>>>>>>> try to avoid excessive file accesses. This appears to improve
>>>>>>>>>
>>>>>>>> startup
>>>>> time
>>>>>>>>> when you have a cache with lots of bundles, but your mileage will
>>>>>>>>>
>>>>>>>> vary
>>>>> based
>>>>>>>>> on platform and other factors. Although, you won't necessarily see
>>>>>>>>>
>>>>>>>> any
>>>>> improvements if you are using an old cache, since it will revert to
>>>>>>>>> the
>>>>>>>>> old
>>>>>>>>> way.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> -> richard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Re: Bundle cache changes
Posted by Pierre De Rop <pi...@gmail.com>.
On Sat, Oct 2, 2010 at 7:42 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 10/2/10 12:09, Pierre De Rop wrote:
>
>> Hi Richard,
>>
> Am I interpreting the above data correctly that it takes about 6 seconds to
> start up when you install your bundles and 9.6 seconds for it to start when
> the framework reloads the cached bundles? And this data is for the trunk
> framework?
>
> yes, with trunk.
> If so, that seems odd to me, since the install includes the copying of the
> JAR file as well as opening the JAR file for use, while reloading should
> only include opening the JAR file for use...
>
>
I will try to send you something which reproduces the scenario.
/pierre
> -> richard
>
>
> /pierre
>>
>> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>>
>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<pi...@gmail.com>
>>> wrote:
>>>
>>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>>> <he...@ungoverned.org>wrote:
>>>>
>>>> One thing, was your performance comparison based on using the new
>>>>>
>>>> cache
>>>
>>>> or
>>>>> old?
>>>>>
>>>>> I assume you are using a newly created cache for the framework snapshot
>>>>> and
>>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>>
>>>>> yes:
>>>> old cache with 3.0.2, and new cache with trunk.
>>>> but I also checked that new fwk/trunk is properly working when being
>>>> started
>>>> with the old cache (from 3.0.2)
>>>>
>>>> You should also be testing an already created cache (i.e., a framework
>>>>> restart), not an empty cache.
>>>>>
>>>>> In the previous test, I compared with already created cache, not with
>>>>
>>> empty
>>>
>>>> caches.
>>>> With empty caches, here are the results:
>>>>
>>>>
>>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is
>>>> surprising:
>>>>
>>> I
>>>
>>>> would expect to get a longer delay, since the cache is empty when I
>>>> start
>>>> the fwk)
>>>>
>>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>>
>>>>
>>>> - new fwk / fresh empty cache ->15.2 sec
>>>>
>>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>>
>>>> hmmm, I don't understand why the fwk startup time is better when the
>>>>
>>> cache
>>>
>>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec from
>>>> previous
>>>> mail)
>>>> Ok, I will do more tests ... may be I did something wrong ? ... to be
>>>> continued ...
>>>>
>>> Hmm. Yeah, that seems a little odd. In that case, you should just delete
>>> your cache each time to get better startup performance! ;-)
>>>
>>> Definitely let me know what you find out. I too would expect framework
>>> restarts to be faster since we don't have to copy the JAR files first.
>>>
>>> -> richard
>>>
>>> /pierre
>>>>
>>>>
>>>>
>>>>
>>>> Is that what you are doing? Just want to make sure I understand what is
>>>>> being measured. :-)
>>>>>
>>>>>
>>>>> -> richard
>>>>>
>>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>>
>>>>> Hi Richard,
>>>>>>
>>>>>> I tried our app server with the trunk (old cache with the new
>>>>>>
>>>>> fwk/trunk)
>>>
>>>> ->
>>>>>> everything works ok
>>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>>
>>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>>
>>>>>> I also compared the performance of the startup time between felix
>>>>>>
>>>>> 2.0.2
>>>
>>>> and
>>>>>> felix trunk.
>>>>>> To do this, I managed to ensure that my linux IO buffers cache are
>>>>>>
>>>>> empty
>>>
>>>> before doing each test, by doing this:
>>>>>>
>>>>>> sync
>>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>>
>>>>>> This ensures that my linux has released all buffer cache disk, like it
>>>>>> is
>>>>>> the case when I boot my host (cold start).
>>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds (it's
>>>>>> slow
>>>>>> because all disk buffers are empty):
>>>>>>
>>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>>
>>>>>> and with felix/trunk, indeed, the server starts a little bit quicker,
>>>>>> but
>>>>>> not so much: around *in 20,3* seconds (I also flushed disk buffers
>>>>>> before
>>>>>> starting the test):
>>>>>>
>>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>>
>>>>>>
>>>>>> /pierre
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<heavy@ungoverned.org
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>> p.s. I deploy snapshots of the everything, including the convenience
>>>>>>
>>>>>>> framework distribution or you can build from trunk.
>>>>>>>
>>>>>>>
>>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>>
>>>>>>> Hey everyone,
>>>>>>>
>>>>>>>> I've made some changes to the bundle cache layout and handling to
>>>>>>>> improve
>>>>>>>> performance and clean up code. I've tried to maintain backward
>>>>>>>> compatibility
>>>>>>>> with old caches, but I'd appreciate is someone could try it out on
>>>>>>>> their
>>>>>>>> caches to see if it works.
>>>>>>>>
>>>>>>>> ** Back up your caches just in case! **
>>>>>>>>
>>>>>>>> Note that the new cache format will not work with older frameworks.
>>>>>>>>
>>>>>>> So
>>>
>>>> you
>>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>>> frameworks;
>>>>>>>> however, previously created caches should mostly continue to work
>>>>>>>> between
>>>>>>>> the two although there will be a loss of fidelity since changes to
>>>>>>>> state
>>>>>>>> are
>>>>>>>> only saved to the new way or the old way depending on if you are
>>>>>>>> running
>>>>>>>> on
>>>>>>>> the new framework or the old one.
>>>>>>>>
>>>>>>>> For the curious, I've combined five bundle cache files (id,
>>>>>>>>
>>>>>>> location,
>>>
>>>> state, start level, last modified, and refresh count) into a single
>>>>>>>> file
>>>>>>>> and
>>>>>>>> try to avoid excessive file accesses. This appears to improve
>>>>>>>>
>>>>>>> startup
>>>
>>>> time
>>>>>>>> when you have a cache with lots of bundles, but your mileage will
>>>>>>>>
>>>>>>> vary
>>>
>>>> based
>>>>>>>> on platform and other factors. Although, you won't necessarily see
>>>>>>>>
>>>>>>> any
>>>
>>>> improvements if you are using an old cache, since it will revert to
>>>>>>>> the
>>>>>>>> old
>>>>>>>> way.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>>
>>>>>>>>
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/2/10 12:09, Pierre De Rop wrote:
> Hi Richard,
>
> Ok, when I clean the disk buffer cache (using echo 1>
> /proc/sys/vm/drop_caches trick),
> it seems that when felix starts with a non-empty cache, it takes some
> substantial delay
> to load its existing cache before firing a "Framework Started" event.
>
> (Our app server is installed by a specific bundle installer, which waits for
> the "Framework Started" event,
> before installing other bundles).
>
> I never noticed this delay because, generally, when I start my fwk in dev
> environment, the bundles are already
> available from linux buffer cache, and felix starts quickly.
> But if I do the "echo> ..." trick in order to clear disk cache, then the
> delay is important
> I mean: the framework takes time to load its existing cache.
>
> To be more specific, I describe exactly what I tested:
>
> - I install/start only one bundle (our bundle installer)
> - When started, the bundle installer listens to the "Framework Started"
> event,
> - So, when the start event is caught, the bundle installer starts
> installing/starting
> other bundles (190), which might be already present in the cache.
>
> Here are the logs of a cold start (disk buffers cleared, and felix cache
> empty):
>
> 2010-10-02 17:18:14,219 - Starting Felix OSGi Framework ...
> 2010-10-02 17:18:15,536 - BundleInstaller starting
> 2010-10-02 17:18:15,538 - Framework started: Installing 190 bundles ...
> 2010-10-02 17:18:20,562 - Done.
>
> And here are the logs of a cold start (disk buffers cleared, but existing
> felix cache with 190 bundles in it):
>
> 2010-10-02 17:18:58,167 - Starting Felix OSGi Framework ...
> 2010-10-02 17:19:07,705 - BundleInstaller starting
> 2010-10-02 17:19:07,707 - Framework started: Installing bundles ...
> 2010-10-02 17:19:07,709 - Done.
>
> -> Here, we see that when the cache is non empty, felix takes 9.6 seconds
> before starting the bundle installer:
It makes sense that it waits some time before firing the event, since
all previously installed bundles are reloaded BEFORE sending the event,
per the spec.
> 2010-10-02 17:18:58,167 - Starting Felix OSGi Framework ...
> 2010-10-02 17:19:07,705 - BundleInstaller starting (at this point, the
> "Framework started" event is caught)
>
>
> What do you think ?
Am I interpreting the above data correctly that it takes about 6 seconds
to start up when you install your bundles and 9.6 seconds for it to
start when the framework reloads the cached bundles? And this data is
for the trunk framework?
If so, that seems odd to me, since the install includes the copying of
the JAR file as well as opening the JAR file for use, while reloading
should only include opening the JAR file for use...
-> richard
> /pierre
>
> On Fri, Oct 1, 2010 at 11:30 PM,<he...@ungoverned.org> wrote:
>
>> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop<pi...@gmail.com>
>> wrote:
>>> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
>>> <he...@ungoverned.org>wrote:
>>>
>>>> One thing, was your performance comparison based on using the new
>> cache
>>>> or
>>>> old?
>>>>
>>>> I assume you are using a newly created cache for the framework snapshot
>>>> and
>>>> [obviously] an old cache for the 3.0.2, correct?
>>>>
>>> yes:
>>> old cache with 3.0.2, and new cache with trunk.
>>> but I also checked that new fwk/trunk is properly working when being
>>> started
>>> with the old cache (from 3.0.2)
>>>
>>>> You should also be testing an already created cache (i.e., a framework
>>>> restart), not an empty cache.
>>>>
>>> In the previous test, I compared with already created cache, not with
>> empty
>>> caches.
>>> With empty caches, here are the results:
>>>
>>>
>>> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is surprising:
>> I
>>> would expect to get a longer delay, since the cache is empty when I
>>> start
>>> the fwk)
>>>
>>> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
>>> 2010-10-01 23:10:23,885 Starting cluster node "test"
>>> 2010-10-01 23:10:33,208 Cluster node "test" ready
>>>
>>>
>>> - new fwk / fresh empty cache ->15.2 sec
>>>
>>> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
>>> 2010-10-01 23:15:52,417 Starting cluster node "test"
>>> 2010-10-01 23:16:01,225 Cluster node "test" ready
>>>
>>> hmmm, I don't understand why the fwk startup time is better when the
>> cache
>>> is empty (15.2 sec) than when the cache is non-empty (21.2 sec from
>>> previous
>>> mail)
>>> Ok, I will do more tests ... may be I did something wrong ? ... to be
>>> continued ...
>> Hmm. Yeah, that seems a little odd. In that case, you should just delete
>> your cache each time to get better startup performance! ;-)
>>
>> Definitely let me know what you find out. I too would expect framework
>> restarts to be faster since we don't have to copy the JAR files first.
>>
>> -> richard
>>
>>> /pierre
>>>
>>>
>>>
>>>
>>>> Is that what you are doing? Just want to make sure I understand what is
>>>> being measured. :-)
>>>>
>>>>
>>>> -> richard
>>>>
>>>> On 10/1/10 16:43, Pierre De Rop wrote:
>>>>
>>>>> Hi Richard,
>>>>>
>>>>> I tried our app server with the trunk (old cache with the new
>> fwk/trunk)
>>>>> ->
>>>>> everything works ok
>>>>> (I install 195 bundles, and start 41 bundles)
>>>>>
>>>>> With new cache/fwk trunk -> it's also ok.
>>>>>
>>>>> I also compared the performance of the startup time between felix
>> 2.0.2
>>>>> and
>>>>> felix trunk.
>>>>> To do this, I managed to ensure that my linux IO buffers cache are
>> empty
>>>>> before doing each test, by doing this:
>>>>>
>>>>> sync
>>>>> echo 1> /proc/sys/vm/drop_caches
>>>>> echo 2> /proc/sys/vm/drop_caches
>>>>> echo 3> /proc/sys/vm/drop_caches
>>>>>
>>>>> This ensures that my linux has released all buffer cache disk, like it
>>>>> is
>>>>> the case when I boot my host (cold start).
>>>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds (it's
>>>>> slow
>>>>> because all disk buffers are empty):
>>>>>
>>>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>>>
>>>>> and with felix/trunk, indeed, the server starts a little bit quicker,
>>>>> but
>>>>> not so much: around *in 20,3* seconds (I also flushed disk buffers
>>>>> before
>>>>> starting the test):
>>>>>
>>>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>>>
>>>>>
>>>>> /pierre
>>>>>
>>>>>
>>>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<heavy@ungoverned.org
>>>>>> wrote:
>>>>> p.s. I deploy snapshots of the everything, including the convenience
>>>>>> framework distribution or you can build from trunk.
>>>>>>
>>>>>>
>>>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>>>
>>>>>> Hey everyone,
>>>>>>> I've made some changes to the bundle cache layout and handling to
>>>>>>> improve
>>>>>>> performance and clean up code. I've tried to maintain backward
>>>>>>> compatibility
>>>>>>> with old caches, but I'd appreciate is someone could try it out on
>>>>>>> their
>>>>>>> caches to see if it works.
>>>>>>>
>>>>>>> ** Back up your caches just in case! **
>>>>>>>
>>>>>>> Note that the new cache format will not work with older frameworks.
>> So
>>>>>>> you
>>>>>>> cannot use a cache created with this new framework with previous
>>>>>>> frameworks;
>>>>>>> however, previously created caches should mostly continue to work
>>>>>>> between
>>>>>>> the two although there will be a loss of fidelity since changes to
>>>>>>> state
>>>>>>> are
>>>>>>> only saved to the new way or the old way depending on if you are
>>>>>>> running
>>>>>>> on
>>>>>>> the new framework or the old one.
>>>>>>>
>>>>>>> For the curious, I've combined five bundle cache files (id,
>> location,
>>>>>>> state, start level, last modified, and refresh count) into a single
>>>>>>> file
>>>>>>> and
>>>>>>> try to avoid excessive file accesses. This appears to improve
>> startup
>>>>>>> time
>>>>>>> when you have a cache with lots of bundles, but your mileage will
>> vary
>>>>>>> based
>>>>>>> on platform and other factors. Although, you won't necessarily see
>> any
>>>>>>> improvements if you are using an old cache, since it will revert to
>>>>>>> the
>>>>>>> old
>>>>>>> way.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>>
Re: Bundle cache changes
Posted by Pierre De Rop <pi...@gmail.com>.
Hi Richard,
Ok, when I clean the disk buffer cache (using echo 1 >
/proc/sys/vm/drop_caches trick),
it seems that when felix starts with a non-empty cache, it takes some
substantial delay
to load its existing cache before firing a "Framework Started" event.
(Our app server is installed by a specific bundle installer, which waits for
the "Framework Started" event,
before installing other bundles).
I never noticed this delay because, generally, when I start my fwk in dev
environment, the bundles are already
available from linux buffer cache, and felix starts quickly.
But if I do the "echo > ..." trick in order to clear disk cache, then the
delay is important
I mean: the framework takes time to load its existing cache.
To be more specific, I describe exactly what I tested:
- I install/start only one bundle (our bundle installer)
- When started, the bundle installer listens to the "Framework Started"
event,
- So, when the start event is caught, the bundle installer starts
installing/starting
other bundles (190), which might be already present in the cache.
Here are the logs of a cold start (disk buffers cleared, and felix cache
empty):
2010-10-02 17:18:14,219 - Starting Felix OSGi Framework ...
2010-10-02 17:18:15,536 - BundleInstaller starting
2010-10-02 17:18:15,538 - Framework started: Installing 190 bundles ...
2010-10-02 17:18:20,562 - Done.
And here are the logs of a cold start (disk buffers cleared, but existing
felix cache with 190 bundles in it):
2010-10-02 17:18:58,167 - Starting Felix OSGi Framework ...
2010-10-02 17:19:07,705 - BundleInstaller starting
2010-10-02 17:19:07,707 - Framework started: Installing bundles ...
2010-10-02 17:19:07,709 - Done.
-> Here, we see that when the cache is non empty, felix takes 9.6 seconds
before starting the bundle installer:
2010-10-02 17:18:58,167 - Starting Felix OSGi Framework ...
2010-10-02 17:19:07,705 - BundleInstaller starting (at this point, the
"Framework started" event is caught)
What do you think ?
/pierre
On Fri, Oct 1, 2010 at 11:30 PM, <he...@ungoverned.org> wrote:
> On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop <pi...@gmail.com>
> wrote:
> > On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
> > <he...@ungoverned.org>wrote:
> >
> >> One thing, was your performance comparison based on using the new
> cache
> >> or
> >> old?
> >>
> >> I assume you are using a newly created cache for the framework snapshot
> >> and
> >> [obviously] an old cache for the 3.0.2, correct?
> >>
> > yes:
> > old cache with 3.0.2, and new cache with trunk.
> > but I also checked that new fwk/trunk is properly working when being
> > started
> > with the old cache (from 3.0.2)
> >
> >>
> >> You should also be testing an already created cache (i.e., a framework
> >> restart), not an empty cache.
> >>
> > In the previous test, I compared with already created cache, not with
> empty
> > caches.
> > With empty caches, here are the results:
> >
> >
> > - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is surprising:
> I
> > would expect to get a longer delay, since the cache is empty when I
> > start
> > the fwk)
> >
> > 2010-10-01 23:10:17,403 Starting Felix 3.0.2
> > 2010-10-01 23:10:23,885 Starting cluster node "test"
> > 2010-10-01 23:10:33,208 Cluster node "test" ready
> >
> >
> > - new fwk / fresh empty cache ->15.2 sec
> >
> > 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
> > 2010-10-01 23:15:52,417 Starting cluster node "test"
> > 2010-10-01 23:16:01,225 Cluster node "test" ready
> >
> > hmmm, I don't understand why the fwk startup time is better when the
> cache
> > is empty (15.2 sec) than when the cache is non-empty (21.2 sec from
> > previous
> > mail)
> > Ok, I will do more tests ... may be I did something wrong ? ... to be
> > continued ...
>
> Hmm. Yeah, that seems a little odd. In that case, you should just delete
> your cache each time to get better startup performance! ;-)
>
> Definitely let me know what you find out. I too would expect framework
> restarts to be faster since we don't have to copy the JAR files first.
>
> -> richard
>
> >
> > /pierre
> >
> >
> >
> >
> >>
> >> Is that what you are doing? Just want to make sure I understand what is
> >> being measured. :-)
> >>
> >>
> >> -> richard
> >>
> >> On 10/1/10 16:43, Pierre De Rop wrote:
> >>
> >>> Hi Richard,
> >>>
> >>> I tried our app server with the trunk (old cache with the new
> fwk/trunk)
> >>> ->
> >>> everything works ok
> >>> (I install 195 bundles, and start 41 bundles)
> >>>
> >>> With new cache/fwk trunk -> it's also ok.
> >>>
> >>> I also compared the performance of the startup time between felix
> 2.0.2
> >>> and
> >>> felix trunk.
> >>> To do this, I managed to ensure that my linux IO buffers cache are
> empty
> >>> before doing each test, by doing this:
> >>>
> >>> sync
> >>> echo 1> /proc/sys/vm/drop_caches
> >>> echo 2> /proc/sys/vm/drop_caches
> >>> echo 3> /proc/sys/vm/drop_caches
> >>>
> >>> This ensures that my linux has released all buffer cache disk, like it
> >>> is
> >>> the case when I boot my host (cold start).
> >>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds (it's
> >>> slow
> >>> because all disk buffers are empty):
> >>>
> >>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
> >>> 2010-10-01 22:15:18,121 Starting cluster node "test"
> >>> 2010-10-01 22:15:28,966 Cluster node "test" ready
> >>>
> >>> and with felix/trunk, indeed, the server starts a little bit quicker,
> >>> but
> >>> not so much: around *in 20,3* seconds (I also flushed disk buffers
> >>> before
> >>> starting the test):
> >>>
> >>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
> >>> 2010-10-01 22:17:56,815 Starting cluster node "test"
> >>> 2010-10-01 22:18:07,798 Cluster node "test" ready
> >>>
> >>>
> >>> /pierre
> >>>
> >>>
> >>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<heavy@ungoverned.org
> >>> >wrote:
> >>>
> >>> p.s. I deploy snapshots of the everything, including the convenience
> >>>> framework distribution or you can build from trunk.
> >>>>
> >>>>
> >>>> On 10/1/10 11:37, Richard S. Hall wrote:
> >>>>
> >>>> Hey everyone,
> >>>>>
> >>>>> I've made some changes to the bundle cache layout and handling to
> >>>>> improve
> >>>>> performance and clean up code. I've tried to maintain backward
> >>>>> compatibility
> >>>>> with old caches, but I'd appreciate is someone could try it out on
> >>>>> their
> >>>>> caches to see if it works.
> >>>>>
> >>>>> ** Back up your caches just in case! **
> >>>>>
> >>>>> Note that the new cache format will not work with older frameworks.
> So
> >>>>> you
> >>>>> cannot use a cache created with this new framework with previous
> >>>>> frameworks;
> >>>>> however, previously created caches should mostly continue to work
> >>>>> between
> >>>>> the two although there will be a loss of fidelity since changes to
> >>>>> state
> >>>>> are
> >>>>> only saved to the new way or the old way depending on if you are
> >>>>> running
> >>>>> on
> >>>>> the new framework or the old one.
> >>>>>
> >>>>> For the curious, I've combined five bundle cache files (id,
> location,
> >>>>> state, start level, last modified, and refresh count) into a single
> >>>>> file
> >>>>> and
> >>>>> try to avoid excessive file accesses. This appears to improve
> startup
> >>>>> time
> >>>>> when you have a cache with lots of bundles, but your mileage will
> vary
> >>>>> based
> >>>>> on platform and other factors. Although, you won't necessarily see
> any
> >>>>> improvements if you are using an old cache, since it will revert to
> >>>>> the
> >>>>> old
> >>>>> way.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> -> richard
> >>>>>
> >>>>>
>
Re: Bundle cache changes
Posted by he...@ungoverned.org.
On Fri, 1 Oct 2010 23:25:35 +0200, Pierre De Rop <pi...@gmail.com>
wrote:
> On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall
> <he...@ungoverned.org>wrote:
>
>> One thing, was your performance comparison based on using the new
cache
>> or
>> old?
>>
>> I assume you are using a newly created cache for the framework snapshot
>> and
>> [obviously] an old cache for the 3.0.2, correct?
>>
> yes:
> old cache with 3.0.2, and new cache with trunk.
> but I also checked that new fwk/trunk is properly working when being
> started
> with the old cache (from 3.0.2)
>
>>
>> You should also be testing an already created cache (i.e., a framework
>> restart), not an empty cache.
>>
> In the previous test, I compared with already created cache, not with
empty
> caches.
> With empty caches, here are the results:
>
>
> - old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is surprising:
I
> would expect to get a longer delay, since the cache is empty when I
> start
> the fwk)
>
> 2010-10-01 23:10:17,403 Starting Felix 3.0.2
> 2010-10-01 23:10:23,885 Starting cluster node "test"
> 2010-10-01 23:10:33,208 Cluster node "test" ready
>
>
> - new fwk / fresh empty cache ->15.2 sec
>
> 2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
> 2010-10-01 23:15:52,417 Starting cluster node "test"
> 2010-10-01 23:16:01,225 Cluster node "test" ready
>
> hmmm, I don't understand why the fwk startup time is better when the
cache
> is empty (15.2 sec) than when the cache is non-empty (21.2 sec from
> previous
> mail)
> Ok, I will do more tests ... may be I did something wrong ? ... to be
> continued ...
Hmm. Yeah, that seems a little odd. In that case, you should just delete
your cache each time to get better startup performance! ;-)
Definitely let me know what you find out. I too would expect framework
restarts to be faster since we don't have to copy the JAR files first.
-> richard
>
> /pierre
>
>
>
>
>>
>> Is that what you are doing? Just want to make sure I understand what is
>> being measured. :-)
>>
>>
>> -> richard
>>
>> On 10/1/10 16:43, Pierre De Rop wrote:
>>
>>> Hi Richard,
>>>
>>> I tried our app server with the trunk (old cache with the new
fwk/trunk)
>>> ->
>>> everything works ok
>>> (I install 195 bundles, and start 41 bundles)
>>>
>>> With new cache/fwk trunk -> it's also ok.
>>>
>>> I also compared the performance of the startup time between felix
2.0.2
>>> and
>>> felix trunk.
>>> To do this, I managed to ensure that my linux IO buffers cache are
empty
>>> before doing each test, by doing this:
>>>
>>> sync
>>> echo 1> /proc/sys/vm/drop_caches
>>> echo 2> /proc/sys/vm/drop_caches
>>> echo 3> /proc/sys/vm/drop_caches
>>>
>>> This ensures that my linux has released all buffer cache disk, like it
>>> is
>>> the case when I boot my host (cold start).
>>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds (it's
>>> slow
>>> because all disk buffers are empty):
>>>
>>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>>
>>> and with felix/trunk, indeed, the server starts a little bit quicker,
>>> but
>>> not so much: around *in 20,3* seconds (I also flushed disk buffers
>>> before
>>> starting the test):
>>>
>>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>>
>>>
>>> /pierre
>>>
>>>
>>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<heavy@ungoverned.org
>>> >wrote:
>>>
>>> p.s. I deploy snapshots of the everything, including the convenience
>>>> framework distribution or you can build from trunk.
>>>>
>>>>
>>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>>
>>>> Hey everyone,
>>>>>
>>>>> I've made some changes to the bundle cache layout and handling to
>>>>> improve
>>>>> performance and clean up code. I've tried to maintain backward
>>>>> compatibility
>>>>> with old caches, but I'd appreciate is someone could try it out on
>>>>> their
>>>>> caches to see if it works.
>>>>>
>>>>> ** Back up your caches just in case! **
>>>>>
>>>>> Note that the new cache format will not work with older frameworks.
So
>>>>> you
>>>>> cannot use a cache created with this new framework with previous
>>>>> frameworks;
>>>>> however, previously created caches should mostly continue to work
>>>>> between
>>>>> the two although there will be a loss of fidelity since changes to
>>>>> state
>>>>> are
>>>>> only saved to the new way or the old way depending on if you are
>>>>> running
>>>>> on
>>>>> the new framework or the old one.
>>>>>
>>>>> For the curious, I've combined five bundle cache files (id,
location,
>>>>> state, start level, last modified, and refresh count) into a single
>>>>> file
>>>>> and
>>>>> try to avoid excessive file accesses. This appears to improve
startup
>>>>> time
>>>>> when you have a cache with lots of bundles, but your mileage will
vary
>>>>> based
>>>>> on platform and other factors. Although, you won't necessarily see
any
>>>>> improvements if you are using an old cache, since it will revert to
>>>>> the
>>>>> old
>>>>> way.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -> richard
>>>>>
>>>>>
Re: Bundle cache changes
Posted by Pierre De Rop <pi...@gmail.com>.
On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> One thing, was your performance comparison based on using the new cache or
> old?
>
> I assume you are using a newly created cache for the framework snapshot and
> [obviously] an old cache for the 3.0.2, correct?
>
yes:
old cache with 3.0.2, and new cache with trunk.
but I also checked that new fwk/trunk is properly working when being started
with the old cache (from 3.0.2)
>
> You should also be testing an already created cache (i.e., a framework
> restart), not an empty cache.
>
In the previous test, I compared with already created cache, not with empty
caches.
With empty caches, here are the results:
- old fwk 3.0.2 / fresh empty cache -> 15.8 sec. (this is surprising: I
would expect to get a longer delay, since the cache is empty when I start
the fwk)
2010-10-01 23:10:17,403 Starting Felix 3.0.2
2010-10-01 23:10:23,885 Starting cluster node "test"
2010-10-01 23:10:33,208 Cluster node "test" ready
- new fwk / fresh empty cache ->15.2 sec
2010-10-01 23:15:46,2 Starting Felix 3.1.0.SNAPSHOT
2010-10-01 23:15:52,417 Starting cluster node "test"
2010-10-01 23:16:01,225 Cluster node "test" ready
hmmm, I don't understand why the fwk startup time is better when the cache
is empty (15.2 sec) than when the cache is non-empty (21.2 sec from previous
mail)
Ok, I will do more tests ... may be I did something wrong ? ... to be
continued ...
/pierre
>
> Is that what you are doing? Just want to make sure I understand what is
> being measured. :-)
>
>
> -> richard
>
> On 10/1/10 16:43, Pierre De Rop wrote:
>
>> Hi Richard,
>>
>> I tried our app server with the trunk (old cache with the new fwk/trunk)
>> ->
>> everything works ok
>> (I install 195 bundles, and start 41 bundles)
>>
>> With new cache/fwk trunk -> it's also ok.
>>
>> I also compared the performance of the startup time between felix 2.0.2
>> and
>> felix trunk.
>> To do this, I managed to ensure that my linux IO buffers cache are empty
>> before doing each test, by doing this:
>>
>> sync
>> echo 1> /proc/sys/vm/drop_caches
>> echo 2> /proc/sys/vm/drop_caches
>> echo 3> /proc/sys/vm/drop_caches
>>
>> This ensures that my linux has released all buffer cache disk, like it is
>> the case when I boot my host (cold start).
>> Now, for felix 3.0.2, I load my server in around *21,1 *seconds (it's slow
>> because all disk buffers are empty):
>>
>> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
>> 2010-10-01 22:15:18,121 Starting cluster node "test"
>> 2010-10-01 22:15:28,966 Cluster node "test" ready
>>
>> and with felix/trunk, indeed, the server starts a little bit quicker, but
>> not so much: around *in 20,3* seconds (I also flushed disk buffers before
>> starting the test):
>>
>> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
>> 2010-10-01 22:17:56,815 Starting cluster node "test"
>> 2010-10-01 22:18:07,798 Cluster node "test" ready
>>
>>
>> /pierre
>>
>>
>> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<heavy@ungoverned.org
>> >wrote:
>>
>> p.s. I deploy snapshots of the everything, including the convenience
>>> framework distribution or you can build from trunk.
>>>
>>>
>>> On 10/1/10 11:37, Richard S. Hall wrote:
>>>
>>> Hey everyone,
>>>>
>>>> I've made some changes to the bundle cache layout and handling to
>>>> improve
>>>> performance and clean up code. I've tried to maintain backward
>>>> compatibility
>>>> with old caches, but I'd appreciate is someone could try it out on their
>>>> caches to see if it works.
>>>>
>>>> ** Back up your caches just in case! **
>>>>
>>>> Note that the new cache format will not work with older frameworks. So
>>>> you
>>>> cannot use a cache created with this new framework with previous
>>>> frameworks;
>>>> however, previously created caches should mostly continue to work
>>>> between
>>>> the two although there will be a loss of fidelity since changes to state
>>>> are
>>>> only saved to the new way or the old way depending on if you are running
>>>> on
>>>> the new framework or the old one.
>>>>
>>>> For the curious, I've combined five bundle cache files (id, location,
>>>> state, start level, last modified, and refresh count) into a single file
>>>> and
>>>> try to avoid excessive file accesses. This appears to improve startup
>>>> time
>>>> when you have a cache with lots of bundles, but your mileage will vary
>>>> based
>>>> on platform and other factors. Although, you won't necessarily see any
>>>> improvements if you are using an old cache, since it will revert to the
>>>> old
>>>> way.
>>>>
>>>> Thanks.
>>>>
>>>> -> richard
>>>>
>>>>
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
One thing, was your performance comparison based on using the new
cache or old?
I assume you are using a newly created cache for the framework snapshot
and [obviously] an old cache for the 3.0.2, correct?
You should also be testing an already created cache (i.e., a framework
restart), not an empty cache.
Is that what you are doing? Just want to make sure I understand what is
being measured. :-)
-> richard
On 10/1/10 16:43, Pierre De Rop wrote:
> Hi Richard,
>
> I tried our app server with the trunk (old cache with the new fwk/trunk) ->
> everything works ok
> (I install 195 bundles, and start 41 bundles)
>
> With new cache/fwk trunk -> it's also ok.
>
> I also compared the performance of the startup time between felix 2.0.2 and
> felix trunk.
> To do this, I managed to ensure that my linux IO buffers cache are empty
> before doing each test, by doing this:
>
> sync
> echo 1> /proc/sys/vm/drop_caches
> echo 2> /proc/sys/vm/drop_caches
> echo 3> /proc/sys/vm/drop_caches
>
> This ensures that my linux has released all buffer cache disk, like it is
> the case when I boot my host (cold start).
> Now, for felix 3.0.2, I load my server in around *21,1 *seconds (it's slow
> because all disk buffers are empty):
>
> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
> 2010-10-01 22:15:18,121 Starting cluster node "test"
> 2010-10-01 22:15:28,966 Cluster node "test" ready
>
> and with felix/trunk, indeed, the server starts a little bit quicker, but
> not so much: around *in 20,3* seconds (I also flushed disk buffers before
> starting the test):
>
> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
> 2010-10-01 22:17:56,815 Starting cluster node "test"
> 2010-10-01 22:18:07,798 Cluster node "test" ready
>
>
> /pierre
>
>
> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> p.s. I deploy snapshots of the everything, including the convenience
>> framework distribution or you can build from trunk.
>>
>>
>> On 10/1/10 11:37, Richard S. Hall wrote:
>>
>>> Hey everyone,
>>>
>>> I've made some changes to the bundle cache layout and handling to improve
>>> performance and clean up code. I've tried to maintain backward compatibility
>>> with old caches, but I'd appreciate is someone could try it out on their
>>> caches to see if it works.
>>>
>>> ** Back up your caches just in case! **
>>>
>>> Note that the new cache format will not work with older frameworks. So you
>>> cannot use a cache created with this new framework with previous frameworks;
>>> however, previously created caches should mostly continue to work between
>>> the two although there will be a loss of fidelity since changes to state are
>>> only saved to the new way or the old way depending on if you are running on
>>> the new framework or the old one.
>>>
>>> For the curious, I've combined five bundle cache files (id, location,
>>> state, start level, last modified, and refresh count) into a single file and
>>> try to avoid excessive file accesses. This appears to improve startup time
>>> when you have a cache with lots of bundles, but your mileage will vary based
>>> on platform and other factors. Although, you won't necessarily see any
>>> improvements if you are using an old cache, since it will revert to the old
>>> way.
>>>
>>> Thanks.
>>>
>>> -> richard
>>>
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Interesting statistics...thanks for doing it.
Yeah, that doesn't look like it buys us too much. Another guy doing
figures for me was reporting more, but I'm not sure how he was setting
it up or what platform he was running on.
At least I didn't break anything, though! :-)
-> richard
On 10/1/10 16:43, Pierre De Rop wrote:
> Hi Richard,
>
> I tried our app server with the trunk (old cache with the new fwk/trunk) ->
> everything works ok
> (I install 195 bundles, and start 41 bundles)
>
> With new cache/fwk trunk -> it's also ok.
>
> I also compared the performance of the startup time between felix 2.0.2 and
> felix trunk.
> To do this, I managed to ensure that my linux IO buffers cache are empty
> before doing each test, by doing this:
>
> sync
> echo 1> /proc/sys/vm/drop_caches
> echo 2> /proc/sys/vm/drop_caches
> echo 3> /proc/sys/vm/drop_caches
>
> This ensures that my linux has released all buffer cache disk, like it is
> the case when I boot my host (cold start).
> Now, for felix 3.0.2, I load my server in around *21,1 *seconds (it's slow
> because all disk buffers are empty):
>
> 2010-10-01 22:15:07,880 Starting Felix 3.0.2
> 2010-10-01 22:15:18,121 Starting cluster node "test"
> 2010-10-01 22:15:28,966 Cluster node "test" ready
>
> and with felix/trunk, indeed, the server starts a little bit quicker, but
> not so much: around *in 20,3* seconds (I also flushed disk buffers before
> starting the test):
>
> 2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
> 2010-10-01 22:17:56,815 Starting cluster node "test"
> 2010-10-01 22:18:07,798 Cluster node "test" ready
>
>
> /pierre
>
>
> On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> p.s. I deploy snapshots of the everything, including the convenience
>> framework distribution or you can build from trunk.
>>
>>
>> On 10/1/10 11:37, Richard S. Hall wrote:
>>
>>> Hey everyone,
>>>
>>> I've made some changes to the bundle cache layout and handling to improve
>>> performance and clean up code. I've tried to maintain backward compatibility
>>> with old caches, but I'd appreciate is someone could try it out on their
>>> caches to see if it works.
>>>
>>> ** Back up your caches just in case! **
>>>
>>> Note that the new cache format will not work with older frameworks. So you
>>> cannot use a cache created with this new framework with previous frameworks;
>>> however, previously created caches should mostly continue to work between
>>> the two although there will be a loss of fidelity since changes to state are
>>> only saved to the new way or the old way depending on if you are running on
>>> the new framework or the old one.
>>>
>>> For the curious, I've combined five bundle cache files (id, location,
>>> state, start level, last modified, and refresh count) into a single file and
>>> try to avoid excessive file accesses. This appears to improve startup time
>>> when you have a cache with lots of bundles, but your mileage will vary based
>>> on platform and other factors. Although, you won't necessarily see any
>>> improvements if you are using an old cache, since it will revert to the old
>>> way.
>>>
>>> Thanks.
>>>
>>> -> richard
>>>
Re: Bundle cache changes
Posted by Pierre De Rop <pi...@gmail.com>.
Hi Richard,
I tried our app server with the trunk (old cache with the new fwk/trunk) ->
everything works ok
(I install 195 bundles, and start 41 bundles)
With new cache/fwk trunk -> it's also ok.
I also compared the performance of the startup time between felix 2.0.2 and
felix trunk.
To do this, I managed to ensure that my linux IO buffers cache are empty
before doing each test, by doing this:
sync
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches
This ensures that my linux has released all buffer cache disk, like it is
the case when I boot my host (cold start).
Now, for felix 3.0.2, I load my server in around *21,1 *seconds (it's slow
because all disk buffers are empty):
2010-10-01 22:15:07,880 Starting Felix 3.0.2
2010-10-01 22:15:18,121 Starting cluster node "test"
2010-10-01 22:15:28,966 Cluster node "test" ready
and with felix/trunk, indeed, the server starts a little bit quicker, but
not so much: around *in 20,3* seconds (I also flushed disk buffers before
starting the test):
2010-10-01 22:17:47,505 Starting Felix 3.1.0.SNAPSHOT
2010-10-01 22:17:56,815 Starting cluster node "test"
2010-10-01 22:18:07,798 Cluster node "test" ready
/pierre
On Fri, Oct 1, 2010 at 5:39 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> p.s. I deploy snapshots of the everything, including the convenience
> framework distribution or you can build from trunk.
>
>
> On 10/1/10 11:37, Richard S. Hall wrote:
>
>> Hey everyone,
>>
>> I've made some changes to the bundle cache layout and handling to improve
>> performance and clean up code. I've tried to maintain backward compatibility
>> with old caches, but I'd appreciate is someone could try it out on their
>> caches to see if it works.
>>
>> ** Back up your caches just in case! **
>>
>> Note that the new cache format will not work with older frameworks. So you
>> cannot use a cache created with this new framework with previous frameworks;
>> however, previously created caches should mostly continue to work between
>> the two although there will be a loss of fidelity since changes to state are
>> only saved to the new way or the old way depending on if you are running on
>> the new framework or the old one.
>>
>> For the curious, I've combined five bundle cache files (id, location,
>> state, start level, last modified, and refresh count) into a single file and
>> try to avoid excessive file accesses. This appears to improve startup time
>> when you have a cache with lots of bundles, but your mileage will vary based
>> on platform and other factors. Although, you won't necessarily see any
>> improvements if you are using an old cache, since it will revert to the old
>> way.
>>
>> Thanks.
>>
>> -> richard
>>
>
Re: Bundle cache changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
p.s. I deploy snapshots of the everything, including the convenience
framework distribution or you can build from trunk.
On 10/1/10 11:37, Richard S. Hall wrote:
> Hey everyone,
>
> I've made some changes to the bundle cache layout and handling to
> improve performance and clean up code. I've tried to maintain backward
> compatibility with old caches, but I'd appreciate is someone could try
> it out on their caches to see if it works.
>
> ** Back up your caches just in case! **
>
> Note that the new cache format will not work with older frameworks. So
> you cannot use a cache created with this new framework with previous
> frameworks; however, previously created caches should mostly continue
> to work between the two although there will be a loss of fidelity
> since changes to state are only saved to the new way or the old way
> depending on if you are running on the new framework or the old one.
>
> For the curious, I've combined five bundle cache files (id, location,
> state, start level, last modified, and refresh count) into a single
> file and try to avoid excessive file accesses. This appears to improve
> startup time when you have a cache with lots of bundles, but your
> mileage will vary based on platform and other factors. Although, you
> won't necessarily see any improvements if you are using an old cache,
> since it will revert to the old way.
>
> Thanks.
>
> -> richard