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 >> >
