Rickard, this is very interesting for me right now.
Infinispan cache propose an eviction strategy (swap-out cache entries from memory to the cache store) based on different mechanisms (FIFO/LRU). The issue here is the triggering system, it is based on the number of entries in the cache... no very effective for me (BTW I wonder if it is for anyone). I would like to trigger this using the total size of the cache in memory (or the free memory left... don't know yet). If you store the JSON object in the state of composites and you parse it/update it only "on demand" the actual memory used by this object will be close to the size of JSON-ized version in the cache. Is this correct ? Any idea about the best way to calculate the (average) size of the composite in memory (other than empirically). I would like to avoid eviction as much as possible, so I also plan to compress the cache content too (gzipping JSON if very effective)... cheers, phil Le 7 déc. 2009 à 11:58, Rickard Öberg a écrit : > Hi, > > The current MapEntityStore and DefaultEntityStore uses a strategy which > basically loads the JSON-state on read, and parses it out completely, and > then writes it out completely on UoW complete. Since usecases normally only > needs a small portion of the properties/associations there's a lot of > unnecessary parsing going on, both ways. > > So I made a new version of it which instead reads the JSON-object from the > underlying store and then provides that directly to the EntityState. When a > property is read, only then is it parsed from the JSON-object. Similarly, > when a property is set, at that point it is translated into JSON, so that > UoW-complete basically only writes the already up-to-date JSON-object. This > *should* be faster and consume a whole lot less memory. > > However, when I did performance profiling I could see that the performance > difference was quite small. The reason is that parsing the JSON-object from a > String is what really takes time. The main difference, then, would be memory > footprint, which is important enough. > > I've kept the old MapEntityStore mixin around, but have switched to the new > JSONMapEntityStoreMixin for the memory store. If other stores want to use it, > just replace the mixin that is used. > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
