On Fri, Oct 1, 2010 at 10:57 PM, Richard S. Hall <[email protected]>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<[email protected] >> >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 >>>> >>>>
